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

Robert Kern robert.kern at gmail.com
Thu Jul 3 12:39:30 CEST 2014


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




More information about the zeromq-dev mailing list