Proposed policy change: permit use of LGPLed libraries

[Gervase Markham]

Mozilla is a large and complex codebase, made up of many parts we have
written and many parts where we leverage the work of others. Mozilla
(the organization) wants people to reuse our codebase to build their own
cool products - browsers, email clients and other things. Therefore,
keeping the copyright licensing status of the codebase simple has been
an important goal.

So, our unwritten licensing rule of thumb for the last decade is that we
have wanted to be able to say to potential downstream users of our code:
"OK with the MPL? Then you can use our stuff." Since 2004 or so, we have
also provided the option for people to use it under the LGPL or GPL, but
not at the cost of MPL-based simplicity.

This has meant that all code which goes into the core Mozilla products
has needed to be licensed under the tri-license (now MPL 2) or a license
compatible with all three parts of it - for a long time, basically MIT
or BSD, but now MPL 2 is Apache 2-compatible, Apache 2 as well.

However, there is a significant body of code available under the LGPL
which it would be very useful to be able to use. One current example is
LibUSB, which we could use to provide WebUSB support in B2G. Examples in
the past include Cairo (where we did manage to persuade upstream to make
a licence change; but this was difficult and is not always possible).

If we used libraries under the LGPL in Mozilla, our "rule of thumb"
would no longer be true. Downstream users would need to read and
understand both the MPL and the LGPL to make sure they met their
licensing obligations.

On the other hand, open source licensing is much better understood now
than it was a decade ago, and the LGPL is a common licence which legal
departments will have usually heard of and know about. So the downsides
of this are not as bad as they once were.

We therefore propose that we change our stance on the trade-off between
speed of development and licensing simplicity, and alter our policy to
permit Mozilla to include clearly-demarcated 3rd-party LGPLed libraries,
with appropriate labelling and reminders against accidental code-copying
to other parts of the codebase.

Comments on this proposal are welcome in the mozilla.legal discussion forum:
https://www.mozilla.org/about/forums/#legal

Gerv

[Hubert Figuière]

On 21/05/12 08:49 AM, Gervase Markham wrote:
> We therefore propose that we change our stance on the trade-off between
> speed of development and licensing simplicity, and alter our policy to
> permit Mozilla to include clearly-demarcated 3rd-party LGPLed libraries,
> with appropriate labelling and reminders against accidental code-copying
> to other parts of the codebase.

I do believe it is important here to specify the version. While I have
no problem with LGPLv3, some legal departments are scared away by it
because of the patent clause in it. (they are also scared of GPLv3)

This should be considered when evaluating the policy.


Hub

[Axel Hecht]

The example of libusb is interesting. I read that as: If a downstream
phone maker wanted to use b2g under the provisions of the mpl to bundle
it together with proprietory code under an EULA, they'd need to find a
replacement for that block of code?

Axel

[Gervase Markham]

On 21/05/12 18:46, Hubert Figuière wrote:
> I do believe it is important here to specify the version. While I have
> no problem with LGPLv3, some legal departments are scared away by it
> because of the patent clause in it. (they are also scared of GPLv3)
>
> This should be considered when evaluating the policy.

Can you be more specific? Are you talking about the legal departments of
potential users, of potential distributors, or of potential
contributors? What is the exact scenario about which they are worried?
And are there any public reports of these concerns?

Gerv

[Gervase Markham]

On 21/05/12 21:50, Axel Hecht wrote:
> The example of libusb is interesting. I read that as: If a downstream
> phone maker wanted to use b2g under the provisions of the mpl to bundle
> it together with proprietory code under an EULA, they'd need to find a
> replacement for that block of code?

No... why do you think that? Android comes with a EULA, but contains
both GPL and LGPLed parts. Anyone distributing B2G already needs to be
comfortable with both the GPL (for e.g. the Linux kernel) and (I
believe; tell me if I'm wrong) the LGPL.

Gerv

[Asa Dotzler]

On 5/21/2012 8:49 AM, Gervase Markham wrote:

> We therefore propose that we change our stance on the trade-off between
> speed of development and licensing simplicity, and alter our policy to
> permit Mozilla to include clearly-demarcated 3rd-party LGPLed libraries,
> with appropriate labelling and reminders against accidental code-copying
> to other parts of the codebase.

I approve of this message. When we have to balance making it easier for
Mozilla to build great products with making it easier for people to
re-use our codebase, I think making it easier for Mozilla should usually
win.

- A

[Hubert Figuière]

Legal departments in general.

I'm not in their shoes, I'm not a lawyer, although I believe this is
wrong, but some companies explicitly prohibit using (L)GPLv3 software
just because of the patent clause. And by using I really mean as a user
(like using Emacs).

Let alone contributing or redistributing.

Hub

[lma...@gmail.com]

We have an enterprise list that *I think* is used for ESR [1]. It may make sense to run this proposal by that list to ensure it's getting out to those eyes. In general, it's difficult to know what people are doing with the Mozilla code base. A licensing stance change can have ramifications upstream. I think it's prudent to publicize this well (ie. outside of dev-planning) to ensure that we shake out as many issues as possible before proceeding with this change.

Lawrence

[1]http://www.mozilla.org/en-US/firefox/organizations/faq/

[lma...@gmail.com]

On Tuesday, May 22, 2012 5:13:08 PM UTC-4, Hubert Figuière wrote:

[Gen Kanai]

On 5/22/12 10:11 AM, Asa Dotzler wrote:
> On 5/21/2012 8:49 AM, Gervase Markham wrote:
>

>> We therefore propose that we change our stance on the trade-off between
>> speed of development and licensing simplicity, and alter our policy to
>> permit Mozilla to include clearly-demarcated 3rd-party LGPLed libraries,
>> with appropriate labelling and reminders against accidental code-copying
>> to other parts of the codebase.

> I approve of this message. When we have to balance making it easier for
> Mozilla to build great products with making it easier for people to
> re-use our codebase, I think making it easier for Mozilla should usually
> win.
>
> - A

I also agree with the original proposal.

Gen

--
Gen Kanai

[Gervase Markham]

On 23/05/12 15:21, lma...@gmail.com wrote:
> We have an enterprise list that *I think* is used for ESR [1]. It may
> make sense to run this proposal by that list to ensure it's getting
> out to those eyes.

This has no legal ramifications for _using_ Mozilla software, or even
for changing it and distributing those changes within your organization.
So I'm not sure the occupants of the ESR list will have much to say
about it. But I will ask for them to be notified.

Gerv

[Gervase Markham]

On 22/05/12 22:13, Hubert Figuière wrote:
> Legal departments in general.
>
> I'm not in their shoes, I'm not a lawyer, although I believe this is
> wrong, but some companies explicitly prohibit using (L)GPLv3 software
> just because of the patent clause. And by using I really mean as a user
> (like using Emacs).
>
> Let alone contributing or redistributing.

Do you have any public evidence of this you can show me?

Gerv

[Hubert Figuière]

On 24/05/12 02:59 AM, Gervase Markham wrote:
> Do you have any public evidence of this you can show me?

Do you need? This is usually a company policy, and usually these
policies are not public for various reason.

Hub

[Gervase Markham]

On 24/05/12 18:30, Hubert Figuière wrote:
> Do you need? This is usually a company policy, and usually these
> policies are not public for various reason.

It's not really possible to work out the severity of a problem without
evidence that it exists. If you can't produce anything to back up your
claim, there is a danger that it sounds like FUD.

Gerv

[Hubert Figuière]

Then just ignore my comment if you think it is FUD.

Hub

[Mook]

(I apologize for replying mid-thread; the mirroring to NNTP appears to
be broken and I can't find the thread starting post.)

Will the LGPL code be limited to be outside of libxul? Because libxul
is special in that it's the only binary with access to
MOZILLA_INTERNAL_API, plus being the bulk of the code it is the most
likely to be changed (for example, Joost used to have patches for the
chrome protocol handler to only accept signed jars, I think, with their
actual crypto code in separate not-released files). If Mozilla ends up
needing LGPL code, and that code gets shipped in libxul, it ends up
meaning libxul itself is LGPL (as far as I understand how LGPL is
intended to work). Of course, if the LGPL code is limited strictly to
separate binaries this would not be a problem, except for the snappy
people (since that was part of the motivation behind having a giant
library in the first place, as I understand it).

Ideally, of course, we'd get a tier-one tinderbox for MPL-only builds to
make sure that doesn't break, but given releng resources I've seen that
seems unlikely ;)

Note: I'm looking at this from the point of view of a _desktop_
application developer; whether existing android builds require GPL/LGPL
code is irrelevant. From an Android/B2G point of view that would be
much different. And I suspect once LGPL code starts being accepted for
B2G, it'd be so much more tempting to use it for non-B2G as well...

--
Mook

[Gervase Markham]

On 27/05/12 02:52, Mook wrote:
> Will the LGPL code be limited to be outside of libxul?

I guess I had assumed that "clearly-demarcated 3rd-party LGPLed
libraries" meant that the library had to be a standalone lib which was
dynamically linked in, such that LGPLness did not affect any non-LGPLed
code. But in hindsight, perhaps that wasn't clear.

I'm sure it's true that a requirement for LGPLed code to be in its own
library (or perhaps we have one for all LGPLed code, I don't know) would
have effects on our build system and perhaps on performance. Those would
need to be taken into account when considering whether to use the LGPLed
code.

> chrome protocol handler to only accept signed jars, I think, with their
> actual crypto code in separate not-released files). If Mozilla ends up
> needing LGPL code, and that code gets shipped in libxul, it ends up
> meaning libxul itself is LGPL (as far as I understand how LGPL is
> intended to work).

Clarification: it would mean we'd need to obey the terms of the LGPL in
terms of the particular ways one makes source available etc. for all
code inside libxul. It wouldn't mean we'd need to change the licence of
the source code or their headers, because MPL2 is upwardly compatible
with LGPL. But I agree, we don't want to be in that place.

> Ideally, of course, we'd get a tier-one tinderbox for MPL-only builds to
> make sure that doesn't break, but given releng resources I've seen that
> seems unlikely ;)

I don't anticipate there being "MPL-only" builds; if we decided to
accept LGPLed code under this new policy, it would be fine for it to be
a required part of building e.g. Firefox.

Gerv

[Henri Sivonen]

On Mon, May 21, 2012 at 6:49 PM, Gervase Markham <ge...@mozilla.org> wrote:
> Mozilla is a large and complex codebase, made up of many parts we have
> written and many parts where we leverage the work of others. Mozilla
> (the organization) wants people to reuse our codebase to build their own
> cool products - browsers, email clients and other things. Therefore,
> keeping the copyright licensing status of the codebase simple has been
> an important goal.

Regardless of licensing, the decision to stop developing embedding
APIs on Mozilla-funded engineering time means that it's already hard
to reuse the code base except in ways that involve building the code
base with some added patches and non-Mozilla branding (e.g.
Iceweasel). Therefore, the licensing use case modeled on embedding
Gecko into the AOL client software might be moot because of technical
reasons already.

> We therefore propose that we change our stance on the trade-off between
> speed of development and licensing simplicity, and alter our policy to
> permit Mozilla to include clearly-demarcated 3rd-party LGPLed libraries,
> with appropriate labelling and reminders against accidental code-copying
> to other parts of the codebase.

Cool. I've always thought it was weird for Mozilla to avoid LGPLed libraries.

To avoid confusion, I think it's important to specify in the new
policy what versions of LGPL third-party code has to allow to be used
in order to be permissible in the Mozilla code base: for example,
whether an "or at your option any later version" choice is required
and whether it matters if the base version is 2.0, 2.1 or 3.

Personally, I have occasionally silently wondered why Mozilla upgraded
to MPL 2.0 instead of moving to LGPLv3 with "or at your option any
later version" choice. If/when Mozilla allows LGPLed third-party code
in the code base, it would probably good to have some kind of
documentation that explains why first-party code needs to be under MPL
2.0 in addition to being available under LGPLv3 (which it has ever
since the tri-license).

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

[Mook]

On 5/28/2012 2:29 AM, Gervase Markham wrote:
> On 27/05/12 02:52, Mook wrote:
>> Will the LGPL code be limited to be outside of libxul?
>
> I guess I had assumed that "clearly-demarcated 3rd-party LGPLed
> libraries" meant that the library had to be a standalone lib which was
> dynamically linked in, such that LGPLness did not affect any non-LGPLed
> code. But in hindsight, perhaps that wasn't clear.

Sorry, I thought that just meant "lives in /other-licenses or similar";
I had not initially interpreted it as "guaranteed to never live in the
same binary as the MPL code". If there's non-code restrictions in place
to keep the LGPL bits in separate binaries, it should be fine.
(Actually, I guess a libmozlgpl would be fine too, assuming that
satisfies the LGPL license enough.)

> Clarification: it would mean we'd need to obey the terms of the LGPL in
> terms of the particular ways one makes source available etc. for all
> code inside libxul. It wouldn't mean we'd need to change the licence of
> the source code or their headers, because MPL2 is upwardly compatible
> with LGPL. But I agree, we don't want to be in that place.

Yep, that was only in the context of making the MPL-only-binary option
unavailable; at that point the code might as well have been LGPL-only
(with its automatic GPL option) instead, since it wouldn't actually
build. But it sounds like this wouldn't be an issue anyway.

--
Mook

[Gervase Markham]

On 29/05/12 05:48, Mook wrote:
> Sorry, I thought that just meant "lives in /other-licenses or similar";

/other-licenses is deprecated; people keep sticking stuff in there that
shouldn't be there even under its original purpose. "LGPL" is a bit more
in line with what it was originally intended for, but at this point I'm
not convinced of the value of putting code somewhere away from code it's
related to in order to make a licensing point.

> I had not initially interpreted it as "guaranteed to never live in the
> same binary as the MPL code". If there's non-code restrictions in place
> to keep the LGPL bits in separate binaries, it should be fine.
> (Actually, I guess a libmozlgpl would be fine too, assuming that
> satisfies the LGPL license enough.)

Thanks for bringing up this point; we will make sure that it's clear
that this needs to be done.

Gerv

[Gervase Markham]

On 28/05/12 11:18, Henri Sivonen wrote:
> To avoid confusion, I think it's important to specify in the new
> policy what versions of LGPL third-party code has to allow to be used
> in order to be permissible in the Mozilla code base: for example,
> whether an "or at your option any later version" choice is required
> and whether it matters if the base version is 2.0, 2.1 or 3.

OK...

If I proposed "any of the above", would that be a problem?

> Personally, I have occasionally silently wondered why Mozilla upgraded
> to MPL 2.0 instead of moving to LGPLv3 with "or at your option any
> later version" choice. If/when Mozilla allows LGPLed third-party code
> in the code base, it would probably good to have some kind of
> documentation that explains why first-party code needs to be under MPL
> 2.0 in addition to being available under LGPLv3 (which it has ever
> since the tri-license).

There are several reasons; one of them is that companies wish to combine
our stuff with proprietary code (a usage model which Mozilla has always
enabled). This is harder with the LGPL because of the wider scope of its
copyleft.

Gerv

[Henri Sivonen]

On Tue, May 29, 2012 at 12:38 PM, Gervase Markham <ge...@mozilla.org> wrote:
> On 28/05/12 11:18, Henri Sivonen wrote:

>> To avoid confusion, I think it's important to specify in the new
>> policy what versions of LGPL third-party code has to allow to be used
>> in order to be permissible in the Mozilla code base: for example,
>> whether an "or at your option any later version" choice is required
>> and whether it matters if the base version is 2.0, 2.1 or 3.
>

> OK...
>
> If I proposed "any of the above", would that be a problem?

I was thinking that specifying LGPL 2.0 or LGPL 2.1 without "or, at
your option, any later version" would have been a problem for using
the whole code base under the GPL, since using the whole code base
under the GPL will, in practice, mean GPLv3 once the code base has
become dependent enough on Apache-license code. However, it appears
the section 3 of LGPL 2.0 and 2.1 not only allows upgrading from LGPL
2.x to GPLv2 but automatically allows upgrading to a later version of
the GPL. So maybe LGPL 2.0 or 2.1 without "or, at your option, any
later version" isn't a problem.

Curiously, section 2 of LGPLv3 does not include an explicit
always-active version upgrade clause as part of the upgrade clause to
GPL. Obviously, that isn't a problem as long as version 3 is the
latest version of the GPL. It's unclear if that could be a problem in
the future.

So no, I don't, at present, see a concrete reason why "any of the
above" would be a problem.

>> Personally, I have occasionally silently wondered why Mozilla upgraded
>> to MPL 2.0 instead of moving to LGPLv3 with "or at your option any
>> later version" choice. If/when Mozilla allows LGPLed third-party code
>> in the code base, it would probably good to have some kind of
>> documentation that explains why first-party code needs to be under MPL
>> 2.0 in addition to being available under LGPLv3 (which it has ever
>> since the tri-license).
>

> There are several reasons; one of them is that companies wish to combine
> our stuff with proprietary code (a usage model which Mozilla has always
> enabled). This is harder with the LGPL because of the wider scope of its
> copyleft.

How realistic will it be to combine first-party Mozilla code with
proprietary code in an LGPL-incompatible way once Mozilla first-party
code becomes dependent on LGPLed third-party code? (This a question.
This is not an objection to allowing LGPL. The success of WebKit shows
that LGPL-compliance isn't a show-stopper burden for combining a Web
engine with proprietary code.)

[Robert Kaiser]

Gervase Markham schrieb:

> Clarification: it would mean we'd need to obey the terms of the LGPL in
> terms of the particular ways one makes source available etc. for all
> code inside libxul.

That means we'd basically need to change the license we ship Firefox
(and other apps) under to be LGPL instead of MPL like now, right?

That could have wide-reaching repercussions, possibly (wider than BSD
not wanting to have us in their package repos).

Robert Kaiser

[Gervase Markham]

On 29/05/12 18:25, Robert Kaiser wrote:
> That means we'd basically need to change the license we ship Firefox
> (and other apps) under to be LGPL instead of MPL like now, right?

No. It would mean we'd need to obey the LGPL terms for a wider body of
code than just that which is explicitly LGPLed. The overall application
could still be under a licence of our choice.

But anyway, we are not contemplating doing this.

Gerv

[Gervase Markham]

On 29/05/12 12:31, Henri Sivonen wrote:
>> There are several reasons; one of them is that companies wish to combine
>> our stuff with proprietary code (a usage model which Mozilla has always
>> enabled). This is harder with the LGPL because of the wider scope of its
>> copyleft.
>
> How realistic will it be to combine first-party Mozilla code with
> proprietary code in an LGPL-incompatible way once Mozilla first-party
> code becomes dependent on LGPLed third-party code?

It depends what you mean by "in an LGPL-incompatible way". Assuming we
keep the LGPLed code in its own shared library, then the person doing
the combining will need to obey the terms of the relevant version of the
LGPL (e.g. making source available and, for LGPLv3 allowing the library
to be replaced etc.) for that code.

If the way they supply code to their customers doesn't comply with this,
they would need to change their practices/licence. Just as they might do
on the upgrade from MPL 1.1 to MPL 2, which has slightly different (and
easier to comply with) terms.

Gerv

[Henri Sivonen]

On Mon, May 21, 2012 at 6:49 PM, Gervase Markham <ge...@mozilla.org> wrote:
> However, there is a significant body of code available under the LGPL
> which it would be very useful to be able to use. One current example is
> LibUSB, which we could use to provide WebUSB support in B2G. Examples in
> the past include Cairo (where we did manage to persuade upstream to make
> a licence change; but this was difficult and is not always possible).

Other examples:
ffvp8 ( https://bugzilla.mozilla.org/show_bug.cgi?id=581773 )
GStreamer

[Gervase Markham]

On 21/05/12 16:49, Gervase Markham wrote:
> We therefore propose that we change our stance on the trade-off between
> speed of development and licensing simplicity, and alter our policy to
> permit Mozilla to include clearly-demarcated 3rd-party LGPLed libraries,
> with appropriate labelling and reminders against accidental code-copying
> to other parts of the codebase.

Thank you to everyone for their comments. We will go ahead with this
policy change, taking into account the issues raised in this group about
making sure LGPLed code remains contained.

So:

- Any version of the LGPL from 2.0 upwards
- "Or later version" allowed
- 3rd party code only
- Clearly-demarcated library
- Code must be compiled such that it is dynamically linked
- Code to live wherever in the tree is most appropriate

Gerv