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
