Why I'm not a fan of the tri-license
Robert O'Callahan
be compatible with the GPL, LGPL and MPL. This typically means it has to
come dual-licensed LGPL/MPL, or have a very permissive license like BSD
that is compatible with all three. Very little code starts with an
LGPL/MPL dual license, so in all the cases I'm aware of where we've
imported code, we've either persuaded people to relicense LGPL code to
offer the MPL as well (cairo), or the license was BSD-like (everything
else).
Persuading people to relicense their code is generally quite hard. I
also think it's a bit unfriendly. For many projects it's simply not a
realistic option.
Therefore, we have a situation where the tri-license strongly encourages
us to use and support projects that are BSD-licensed over projects that
use other licenses such as LGPL. I find this troubling because we
clearly think some kind of copyleft is desirable --- every one of our
three licenses has some form of copyleft --- yet our license
compatibility issues create pressure *against* copyleft for third-party
libraries that we use.
Since we're in the process of updating the MPL, I guess it's not going
away anytime soon. I just want people to be aware of these consequences.
Rob
Axel Hecht
code. Both for what that license intends to do (putting folks like us
into trouble, first and foremost), and for what the organization behind
it does (relicensing of wikipedia for example).
Axel
Asa Dotzler
> Therefore, we have a situation where the tri-license strongly encourages
> us to use and support projects that are BSD-licensed over projects that
> use other licenses such as LGPL. I find this troubling because we
> clearly think some kind of copyleft is desirable
Do we all really still believe that? Or is that just thinking from 12
years ago before anyone really knew how things would play out over a
decade or more.
I'm personally not a big copyleft fan. I may be a tiny minority in the
Mozilla community (a minority of one?) but I don't think it's
necessarily correct to start this discussion with the assumption you have.
I know this is contentious and people are very passionate (and correctly
and reasonably so) on both sides. I just want to make sure that we don't
assume away one side (especially since it happens to be my side) at the
beginning of the conversation.
- A
Mike Shaver
> I know this is contentious and people are very passionate (and correctly and
> reasonably so) on both sides. I just want to make sure that we don't assume
> away one side (especially since it happens to be my side) at the beginning
> of the conversation.
I agree. What is clear is that we wanted a copyleft in 1998; I think
it's not quite right to assume that our position is necessarily the
same today, given more than a decade of experience and changing
context.
The strongest "copyleft" in terms of getting contribution back is
having a vibrant and active community and "core project". People who
want to defeat copyleft have many options, especially in the brave
multi-process world.
If *I* (speaking personally, not as VP Engineering) had a magic wand,
I would wave it and make all our stuff be MIT. The code that gets the
most contributions (including feedback and bug reports) is the code
that gets used the most, and MIT is what gets that. It's also the
code that is most used by others, and therefore can deliver the most
value to the world. (That's why our code samples on MDC are MIT, for
example.)
I'm not saying, either, that we should remove the copyleft elements
from the MPL or anything. In some ways, the MPL's nature and our
choices about how to use it are a bit distinct here.
Mike
L. David Baron
> I'm personally not a big copyleft fan. I may be a tiny minority in
> the Mozilla community (a minority of one?) but I don't think it's
> necessarily correct to start this discussion with the assumption you
> have.
I don't think either side is a tiny minority, as I think I've heard
a decent number of opinions on both sides (regarding copyleft) over
the years.
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Mitchell Baker
> On Friday 2010-03-26 16:01 -0700, Asa Dotzler wrote:
>> I'm personally not a big copyleft fan. I may be a tiny minority in
>> the Mozilla community (a minority of one?) but I don't think it's
>> necessarily correct to start this discussion with the assumption you
>> have.
>
> I don't think either side is a tiny minority, as I think I've heard
> a decent number of opinions on both sides (regarding copyleft) over
> the years.
>
> -David
>
I'm currently of David's view. The MPL process may prove us wrong, but
(of course) i think not. Axel would jump for joy to use the GPL, but
lots of people would jump for joy to use Apache. Splitting ourselves
apart on this issue does not seem like a win.
We will look into GPL compatibility with some mechanism other than the
tri-license. I don't know if this is possible yet but there has been a
bunch of thinking about this since we adopted the tri-license.
And just to be clear, I have *always* hated the tri-license, from the
moment I first heard (after it had been approved, while I was on
maternity leave) to today. I would love to get rid of it too. But not
so much that I'm eager to start a GPL vs. Apache fight. Maybe we'll
find Mozilla contributors don't care or have all migrated to one end of
the spectrum, but I would be surprised.
Robert O'Callahan
> I'm personally not a big copyleft fan. I may be a tiny minority in the
> Mozilla community (a minority of one?) but I don't think it's
> necessarily correct to start this discussion with the assumption you have.
I'm not assuming that copyleft is what we currently want. I'm just
observing that our license structure encourages copyleft for our own
code but effectively discourages it for third-party code.
Rob
Robert O'Callahan
to incorporating LGPL libraries into Gecko.
We currently insist that all code we ship in Firefox be usable under the
GPL, LGPL and MPL, correct?
If so, what is the rationale for insisting that all the code we ship be
usable under the MPL and GPL? Do we have downstream consumers who would
not be satisfied with the LGPL? Are we not satisfied with the LGPL?
Rob
Mike Shaver
> We currently insist that all code we ship in Firefox be usable under the
> GPL, LGPL and MPL, correct?
No, we provide that if you abide by the terms of the MPL, you can use
all of the code we ship. That's the baseline guarantee; GPL and LGPL
are additional niceties to permit our code to be used by more projects
downstream.
I don't believe that we're satisfied by the LGPL. (TBH I'm not sure I
even know what it really means in context of a program that is
dynamically linked together from multiple processes and libraries at
runtime, or what "ability to relink" means. It also lacks the
strength of the MPL's patent language.)
Mike
Axel Hecht
And I just forgot a "not" in my sentence. Blame me for trying to write
something not-so-offensive in the middle of the night. FTR, I'm not fond
of the GPL.
Axel
Mitchell Baker
>
> And I just forgot a "not" in my sentence. Blame me for trying to write
> something not-so-offensive in the middle of the night. FTR, I'm not fond
> of the GPL.
>
> Axel
And I just forgot a "not" in my sentence. Blame me for trying to write
something not-so-offensive in the middle of the night. FTR, I'm not fond
of the GPL.
Axel
LOL :-) thanks for clarifying!
timeless
> I'm personally not a big copyleft fan. I may be a tiny minority in the
> Mozilla community (a minority of one?) but I don't think it's necessarily
> correct to start this discussion with the assumption you have.
If I understand orientations correctly, I'm with you.
Max Kanat-Alexander
> If *I* (speaking personally, not as VP Engineering) had a magic wand,
> I would wave it and make all our stuff be MIT.
I agree with you, although I might prefer a license with explicit
patent protection over the simple MIT license. But the more permissive,
the better--particularly, whatever gets us compatibility with the most
other licenses.
One could in fact incorporate a clause into a new version of the MPL
itself allowing relicensing under a more permissive license, which would
be that magic wand. One simply says "We have opted to distribute this
under the newer MPL. Now, we have opted to relicense this more
permissively."
-Max
timeless
<mka...@bugzilla.org> wrote:
> One could in fact incorporate a clause into a new version of the MPL
> itself allowing relicensing under a more permissive license, which would
> be that magic wand. One simply says "We have opted to distribute this
> under the newer MPL. Now, we have opted to relicense this more
> permissively."
While one could do that, depending on how 'more permissively' (and i
don't think there are too many gradations) it would be a violation of
trust, and would thus probably not be a good idea.
Remember that MPL is not merely something used in code hosted at
mozilla.org, and updating _The_ MPL license affects all MPL licensed
code. While we could try to write a replacement MPL which is not an
update to The MPL, I think it's fairly safe to say we don't want to do
that, as it would mean absolutely no magic wand and we'd have to go
about another round of approvals from all contributors, at which point
if we wanted a looser license, we'd just as soon pick one.
Gervase Markham
> If *I* (speaking personally, not as VP Engineering) had a magic wand,
> I would wave it and make all our stuff be MIT. The code that gets the
> most contributions (including feedback and bug reports) is the code
> that gets used the most, and MIT is what gets that. It's also the
> code that is most used by others, and therefore can deliver the most
> value to the world.
I think "most used --> most value" is the BSDers viewpoint, which would
be challenged by the copylefters, who might argue that the greater value
is in downstream users being given the same freedom that upstream users
have. (I note this because I think it's important we don't hide a
conclusion in a starting assumption.)
> (That's why our code samples on MDC are MIT, for
> example.)
I agree that we made them MIT to allow the widest possible use, but I'd
also say that it's not necessarily true that the trade-offs one makes
for code samples are the same as the trade-offs one makes of entire
application codebases.
Gerv
Gervase Markham
> One could in fact incorporate a clause into a new version of the MPL
> itself allowing relicensing under a more permissive license, which would
> be that magic wand. One simply says "We have opted to distribute this
> under the newer MPL. Now, we have opted to relicense this more
> permissively."
As timeless says, I think people (including me) would argue strongly
that this would be a violation of trust. The MPL has a "middle ground"
approach between BSD-like and GPL, and proponents of both licensing
schemes work together on it. Saying "actually, anything MPLed can now be
BSDed".
(This is not a parallel situation to our previous relicensing, which
added the option of greater copyleft. BSD-minded people are (or should
be, if they are being consistent) happy with GPLed projects using their
code, because they are happy with _any_ projects using their code. GPL
people, OTOH, are not happy with the copyleft being stripped from their
code, as would happen if the permissions moved the other way.)
Gerv
Gervase Markham
> Therefore, we have a situation where the tri-license strongly encourages
> us to use and support projects that are BSD-licensed over projects that
> use other licenses such as LGPL.
This is an entirely true observation.
> I find this troubling because we
> clearly think some kind of copyleft is desirable --- every one of our
> three licenses has some form of copyleft --- yet our license
> compatibility issues create pressure *against* copyleft for third-party
> libraries that we use.
This isn't necessarily inconsistent. If code is packaged as a library,
there are arguments for using a weaker copyleft for it, This is why the
LGPL was originally created, and called the Library GPL, although the
FSF has had a change of mind on this issue. So therefore, it's not
inconsistent to use a moderate copyleft for your project but only take
libraries under no-copyleft licences.
Having said that, the fact is that the MPL is in an odd place with
relation to the "upwards compatibility" stream of modern FOSS licences:
MIT -> BSD-like -> Apache 2 -> LGPL 3 -> GPL 3 -> AGPL 3
|
-> MPL
(Where A -> B means "projects using licence B can use code licensed
under A")
This is something the MPL revision process will hopefully address.
> Since we're in the process of updating the MPL, I guess it's not going
> away anytime soon. I just want people to be aware of these consequences.
BTW, I would point out the mozilla.governance.mpl-update group:
http://www.mozilla.org/community/developer-forums.html#governance-mpl-update
to anyone interested in commenting on the current or future MPL. Also:
http://mpl.mozilla.org/
Gerv
Amey Bhatkar
i think google is beter than microsoft
John J Barton
> Let me ask a few questions to help me understand what the barriers are
> to incorporating LGPL libraries into Gecko.
> Do we have downstream consumers who would
> not be satisfied with the LGPL?
I work at IBM. a company with significant contributions to and
downstream uses of open source software. This comment is just based on
my personal experience in working with corporate issues involving
licenses. (If anyone is interested I could find an official IBM person
to comment).
Any corporate contribution to open source depends on identifying
benefit; any corporate project based on open source software must have
potential benefit significantly greater than the risk times impact of
legal action. The central problem with LGPL is its well-known ambiguity.
Because technical people cannot agree on the precise definition of
'library' or other terms of the LGPL, lawyers consistently rate LGPL as
a serious hazard. For LGPL, technical people cannot argue that the risk
is low. Consequently technical people in established corporations avoid
being interested in LGPL projects.
jjb
Jean-Marc Desperrier
> [...] LGPL. (TBH I'm not sure I
> even know what it really means in context of a program that is
> dynamically linked together from multiple processes and libraries at
> runtime, or what "ability to relink" means
LGPL 3 has made this clearer : the user must given the means to use the
software with a updated/modified version of the LGPL covered code.
Dynamic libraries where you can just overwrite the dynamic library with
the newer version obviously comply, but providing linkable object files
together with the appropriate instructions for the linking process is
also acceptable.
Robert O'Callahan
> This isn't necessarily inconsistent. If code is packaged as a library,
> there are arguments for using a weaker copyleft for it, This is why the
> LGPL was originally created, and called the Library GPL, although the
> FSF has had a change of mind on this issue. So therefore, it's not
> inconsistent to use a moderate copyleft for your project but only take
> libraries under no-copyleft licences.
Gecko is often used as a library too.
Rob