[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