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

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Thanks a lot Daniel and Benoit for the detailed explanation. Now, I
much better understand all this logic.

I've to admit I also missed the '10-line requirement' of the LGPL. One
more reason to switch. (L)GPL are really scary.

gael

On Thu, Jun 28, 2012 at 11:55 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2012/6/28 Daniel Berlin <dannyb@xxxxxxxxxx>:
>> On Thu, Jun 28, 2012 at 5:02 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> Hi Daniel,
>>>
>>> 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)?
>>
>> No, because in practice, the LGPL is harder to comply with than MPL2.
>> In eigen's case, it's even weirder to comply with
>> For example, we either have to verify everything in eigen falls under
>> LGPLv3 section 3, which means checking the length of every inline
>> function and template (since LGPLv3 says 'inline functions and
>> templates (ten or fewer lines in length)'),
>
> Ouch. I had never noticed that 10-line requirement. Had I noticed it,
> I wouldn't have advocated the LGPL3 in the way I have.
>
> The other part I was missing above (whence my uninformed question) was
> the difference between Larger Work and Covered Software. According to
> 3.3, the MPL only applies to Covered Software; I misread 3.3 as saying
> that the MPL would cover the whole Larger Work. Now I get it --
> thanks.
>
>
>> and either disallowing
>> people from using the ones that are longer, or saying it falls under
>> section 4, which would require using a suitable shared library
>> mechanism (at least for us), which would mean building a shared lib
>> just of eigen using stub files, etc.
>
> It's impressive to hear the things that (L)GPL forces people to do in
> practice... thanks for sharing these insights.
>
> Benoit
>
>>
>>
>>
>>>  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) ?
>>
>> I doubt this is the case. I actually know of several folks who don't
>> use eigen *because* it's LGPLv3, and the issues i mentioned above.
>>
>>>
>>> Benoit
>>>
>>>>
>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
>