|Re: [eigen] Relicensing Eigen|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Relicensing Eigen
- From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
- Date: Thu, 28 Jun 2012 20:44:50 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=MJy2QkC7AFkBZaiA/a1MvPdAsG1XlZTsiav7YTZgfq0=; b=PqmGb62rSxCJQxNKE7KdN7DmFbA1/5vLoOPs5F8vN26ifFJ/yTvxKJ7eSVUlDDrHMy iuu2NsrXfPgiCjmC/V2TKR/T0o8/932cdZlghCXGk54hN8lJZGfS+x9w+B4j9GPf18zj hTun2wHZaVKq+j54yHqRmTU/f8YjCTp4jOG+yv2YoixW/44vRQTUgnzYqviAFCO27sut Ap49K/hfF+dMpqEvQ5/n5iLFKTyWro+g+c8cVvGbaIjb+2RD/zguoN+q4Gt9ZqhWfPSY yrYzKRrgL/pD5HBLjjNyYmnQDUNAcchC/rEPAm2fSuUvHQx+TNRzxV9Z+kraFmf9c0CG XD1w==
I'll break the news: I'm leaning in that direction as well too!
Here is a bit of wisdom that a few colleagues at Mozilla agree on:
- If your competitors are mostly closed-source, then it makes sense
to be GPL to protect yourself. Killer example: Linux.
- If your competitors are mostly open-source, then it makes sense to
use a liberal license to share more (more "coopetition"), have a more
central place in the ecosystem.
So in fact, many engineers at Mozilla prefer BSD-style licenses. But
when you're a large project and you've been MPL1/LGPL/GPL for 10+
years, you probably can't conceivably get enough consensus to
relicense to BSD.
I'm not unhappy at all with the MPL2 though: the MPL2 is at least the
most pain-free of the weak-copyleft licenses (that I know of), it is
free of the unneeded pain found in (L)GPL licenses and, to a lesser
extent, the MPL1. So I'm really glad that it exists, as it at least
offers a nice path for improvement for all the existing copyleft
projects, and as I said above, I still believe that for many projects,
copyleft is the right choice (projects competing primarily with
closed-source projects). If the MPL2 can win many other currently
(L)GPL projects, that will certainly help avoid a lot of headaches.
2012/6/28 Marcus D. Hanwell <marcus.hanwell@xxxxxxxxxxx>:
> On Thu, Jun 28, 2012 at 5:29 PM, Keir Mierle <mierle@xxxxxxxxx> wrote:
>> On Thu, Jun 28, 2012 at 1:56 PM, Daniel Berlin <dannyb@xxxxxxxxxx> wrote:
>>> On Thu, Jun 28, 2012 at 4:27 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
>>> > 2012/6/28 Daniel Berlin <dannyb@xxxxxxxxxx>:
>>> >> I'm also happy to put you in touch with Luis Villa, who was
>>> >> responsible for much of the MPLv2 process
>>> > Actually... I have been in touch with the MPL2 team at Mozilla (I work
>>> > at Mozilla but not on legal stuff).
>>> Sorry, wasn't aware ;)
>>> > But since the MPL2 FAQ already
>>> > says that the MPL2 is GPL-compatible, it's hard for me to phrase a
>>> > precise question. My real issue has been that the MPL2 FAQ isn't easy
>>> > enough to grasp for a non-lawyer on this particular point.
>>> Honestly, no licenses are.
>>> License compatibility is a difficult thing, even for experienced open
>>> source lawyers.
>>> > Now that I
>>> > understand the mechanics at hand, I understand that it's hard to
>>> > explain in a simpler way, as the mechanism is actually non-trivial.
>>> > (The way in which the licensing of "Larger Works" subtly differs from
>>> > plain dual-licensing, as explained in the FAQ).
>>> FWIW, this exact conversation you are all having right now is why
>>> Google has generally taken a hard stance on approving more OSI
>>> licenses. It's not that we think particular license are good or bad,
>>> it's than when you combine code from 30 licenses, which is more and
>>> more common these days, figuring out the licensing results are a
>>> complete and utter mess.
>> Ultimately, this is part of what drove me to pick BSD/MIT for all my
>> personal projects. Less hassle, more coding, more users.
> This is where I have headed too, and I now work at a company with that
> same stance (mainly BSD with one or two Apachev2 licensed projects).
> The science and coding is hard enough without having to worry about
> license compatibility/compliance ;-)