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, 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. -Pieter On Thu, Jul 3, 2014 at 12:39 PM, Robert Kern <[email protected]> wrote: > On 2014-07-03 09:28, Pieter Hintjens wrote: >> This kind of thing happens, when we intersect communities. >> >> Software licenses are not an easy area. Most projects on Github >> haven't even got an explicit license, let alone a clear rationale for >> their license choice. >> >> I'm pretty sure that a MIT/BSD licensed project cannot accept pull >> requests without an additional step ("I license this patch/all my >> patches under MIT"), which most people will not know about, or skip. >> Meaning the codebase can become tainted with unlicensed code. >> >> GitHub could in fact fix this with a one-time contributor agreement >> for people sending PRs to a new project. Until then a share-alike >> license like MPLv2 is safe by default. (This is my current analysis, >> I'm always happy to be corrected.) > > The same additional step is required even when the project has a share-alike > license (if you decide such a step is required for any license). Someone can > physically make a patch to the MPLv2-covered software and distribute it > without > licensing it under the MPLv2. They are just in violation of the project's > MPLv2 > license if they do so. They have two ways to remedy this: license their patch > under the MPLv2 or stop distributing their patch. Nothing forces them to take > the former action. > > Of course, everyone who wants to contribute their patch to the project *wants* > to take the former action. But the same is true as long as the project's > policy > is to only accept contributions under the same license as the project, no > matter > which license that happens to be, whether it is a share-alike license or > MIT/BSD. > > IANAL. TINLA. HAND. > > -- > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
