Re: [eigen] Re: Important: Relicensing Eigen to MPL2

[Bastien ROUCARIES <roucaries.bastien@xxxxxxxxx>]

On Mon, Jan 16, 2012 at 4:08 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> Some more precisions (hit send too fast):
>
> * Eigen currently contains some BSD-licensed code, like the Intel MKL
> backend. This can stay BSD-licensed. Likewise, if you feel strongly
> that you would prefer to contribute code under BSD license over MPL2
> license, this can be discussed on a case by case basis but it's safe
> to say that for self-contained parts, this should be OK.
>
> * Eigen currently contains some LGPL-licensed third-party code, in
> self-contained parts, like sparse solvers. This would have to remain
> LGPL, but being self-contained makes it not a big issue. It will just
> be a bit annoying to have to document this pitfall; if this becomes
> too big of an annoyance, we could always contact the authors and ask
> for permission to relicense their code.
>
> * Eigen can interact with GPL-licensed code like FFTW. Our
> understanding of the MPL2 license is that this is a non-issue: it
> would simply be the responsibility of the user to ensure that they
> comply with both the MPL2 and the GPL, if they use Eigen jointly with
> GPL-licensed libraries.

Quoting FSF:
Software under previous versions of the MPL can be upgraded to version
2.0, but any software that isn't already available under one of the
listed GNU licenses must be marked as Incompatible With Secondary
Licenses. This means that software that's only available under
previous versions of the MPL is still incompatible with the GPL and
AGPL.

Conclusion:
So please document in copying that indeed you are compatible with GPL.
Plain english text will alliviate some problem.

Particularly remember clause 8. of MPL 2
8. Litigation
-------------

 Any litigation relating to this License may be brought only in the
 courts of a jurisdiction where the defendant maintains its principal
place of business and such litigation shall be governed by laws of that
 jurisdiction, without reference to its conflict-of-law provisions.

In pratice it means that you force reolution of ambiguity
(http://contractman.blogspot.com/2010/04/ambiguity.html)

Because here a lot of people are french it is equivalent of the French
civil code L1156:
http://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT000006070721&idArticle=LEGIARTI000006436452&dateTexte=20120117

"On doit dans les conventions rechercher quelle a été la commune
intention des parties contractantes, plutôt que de s'arrêter au sens
littéral des termes."

So please document that your rationnal during the license change, and
that you keep GPL compatibility.

Bastien



> Cheers,
> Benoit
>
> 2012/1/15 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 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
>
>