Fear the Repo Dead
XmlmXmlmX opened this issue · 17 comments
16 open pulls, 45 open bugs, the last commit was on 2 Jun.
Is this repo still alive?
The alternative is, somebody takes it officially up. To avoid getting multiple splitted copies of this repo.
If someone else would join to create an "official" fork, I might help out, just don't want to do it myself.
@XmlmXmlmX official in the sense that there's a link in this repo to the new repo where "everyone" is sending their pull requests.
What about the license. I'm not an expert to this. Is Apache 2.0 still the best? Should/Could we change the license? Do we still need the hint Copyright 2014 Google Inc. All rights reserved.?
Unlike you I'm not an expert in that field, personally I'd suggest to go with MIT, but we'd have to ask the google guys first.
Thanks!
Email send at 13:10 (MEZ) to @brendankenny and Luke Mahé.
Some additional info about license:
- https://www.quora.com/Whats-the-different-between-Apache-v2-0-and-MIT-license
- https://www.quora.com/Is-the-MIT-license-compatible-with-the-Apache-License-Version-2-APLv2
- http://www.whitesourcesoftware.com/whitesource-blog/top-10-apache-license-questions-answered/?utm_source=quora&utm_medium=social&utm_term=blog-top-10-apache-license-questions-answered&utm_content=Is-the-MIT-license-compatible-with-the-Apache
- http://softwareengineering.stackexchange.com/questions/278094/license-terms-when-porting-free-software-to-another-language
News, I've got an answer from Google.
Q: Can/must/should we change the current license (Apache 2.0)? Our suggestion is MIT.
A: According to the Apache 2 license, it's required that you retain it for any code that was originally licensed under it. If you have your heart set on a different license, you might be able to license any new changes under it, but the existing code must retain existing license notices. My opinion is that the easiest thing to do would be to continue using the Apache license (it would also show a sign of good faith).
Q: Do we still need the Copyright disclaimer?
A: See the above.
Q: Can we drop the Contributor License Agreement?
A: Yes
Q: Would you link our new Repository and close the issues section after a migration?
A: We can't do this unfortunately, but you're free to leave a comment in the thread you mentioned pointing to it.
Q: Are there any comments from Google on this subject?
A: Thanks for your help with this!
No problem with the license, but it's a shame they can't link to the fork. That causes the thing I hate about forks, there are too many and not a single one is official.
How do you suggest we proceed? Create a new repo using the organization js-marker-clusterer? Want to keep it under your own username?
That's true @Remo. I think there is no other way than to comment each of these issues to create this issue again in our new repository. The same for all open pull-requests.
Does this sounds realistic?
To create a new organisation like js-marker-clusterer is a good idea. We should do that. Would you create one?
It's a shame, but if we start pulling some of the fixes into the repository we should hopefully get enough traction to make it the inoffically official fork.
Invitation sent
Ok, may we should start with the PRs. We could create a Issue in the new repo for this topic and collect there all relevant PRs in a checklist.
This seems like pretty important functionality for Google Maps. Is there any sense as to why Google is abandoning this codebase? I.e. are they working on a replacement for it? Or is their a competing solution that is more popular?