On 2014-07-03 12:57, Pieter Hintjens wrote: > Our process bans patches delivered any way except via the GitHub > fork/merge process. That can only happen from public forks, thus any > patch is published (and optionally licensed) before the author can > start making a pull request. > > We simply don't accept patches provided any other way. So the question > is, what's the license on a derived work published on GitHub? IANAL > and TINLA however it seems clear that with a share-alike license, the > derived work is by definition published under the same license,
This is not correct. The act of publishing a derivative work does not automatically license the derivative work in any particular way even when the original license is share-alike. You don't have *permission* to publish it any other way, certainly, but that doesn't stop one from doing it in error. They can still fix their error by removing the derivative work. They do not have to license it to you under any given license. Violating the upstream license just means that you lose the ability to distribute the derivative work. Consider the case of a developer employed by a company. As is typical, the company owns the copyright to whatever code he writes in the course of his job. Suppose he forks 0MQ to submit a patch needed for work, but he doesn't get the appropriate permissions from his superiors to do so. The contents of his PR are still owned by the company, and no one else has a license to use it until they decide so (of course, no one outside knows this because the developer goofed). The fact that the forked project is licensed under a share-alike license doesn't force the company to retroactively license their IP under that license. If you merged that PR, they can still force you to remove it. > whereas with a "permissive" license, you can't make that assumption. > It may be, and it may not be. > > Which puts the onus of verification on the person clicking "Merge", > which brings us back to "maintainers as experts", which we have > learned is not good for community growth. I think that you can reasonably take the act of publishing a forked repo without changing its attached license indicates agreement to apply that license to the modifications in the repo. Similarly, the act of submitting a PR to a project that declares that it will only accept PRs under the project's license is sufficient in my book. If you don't think that this is sufficient for the MIT/BSD license, then it is also insufficient for share-alike licenses. The share-alike nature of the license does not provide any more protection. If someone comes along claiming that they own code that was committed by someone else or if they say that they contributed it in error and didn't intend to contribute it under the project's license, you have exactly the same problem. Karl Fogel's book _Producing Open Source Software_ covers this issue: http://producingoss.com/en/contributor-agreements.html Note that there is no discussion of share-alike licenses providing extra protection. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
