|Re: [eigen] MPL2 is really compatible with GPL/LGPL|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] MPL2 is really compatible with GPL/LGPL
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 28 Jun 2012 17:02:04 -0400
- Cc: Gerv Markham <gerv@xxxxxxxxxxx>, Daniel Berlin <dannyb@xxxxxxxxxx>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VVSuteUdGWXeTeVOmMIMR/HIFFGdJsuYprtm0jovYms=; b=pZZdy/cS3UMirvbw3wnR8IXokEurxhZ+EvDXS96n9tkvm2KmJJVrppV/KCKvmYPB8q QbQeyuwLXQWRiY8OoIVL4nT5xrpMQmVKeXcs4k/F8oHMtKwLr1HzZBT46BDOKXOfzSc/ 76Ars7C6yb1IGxWms/jAmWKiIQ+ebqbIyHzrcmGJCjWNJde80VcjeYTmI4TzMzLyxx0U 8n6RYeBv3A/o9zuIbwUQget+IqIpDfMDMvFN7fHNRRehOq1C0Mns/DKgKtMdl9reYRBo nlwh+9urRkcU2L2O+tcVpWH92nf1RpjeQub6Rgimw+/d9mtbMRIHzwrvVbDKIbvHwRGi zl+w==
Many, many thanks for the invaluable reply. I have one question below:
2012/6/28 Daniel Berlin <dannyb@xxxxxxxxxx>:
>> Does that means if someone combines MPL2 code and LGPL code to build
>> an app, then the app can be either MPL2 or LGPL??
> LGPL is a bad example here, as LGPL does not require the overall work
> be LGPL'd except in specific cases.
Oh. I had forgotten about that aspect of the LGPL. Does this mean that
in this respect, the MPL2 is less liberal than the LGPL (in that it
requires the Larger Works to be covered by the MPL2, whereas the LGPL
has no such requirement)? If that is the case, could you elaborate a
bit on what the risks are that switching Eigen to MPL2 could annoy
existing users (because suddently this MPL2 licensing requirement
would apply to their Larger Works) ?
> But if you combine MPL2 code with GPL code, your overall work will be
> GPL. The pieces of that work that were MPL'd can now be used under
> GPL *or* MPL. The rest of the work is still GPL-only.
>> This does not make sense to me.
>> Requirement 3 is confusing too: I don't understand how is it different
>> from traditional dual-licensing if the "recipients can then take under
>> (L)GPL-only or MPL-only" ??
> I think i covered this above, i'll only add that in the case of dual
> licensing, if I choose GPL, it's GPL forever for everything.
> If i choose MPLv2, i can distribute a larger work under GPLv2, people
> can take the MPLv2 pieces under MPLv2, and then, later on down the
> road, make them part of a larger LGPL or GPL work again. You can't do
> this with dual licensing.
>> What does "you must make the MPL-licensed source code available to
>> your recipients under both MPL and (L)GPL" means for us in practice?
> It means that people aren't stuck with just LGPL or GPL depending on
> whose source code they got their distribution from :)
>> On Thu, Jun 28, 2012 at 10:11 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> I've finally had a look at it and in fact it's really clear --- sorry,
>>> I don't know why I took so long to get back to it, sometimes you just
>>> need to give your brain some time before you come back to a problem.
>>> I am CC'ing Gerv who is a MPL expert at Mozilla to hopefully check
>>> that I am not saying anything wrong here.
>>> Here goes:
>>> The MPL itself doesn't ever mention the GPL, LGPL, or any other
>>> licenses. So the compatibility is implicit and generic. The FAQ
>>> explains it, though not as simply as I would like for non-lawyers,
>>> which is why I didn't get back to it until today:
>>> Here is my understanding of things from the MPL2 text, regardless of the FAQ:
>>> The license is designed to be GPL compatible by default, but allow you
>>> to opt out from it. This opting-out feature is primarily intended for
>>> existing software that is licensed under MPL1, and not dual-licensed
>>> with GPL and/or LGPL. Such software is not currently GPL-compatible,
>>> so they had to find a way to allow it to upgrade without having to
>>> accept GPL-compatibility (I guess). Anyway, the key is that this is
>>> NOT our case and if we relicense to plain default MPL2 we are NOT
>>> concerned by this at all. The default case, into which we fall by
>>> default, is GPL-compatible.
>>> Here is how this is working in the MPL2 text. The key part is Section 3..3:
>>>> 3.3. Distribution of a Larger Work
>>>> You may create and distribute a Larger Work under terms of Your choice, provided that You also comply with the requirements of this License for the Covered Software. If the Larger Work is a combination of Covered Software with a work governed by one or more Secondary Licenses, and the Covered Software is not Incompatible With Secondary Licenses, this License permits You to additionally distribute such Covered Software under the terms of such Secondary License(s), so that the recipient of the Larger Work may, at their option, further distribute the Covered Software under the terms of either this License or such Secondary License(s).
>>> So as long as we are not "Incompatible With Secondary Licenses", we
>>> are GPL compatible in the sense that if you combine MPL2 and GPL code
>>> to create a Larger Work, you can distribute the Larger Work under dual
>>> MPL/GPL. As explained in the FAQ, "Someone downstream from your
>>> recipients can then take under (L)GPL-only or MPL-only.".
>>> The question becomes then, what decides whether we are "Incompatible
>>> With Secondary Licenses"?
>>> This is explained clearly by Section 1.5: we would be "Incompatible
>>> With Secondary Licenses" if either of the following conditions were
>>> - either if Eigen had been previously licensed as MPL1 only (does not
>>> apply to dual-licensing with MPL and another license).
>>> - or if we added the text snippet from Exhibit B to explicitly opt
>>> out from compatibility
>>> Since we are not in either case, we are not "Incompatible With
>>> Secondary Licenses". Therefore, the provisions of 3.3. Distribution of
>>> a Larger Work apply to us, i.e. we are compatible.
>>> Is this fully clear to everyone?