Re: [eigen] Important: Relicensing Eigen to MPL2

[Rohit Garg <rpg.314@xxxxxxxxx>]

That's great. I am for it then.

On Sat, Jan 21, 2012 at 10:20 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 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
>>
>>
>
>



-- 
Rohit Garg

http://rpg-314.blogspot.com/

Graduate Student
Applied and Engineering Physics
Cornell University