Re: [eigen] Important: Relicensing Eigen to MPL2

[ Thread Index | Date Index | More Archives ]

On Sun, Jan 15, 2012 at 7:02 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

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:



Some positive press:

*** 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

b) yes

but see below, I am in favor of BSD / MIT. 

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

a) Clearly a good thing.

LGPL is a legal minefield; the MPL2 is simpler. 
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).

c) Relicense to a liberal license (MIT/BSD)

I am in favor of an MPL2 relicense as well.
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

*** 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:

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.

The CeCILL is a bad choice for more than just the reasons listed above. Sticking to well known licenses is generally good. It's unfortunate that the MPL2.0 license is so new, since it is virtually unknown at this point.. The conservative side of me is a bit worried about that.
*** 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!

Yeah, it's scary.
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).

Yes, this is a nice property of the MPL2.
*** 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.

It's a good license for sure. Personally I still think BSD/MIT is a better choice for Eigen. I'll clean up my long and boring discussion about why I think MIT/BSD is a better choice for Eigen, and send it along soon.
Note that many questions about the MPL2 are answered in the MPL2 FAQ
linked at the beginning of this email.


Mail converted by MHonArc 2.6.19+