|[eigen] Re: Important: Relicensing Eigen to MPL2|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen <eigen@xxxxxxxxxxxxxxxxxxx>
- Subject: [eigen] Re: Important: Relicensing Eigen to MPL2
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Sun, 15 Jan 2012 22:08:04 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=2EmguH2jmvtshfvXKB2eRWmykXplNb/ko2W3JwX4wpM=; b=ldhsmX6fPCmsavdEgpOBGOOopX00e2WFNdOI+XudHarQ0lKWp/3QD0bk8b2qU/uZ45 RZnmTlr5xd24Q94FZ7SxvJ0QtjzY/sJI7k/42g+cabyue5XXhiB4S2x21VsMK23nqkkW +wqAqS8J4pULKHt6qN9a9AJcdN+el8uwlGO7Y=
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
2012/1/15 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 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
> 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
> *** 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.