Mozilla and Non-Copyleft Licensing

[Gervase Markham]

[Starting in .governance, .legal and .dev.planning for wide notification
- follow-ups to .legal, please]

[tl;dr: starting a discussion about the appropriate role of non-copyleft
licenses with respect to Mozilla-originated projects.]

For a long time now, the Mozilla License Policy[0] has said,
paraphrasing, that new codebases written by Mozilla should use the
MPL[1]. (When we contribute to projects created by others, we have a
policy of using the licence which that project uses.)

Reality does not entirely agree[2]. Over the last few years, some new
codebases have been created under various non-copyleft licences, such
the BSD licence and Apache License 2.0. Examples include many of our
websites, shumway, and Gaia.

The MPL was created as an intermediate stage between the copyleft of the
GPL and the non-copyleft of licences like the BSD license. It has served
us well in that role for many years.

It has been argued that copyleft, such as that in the MPL, is not
particularly useful in the case of websites, because the MPL contains no
source distribution requirement for network apps. The question of adding
such a requirement was specifically excluded from the scope of the MPL 2
discussions. However, as we move more towards mobile "web apps", where
significant amounts of the code do live on end-user devices, copyleft
has become more relevant again.

Copyleft is a tool which we use to achieve particular ends. The
leadership of some Mozilla projects, such as Gaia and AMO, have decided
that it is not the best route to success, as they define it, for their
projects.

So, the first question is: if use of non-copyleft licenses has become a
practice, is it a good practice? We should revisit why Mozilla chose
copyleft of "MPL strength" in the first place and whether those reasons
still apply today, and if so, in what context.

Secondly, if we decide that there is a reasonable and valid demand in
the Mozilla community to allow projects to choose non-copyleft
licensing, which licence(s) should we permit? Should we just allow
people to choose any open source licence? Or any popular one? Or should
we be more prescriptive?

One excellent feature of the MPL is that it offers a level of patent
protection to contributors. Patents are rapidly becoming even more of a
factor in software development, and anything we can do to protect our
software ecosystems from the damage caused by patent lawsuits is worth
it. This particularly applies to communities where large numbers of
competing companies may be taking part - such as B2G. The licensing team
is strongly of the opinion that patent protection is an essential part
of a modern open source licence.

The equivalent non-copyleft licence to the MPL, in this regard, is the
Apache License 2.0[3]. It, like the BSD and MIT licences, is
upwardly-compatible with the new MPL 2, but unlike those two licences
features a patent protection clause to give companies contributing to a
shared Apache 2.0 codebase confidence that other contributors will not
turn around and sue them.

My proposal therefore is this:

0) We should attempt (although this may be difficult) to reach consensus
on what sort of projects are best served by what sort of licences, and
what scope of copyleft.

1) We should update the licence policy to permit, via consultation with
the licensing team, use of either the Apache License 2.0 or the MPL 2.0
for projects. The exact decision process here would depend on the
outcome of 0).

2) We should clearly and by name forbid the use of other licences for
Mozilla-originated codebases, without specific permission and in
exceptional circumstances.

3) We should talk to existing Mozilla projects which are using BSD and
MIT and see if there are particular reasons for not using the Apache
License. If there isn't, we should transition; if there is, we should
evaluate those reasons against our licensing goals.

Gerv

[0] http://www.mozilla.org/MPL/license-policy.html
[1] http://www.mozilla.org/MPL/
[2] https://wiki.mozilla.org/License_Policy/Mozilla_Project_Licensing
[3] http://www.apache.org/licenses/LICENSE-2.0.html

[Rubén Martín]

Hi Gerv,

I think it would be easier to follow for non-licensing-experts if we
could get a brief summary (or table) about the differences between each
license. Sometimes it's complicated to perceive the differences you have
commented.

Regards.

--
Rubén Martín [Nukeador]
Mozilla Reps Mentor
http://www.mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

[Gervase Markham]

On 18/01/13 22:22, Rubén Martín wrote:
> I think it would be easier to follow for non-licensing-experts if we
> could get a brief summary (or table) about the differences between each
> license. Sometimes it's complicated to perceive the differences you have
> commented.

Are there particular areas in which it would help to have the
differences highlighted? A complete answer to that question would be
rather long :-)

In terms of the amount of copyleft, free software licenses range from
"no copyleft" (MIT, BSD, Apache) to "file-level copyleft" (MPL) to
"library-level copyleft" (LGPL) to "application-level copyleft" (GPL).

This discussion relates primarly to the "no copyleft" category.

1) Do we think there are circumstances under which it is best for
Mozilla to release software under a "no copyleft" (a.k.a. "permissive")
license? If so, what are they?

2) If there are such circumstances, what "no copyleft" license should we
use? (With the licensing team recommending Apache.)

3) If we decide on Apache as our "no copyleft" license, what do we do,
if anything, about existing projects which are BSDed or MITed?

Gerv

[David Ascher]

> 1) Do we think there are circumstances under which it is best for
> Mozilla to release software under a "no copyleft" (a.k.a. "permissive")
> license? If so, what are they?

There are two kinds of reasons motivating a copyleft requirement in a software release: moral ones, and pragmatic ones.

I'm not particularly motivated by moral arguments, at least when it comes to something like open source software. I am driven by a pragmatic desire to pick the license that is most likely to achieve the goals of a particular project. (And realize that in an open source community, where contribution is important, some licenses attract contributors who _do_ have a moral stance, which is fine).

In the context of an end-user product like Firefox, I always understood the copyleft part of the MPL to be about

- encouraging contributions
- making it slightly harder for someone to take Firefox and fork it "for evil".

In the late 90s, the world was different. In particular, open source was new, and licensing as a way to "force" people to contribute seemed reasonable (at least to me).

In 2013, I have to say I find the copyleft clause much less interesting or valuable, because:

- open source has evolved, and IMO social pressure is a much more effective way to build an actual community of contributors than licensing restrictions
- we know that bad guys will fork Firefox and turn it into malware, and that copyright is a better tool for reigning them in than licensing law. (I'm not talking about open source forks, which are fine)
- history (e.g. DVCS'es, github) has shown (IMO) that encouraging forking ends up resulting in more code being published than focusing on merging.

Furthermore, for a lot of the code we write and publish, there's no "problem" with people taking some code and repurposing it in some random other bits of software.

So, from a pragmatic POV, I'm less interested in copyleft clauses than I was a decade ago.

In addition, the MPL isn't a "trendy" license -- MIT, BSD, Apache are all more widely / better understood. MPL2 is (IMO) much better, and if we'd had a time machine and released MPL2 back in 1999 or whatnot, the world might be different today, but pushing MPL2 externally at this point doesn't feel high-value.

Where I end up therefore is that picking a license that minimizes the barrier to adoption & contribution is pretty high on my list of criteria. I have no strong opinion w.r.t. MIT vs BSD vs Apache, as in my experience they're often interchangeable in that pursuit. YMMV, especially if the code has to integrate in an existing community.

--da

[Gijs Kruitbosch]

On 21/01/2013 22:31 PM, David Ascher wrote:
> we know that bad guys will fork Firefox and turn it into malware, and that copyright is a better tool for reigning them in than licensing law
>

Did you mean to say "trademarks"? Or did I miss something WRT copyright helping
us fight against malware forks?

~ Gijs

[dascher]

I meant trademark indeed, thanks for the correction. 

-- da
(typed with thumbs)

[Justin Dolske]

On 1/21/13 1:31 PM, David Ascher wrote:

> - we know that bad guys will fork Firefox and turn it into malware

I don't think malware is the concern, or even people forking with evil
intent. There are plenty of people and companies doing cool and good
things, whose goals just don't happen to overlap with the ethos of free
software.

But I do agree that culture has changed, and that a copyleft license
feels less necessary than it did a decade ago. Especially for a large,
deep, active project like Firefox... It's hard to imagine how, say, AOL
could stroll back in, make a private fork of Firefox, and have any hope
of long term success.

OTOH, Gerv's thread isn't about Firefox, but Mozilla as a whole. I can
easily imagine there being other projects under the Mozilla umbrella
where private forking is a plausible event.

I don't feel strongly on the issue, but I'd ask a couple of questions:

* For projects that have strayed from copyleft licensing, was there a
particular reason why?

* For projects below some threshold of size / importance / effort /
whatever, should we even care?

Justin

[David Ascher]

On 2013-01-21, at 3:07 PM, Justin Dolske <dol...@mozilla.com> wrote:
>
> * For projects that have strayed from copyleft licensing, was there a particular reason why?

My own take is that license choice is often thought of as a social signal -- it's a way of telling a community "hey, ____, we're like you!" (and implicitly: "come play with us!"). Many projects at Mozilla are part of Mozilla but also align with other cultural movements -- web devs, django devs, JS devs, etc. Given that there's no doubt in anyone's mind that those projects _are_ Mozilla projects, it's not surprising that a signal to those communities is valued.

As to your second question, I do think that for many of our codebases, I don't think it matters much either way.

--da

[Gervase Markham]

On 21/01/13 23:07, Justin Dolske wrote:
> I don't feel strongly on the issue, but I'd ask a couple of questions:
>
> * For projects that have strayed from copyleft licensing, was there a
> particular reason why?

This document tried to gather some of those reasons (see the bottom):
https://wiki.mozilla.org/License_Policy/Mozilla_Project_Licensing

> * For projects below some threshold of size / importance / effort /
> whatever, should we even care?

A good point.

I would note in this connection that when contributing to other people's
projects, Mozilla has a policy of "any open source license is fine". So
small patches aren't the focus here.

[Also relevant, perhaps: MoFo doesn't sign copyright assignments with
for-profit entities relating to _copyleft_ code written by its
employees, because that creates a tilted playing field with respect to
proprietary versions and we think that almost always have
community-corrosive effects.]

Gerv

[Gervase Markham]

On 21/01/13 21:31, David Ascher wrote:
> There are two kinds of reasons motivating a copyleft requirement in a
> software release: moral ones, and pragmatic ones.

<snip>

Your message overall is a cogent (as one would expect :-) outline of the
pragmatist case.

> In 2013, I have to say I find the copyleft clause much less
> interesting or valuable, because:
>
> - open source has evolved, and IMO social pressure is a much more
> effective way to build an actual community of contributors than
> licensing restrictions

Is this a straight either/or? Surely it's a "social pressure OR social
pressure and licensing"?

I think there are good examples, even in our space, of licensing working
as a tool to encourage useful code publication. WebKit Core is LGPL, and
Apple publishes its modifications to it on release in 2003. Other bits
are BSD, and were only open-sourced when Apple decided it wanted to,
which was in mid-2005.

> - history (e.g. DVCS'es, github) has
> shown (IMO) that encouraging forking ends up resulting in more code
> being published than focusing on merging.

That may well be true; however, to make it support your point you would
need to show that copyleft-licensed code is less forked than
non-copyleft code.

> In addition, the MPL isn't a "trendy" license -- MIT, BSD, Apache are
> all more widely / better understood. MPL2 is (IMO) much better, and
> if we'd had a time machine and released MPL2 back in 1999 or whatnot,
> the world might be different today, but pushing MPL2 externally at
> this point doesn't feel high-value.

The MPL is in the OSI's "Popular Licenses" list:
http://opensource.org/licenses/index.html . We certainly saw uptake of
the license outside Mozilla even for 1.1, and we think 2.0 fits rather
nicely on the copyleft spectrum between Apache and LGPL.

Still, I agree that we shouldn't push the MPL "because it's ours". We
don't want licensing NIH.

> Where I end up therefore is that picking a license that minimizes the
> barrier to adoption & contribution is pretty high on my list of
> criteria. I have no strong opinion w.r.t. MIT vs BSD vs Apache, as
> in my experience they're often interchangeable in that pursuit.
> YMMV, especially if the code has to integrate in an existing
> community.

Where on your list of criteria is "protect contributors against legal
action"? If it's somewhere near the top, how much value do you place on
the patent clauses in e.g. MPL and Apache?

Gerv

[David Ascher]

On 2013-01-22, at 1:33 AM, Gervase Markham <ge...@mozilla.org> wrote:
>
> Is this a straight either/or? Surely it's a "social pressure OR social
> pressure and licensing"?

indeed

> I think there are good examples, even in our space, of licensing working
> as a tool to encourage useful code publication. WebKit Core is LGPL, and
> Apple publishes its modifications to it on release in 2003. Other bits
> are BSD, and were only open-sourced when Apple decided it wanted to,
> which was in mid-2005.

Good data.

>
>> - history (e.g. DVCS'es, github) has
>> shown (IMO) that encouraging forking ends up resulting in more code
>> being published than focusing on merging.
>

> That may well be true; however, to make it support your point you would
> need to show that copyleft-licensed code is less forked than
> non-copyleft code.

No, I'm not arguing against copyleft -- I'm just arguing that IMO copyleft is less important now than it once was.

(The question you're asking is an interesting one, which presumably could be estimated, but I don't have the answer)

> Where on your list of criteria is "protect contributors against legal
> action"? If it's somewhere near the top, how much value do you place on
> the patent clauses in e.g. MPL and Apache?

My understanding of the relevant parts of the world is so fuzzy that I don't have much of a "position on the list". In general, legal risk is something that I'd like to weigh relative to likelihood of a suit, etc., which I wouldn't want to do without legal advice and a specific context. I expect our answer might be different for e.g. FirefoxOS vs. some internal tool.

--da

[Nukeador]

Hi,

I have to disagree with David's posture. I think copyleft is more important
now than it was time ago.

Currently we have more developers than ever before, and we've seen a lot of
cases where companies/developers use code for their own purposes, improve
it and never contribute back (yes, even breaking copyleft licenses). Ten
years ago contributing back to a project was a common practice, maybe
because GPL and LGPL were more popular, but now it seems people use
BSD-like licenses even for things that don't need to be spread as a
standard.

In terms of contributions, I think BSD-licensed code gets less contributors
because they don't have to, there is no social pressure, if the license
doesn't force you to contribute back, there are a lot of people that won't
do it.

This remind me the old discussion about when to use GPL and when LGPL:

http://www.gnu.org/licenses/why-not-lgpl.html

We should choose different licenses for different situations, but I think
we should use copyleft licenses in most cases unless there is a good and
documented reason.

Regards.
--
Rubén Martín (Nukeador)
Mozilla Reps Mentor
http://mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

[Gervase Markham]

On 18/01/13 16:06, Gervase Markham wrote:
> [Starting in .governance, .legal and .dev.planning for wide notification
> - follow-ups to .legal, please]

Hello everyone in .governance: can we try and have this discussion in
..legal, please? Sorry I joined in before noticing.

Also, do check and see if your mail/news client is failing to honour
Reply-To or Followup-To, as appropriate (I set both).

Gerv

[Mike Connor]

On 23/01/2013 4:41 AM, Nukeador wrote:

> In terms of contributions, I think BSD-licensed code gets less contributors
> because they don't have to, there is no social pressure, if the license
> doesn't force you to contribute back, there are a lot of people that won't
> do it.

There's a lot of assumptions baked into this statement. Let's break
them down:

* People making significant improvements to a Mozilla codebase will be
more motivated by copyleft than any other factor.

I think this dramatically understates the cost of maintaining a
downstream fork. If we're talking about major improvements, keeping
those up to date is going to be more work than just contributing them back.

* People who do not want to contribute back are still going to depend on
a copyleft-licensed codebase

If a company doesn't want to contribute back, or has reasons why they
don't want to publicly share any of their code, a copyleft license
represents a cost and risk that they may not want to accept.

* Forcing people to contribute will yield positive interactions and
outcomes.

If people who don't want to contribute are forced by circumstance to
adopt our code, they're more likely to do the minimum requirement, which
would be to publish their diffs, not going through the process of
contributing and landing upstream. Throwing changes over the wall
doesn't do us much good.

* The most important metric is how many code contributions we get back

I don't think that's true, though it's an appealing coder-centric
mindset. I don't think our goals in writing code are to get other
people to write code. We build software for people to use as a lever to
drive towards making the Internet better. If no one gives code back,
but the code we write becomes widely adopted and a key factor in keeping
the Web open, Mozilla is a success. If we have a ton of awesome people
contributing a ton of awesome code that no one uses, we're irrelevant.

Any license policy change we consider should be focused on maximizing
the reach and usage of our software. Obviously we should do that in a
way that provides us with adequate protections for contributors, but
given the choice between creating more involuntary contributors and
gaining voluntary users of our software, the latter _must_ win.

-- Mike

[Gervase Markham]

Having taken in the various viewpoints, I suggest the next step is a
concrete proposal. Here is one.

We should update the Mozilla License Policy[0]. On the particular topic
of which license to choose for a new project, it should say:

"New Mozilla-originated software projects may choose either the MPL 2.0
or the Apache License 2.0. No other license is acceptable. When
integrating with, building on or relating to an existing codebase, the
license of that codebase should be chosen. Otherwise, the licensing team
recommends MPL 2.0 for client-side code, and either for server-side
code. However, the decision should be taken on a case-by-case basis in
consultation with the licensing team."

Gerv

[0] http://www.mozilla.org/MPL/license-policy.html

[Gervase Markham]

On 18/01/13 16:06, Gervase Markham wrote:

> [tl;dr: starting a discussion about the appropriate role of non-copyleft
> licenses with respect to Mozilla-originated projects.]

I have now updated the license policy and flowchart with the outcome of
this discussion:
http://www.mozilla.org/MPL/license-policy.html

I've also tried to simplify and shorten the policy by removing
redundancy and reorganizing for clarity. Please let me know if anything
in that document seems weird, or doesn't match what you think was agreed.

Gerv