Re: [eigen] Important: Relicensing Eigen to MPL2

[ Thread Index | Date Index | More Archives ]

That's ok from my side


On 01/16/2012 04:02 AM, Benoit Jacob 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:
> announcement:
> FAQ:
> 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
> 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

Mail converted by MHonArc 2.6.19+