[eigen] Re: Important: Relicensing Eigen to MPL2

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

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.

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