Re: [eigen] Important: Relicensing Eigen to MPL2

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2012/1/21 Rohit Garg <rpg.314@xxxxxxxxx>:
> TL;DR
>
> I am not in favor of BSD/MIT/Apache etc.
>
> My criteria are
>
> a) Does MPL2 require redistribution of changes to Eigen itself?

Yes, but specifically only for the files that come from the
MPL2-licensed software. That's called file-level copyleft. So if you
make an improvement to Eigen's own files, and distribute software
based on that improved Eigen, you have to allow people to get these
Eigen improvements. If on the other hand you improve Eigen from the
outside (e.g. you add a new feature without modifying existing files)
then there is no copyleft requirement. In the case of Eigen, that
doesn't make much of a difference since my understanding of the LGPL3
Section 3 is that things were already working that way. But at least
it's much more explicit with MPL2, without room for corner cases.

>
> b) Can I use MPL2 licensed Eigen in a LGPL2/3 project? GPL2/GPL3 project?

Yes and yes. The MPL2 is GPL-compatible, contrary to the MPL1.

Benoit


>
> Regards,
> Rohit
>
> On Sun, Jan 15, 2012 at 10:02 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>> Hello,
>>
>> This is a proposal to relicense Eigen to the new MPL2 license. Like
>> the LGPL3+ that Eigen is currently licensed under, this is a
>> weak-copyleft license. However, it is simpler, shorter, clearer, more
>> general, and slightly more liberal with a clear file-level copyleft.
>>
>> the license:
>> http://www.mozilla.org/MPL/2.0/
>>
>> announcement:
>> http://mpl.mozilla.org/2012/01/03/announcing-mpl-2-0/
>>
>> FAQ:
>> http://www.mozilla.org/MPL/2.0/FAQ.html
>>
>> Some positive press:
>> http://blogs.computerworlduk.com/simon-says/2012/01/can-mozilla-unify-open-source/index.htm
>>
>>
>> *** Disclaimers ***
>>
>> 1. I'm a Mozilla Corporation employee and I've followed closely the
>> MPL2 process, and provided some input into it as I really wanted it to
>> become a great alternative to the LGPL. So I guess I'm biased about
>> the MPL.
>>
>> 2. This has already been discussed privately among a small group of
>> core Eigen contributors. I'm not going to try to represent other
>> people's opinions in this email, so please do reply to this thread to
>> (re-)state your opinion.
>>
>>
>> *** Main questions to answer ***
>>
>> While I'm interested in anything you may reply, here are the core
>> questions that I really want an answer to. I want to stress that they
>> are *separate* questions. These questions only concerns people who
>> have contributed code to Eigen. It's worth replying even if you only
>> have 1 line of code in Eigen.
>>
>> 1. Would you agree to a MPL2 relicensing of the code you've
>> contributed to Eigen?
>>    a) no
>>    b) yes
>>
>> 2. Would you personally consider such a MPL2 relicensing of Eigen a
>> good or a bad thing?
>>    a) Clearly a good thing
>>    b) Somewhat of a good thing
>>    c) Neither a good nor a bad thing
>>    d) Somewhat of a bad thing
>>    e) Clearly a bad thing
>>    f) Don't know
>>
>> 3. Which of the following courses of action would you consider the
>> best choice for Eigen?
>>    a) Keep current LGPL3+/GPL2+ license
>>    b) Relicense to MPL2
>>    c) Relicense to a liberal license (MIT/BSD).
>>    d) Relicense to some other license (please elaborate).
>>
>> Notice that the present MPL2 relicensing proposal would not exclude,
>> if accepted, a future relicensing when the time comes. So even if you
>> strongly believe that a BSD-style license would be better, please
>> consider not turning down the current MPL2 licensing proposal. We've
>> already discussed BSD-style licenses in the preliminary discussion and
>> it is clear that at this point there isn't consensus in favor of a
>> BSD-style relicensing, so it couldn't happen in the near/foreseeable
>> future.
>>
>>
>> *** What are the problems we're trying to solve, with the current
>> Eigen licensing? ***
>>
>> 1. Excessive complexity of the LGPL is scaring away potential users
>>
>> Just one example: When I wrote the Eigen Licensing FAQ, I sincerely
>> believed that LGPL users wouldn't have to read and worry about the GPL
>> license (notice that the LGPL is an addendum to the GPL). That turned
>> out to be wrong: Section 1 of the LGPL only dispenses from Section 3
>> of the GPL, but users still have to read and understand the rest of
>> the GPL. So when measuring the length and complexity of the LGPL, one
>> has to add it on top of the GPL. That makes it one of the biggest of
>> all licenses. Here's a table of word counts of some popular licenses:
>>
>> bjacob@cahouette:~/licenses$ wc -w * | sort -g
>>  220 BSD-3-clauses.txt
>>  2435 MPL-2.0.txt
>>  5644 GPL-3.0.txt
>>  6878 LGPL-3.0-combined-with-GPL.txt
>>
>> Another aspect is that while Section 3 of the LGPL3 makes it quite
>> liberal in Eigen's case, that is indeed quite specific to Eigen's case
>> (headers-only libraries) and doesn't match the lesser liberality of
>> the LGPL3 in other cases (say, binary libraries, see Section 4). This
>> means that it takes a large amount of pedagogy to make people
>> understand that LGPL3 is fine for Eigen, and often, enterprise lawyers
>> are not interested.
>>
>> 2. The LGPL doesn't allow some things that we need to allow
>>
>> For example, the LGPL doesn't apply well to documentation. This is a
>> problem for us, as we would like to use the same license for
>> documentation, examples, and real Eigen code (see threads on this list
>> about documentation licensing).
>>
>>
>> *** OK, so the LGPL isn't great. What are the other licenses we can
>> choose from? ***
>>
>> One obvious answer is "BSD/MIT" but it is clear from private
>> conversations that there is opposition to that from a very significant
>> part of the project members. So while I can't rule out the possibility
>> that we'd some day relicense to such liberal licenses, this can't
>> happen in the near/foreseeable future. We need a better license than
>> the LGPL, sooner.
>>
>> The LGPL is a weak-copyleft license. In order to get relicensing
>> consensus fast, we need to stay within the bounds of the
>> weak-consensus realm. The only somewhat widespread weak-copyleft
>> licenses that I know, are:
>> * LGPL
>> * MPL
>> * CeCILL-C
>>
>> The CeCILL licenses are made by INRIA, which is Gael's employer. We've
>> briefly looked at them, CeCILL-C is a somewhat decent LGPL
>> alternative, but it's clear enough that it's less good than MPL2, that
>> I don't a priori see the need to elaborate here. Let's just say:
>> longer, less clear definitions/phrasing, tied to French juristiction,
>> arguably less well-known internationally.
>>
>>
>> *** How is the MPL2 better? ***
>>
>> 1. The MPL2 is 2.8x shorter than the LGPL (including GPL, of which it
>> is an addendum), see above table.
>>
>> 2. The MPL2 is much better written than any other copyleft-ish license
>> I've seen. See for example these definitions from the MPL2:
>>
>>    1.6. “Executable Form”
>>
>>       means any form of the work other than Source Code Form.
>>
>>    1.13. “Source Code Form”
>>
>>       means the form of the work preferred for making modifications.
>>
>> Now if we compare to the GPL ( / LGPL), at first they look very similar:
>>
>>  The "source code" for a work means the preferred form of the work
>> for making modifications to it.  "Object code" means any non-source
>> form of a work.
>>
>> Except that they then proceed to talk about "executable works" without
>> having defined _that_ term!
>>
>> 3. As a consequence of 2., the MPL is readily suitable for
>> documentation (and examples) contrary to the LGPL / GPL. Indeed, its
>> definitions of "source code" and "executable" forms are not specific
>> at all to programs. And indeed, Mozilla has long been using the MPL
>> for documentation and plans to do so with the MPL2 as well.
>>
>> 4. The MPL2 has a much simpler concept of copyleft. It's called
>> file-level copyleft, and basically means that copyleft doesn't
>> propagate across file boundaries. This should do wonders to ease
>> concerns of people who worry about what they call "virality" (a term
>> that I loathe).
>>
>>
>> *** Why did we never consider the MPL1? ***
>>
>> For several reasons, the MPL1 wasn't a very compelling license for
>> non-Mozilla projects. For example, it had a clause requiring legal
>> disputes to be resolved under Californian jurisdiction...
>>
>>
>> *** Should we relicense to MPL2-only or tri-license MPL2/LGPL/GPL? ***
>>
>> We should do MPL2 only. Mozilla has been tri-licensing MPL/LGPL/GPL
>> for a while and that is considered a big mistake. It allowed people to
>> screw us by forking mozilla code and releasing it under GPL only,
>> preventing us from using it.
>>
>> Mozilla plans to switch from MPL/LGPL/GPL to MPL2 only, and the MPL2
>> has been designed explicitly to allow that, so we know we're not in
>> uncharted territory with this relicensing.
>>
>>
>> *** But the MPL is not a well-known-enough license! ***
>>
>> Hard to tell: to some people it's very well-known, to some people it
>> isn't. Recently, a large software company contacted us, spontaneously
>> asking if we'd accept to relicence to MPL2, completely independently
>> from our ongoing discussions! They weren't deterred by the recentness
>> of the MPL2, saying that it was very close in spirit to the MPL1.
>>
>> I believe that the MPL2 is the only well-written, concise, no-nonsense
>> copyleft license, so I expect it to gain a lot of traction within the
>> copyleft world. Of course, copyleft != FOSS.
>>
>> Note that many questions about the MPL2 are answered in the MPL2 FAQ
>> linked at the beginning of this email.
>>
>> Cheers,
>> Benoit
>>
>>
>
>
>
> --
> Rohit Garg
>
> http://rpg-314.blogspot.com/
>
> Graduate Student
> Applied and Engineering Physics
> Cornell University
>
>