[zeromq-dev] [ANN] zmq.rs - native stack of ØMQ in Rust

[Pieter Hintjens]

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 <robert.kern at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev