Re: [eigen] MPL2 is really compatible with GPL/LGPL

[Daniel Berlin <dannyb@xxxxxxxxxx>]

On Thu, Jun 28, 2012 at 4:30 PM, Gael Guennebaud
<gael.guennebaud@xxxxxxxxx> wrote:
> Hi,
>
> I had a look too, and the FAQ really confuses me, especially the
> requirements 2 and 3 of this entry
> http://www.mozilla.org/MPL/2.0/FAQ.html#mpl-and-lgpl:
>
> 2 - The Larger Work must be "a combination of Covered Software with a
> work governed by one or more Secondary Licenses." So you can't just
> say "I really prefer (L)GPL" - you must have a need to combine with
> another, existing GPL work.

Correct.

> (This is different from a traditional
> dual-license, which does not require you to combine, and instead
> allows you to simply say "I've decided to be GPL-only.")
Without trying to get into a philosophical argument:
As not just a lawyer, but the guy in charge of making sure license
compliance happens, i can tell you that dual licensing is, for the
most part, a serious pain in the ass. Dual licenses require you to
make complicated legal tradeoffs, because you choose one, or the
other, and may have to switch back to the other half of the license
later in life.  Average users have significant trouble figuring this
out.    Because the license impacts everything, you have to understand
two licenses *all the time*, regardless of whether you are combining
the code with anything.
Single licenses that allow additional secondary licenses are much
better in this respect. For the average person, who isn't going to
combine it with GPL code, they only ever have to understand the MPL,
instead of two licenses (or three licenses).

If and when they do want to combine it with GPL code, the licenses
allows them to do so, and *only then* do they really have to
understand what both licenses mean.

It's the difference between gracefully scaling complexity, and shoving
it all in someone's face at once :)


>
> 3 - You must "additionally distribute" under (L)GPL. In other words,
> you must make the MPL-licensed source code available to your
> recipients under both MPL and (L)GPL.
Yes.
> Someone downstream from your
> recipients can then take under (L)GPL-only or MPL-only.
Yes, but more importantly, they can take under MPLv2, and still keep
the work license from fragmenting.

> This is
> different from a traditional dual-license, which never requires
> publication under both licenses, and so always gives you the option of
> releasing incompatibly-licensed code.

But you either must dual license all that code (IE publish under both
licenses), or now there are versions of your code floating around that
are under difference licenses, and users rights depends on where they
get the code from!

This is also possible with MPL2 but it's structure makes it
significantly less likely.
>
> 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.

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 :)


>
> gael
>
> On Thu, Jun 28, 2012 at 10:11 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Hi,
>>
>> 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:
>> http://www.mozilla.org/MPL/2.0/FAQ.html#mpl-and-lgpl
>>
>> 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
>> true:
>>  - 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?
>> Benoit
>>
>>
>
>