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

[Henri Sivonen]

On Fri, Jan 18, 2013 at 6:06 PM, Gervase Markham <ge...@mozilla.org> wrote:
> 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.

Served us well in what sense? What code contributions has Mozilla
gotten because of copyleft in MPL? What code contributions Mozilla
thinks it should have gotten but didn't get despite of MPL?

I didn't follow the Flock case at the time. Is there a postmortem
analyzing the Flock case and whether Mozilla's licensing policy
resulted in outcomes Mozilla wanted in that case?

> Copyleft is a tool which we use to achieve particular ends.

What are the ends in Mozilla's case?

In general, copyleft serves three purposes: 1) requiring people who
build upon the copylefted code to license their code in such a way
that it can be integrated back into the original project, 2) making
people see what code someone ships and 3) making how you obtain
software not matter when it comes to right to redistribute (i.e. you
know GCC is still under the GPL if you obtain GCC from Apple—but are
you sure the copy of clang you obtained from Apple hasn’t gotten
infected by the proprietary license of the dev tool package?). (GPLv3
also tries to serve the purpose of making sure users can repair
software on their devices themselves, but in the Tivoized world
copyleft in general does not provide this.)

In the case of the old tri-license, purpose #1 was easy to circumvent
by someone who didn't mind #2 but who had reasons not to contribute
back to the original project: Licensing modifications only under the
LGPL or the GPL. MPL 2 tried to plug that hole. Is it too soon to
assess whether plugging that hole has resulted in any code getting
integrated into Mozilla's repositories that previously would have been
deliberately made unintegratable?

It's worth noting that copyleft works for coercing reluctant third
parties only when the copylefted software is unique among other Open
Source alternatives. For example, Apple and the BSD projects where
more willing to tolerate the licensing of GCC before clang existed as
a technically good enough alternative. (Also, they were more willing
to tolerate GPLv2 than GPLv3. Apple is so intolerant of GPLv3 that
they sacrificed user experience in order to get rid of Samba
[replacing it with the outrageously beachbally SMBX].)

When Mozilla's licensing policy was established, the expectation was
that many proprietary-minded entities would embed Gecko into
proprietary shells and still make improvements to Gecko itself. But
after that time:

1) WebKit has entered the market and is perceived by potential
embedders as good enough and has a more common license that Gecko
(LGPLv2 vs. MPL).

2) The way WebKit has been used suggests that proprietary-minded
entities that want to embed a Web engine aren't really that interested
in contributing to the engineering of the Web-exposed capabilities of
the engine. (That is, Apple and more recently Google are the companies
that do the most of the core engine engineering in the case of WebKit.
The large number of other companies that use WebKit tend to get a free
ride when it comes to the core features of the engine and they focus
their engineering efforts on porting the engine to their environment.)
That is, perhaps the idea that proprietary-minded embedders would
improve the guts of Gecko was wishful thinking all along.

3) It appears that copyleft is not what motivates Apple and Google to
work on a common source tree. There are other factors.

4) Mozilla has ceded the embedding market to WebKit anyway as far as
technical aspects go, so the legal aspects of embedding Gecko aren't
really that relevant anymore.

If one considers the availability of competing alternatives as a
factor in licensing: Should Mozilla make Servo's licensing less
restrictive than either Gecko's or WebKit's to drive adoption once
Servo is technically good enough?

> So, the first question is: if use of non-copyleft licenses has become a
> practice, is it a good practice?

Have there so far been cases where someone has improved non-copyleft
Mozilla source and we really wish we could get their improvements and
believe that had the code been under MPL, they'd have still chosen to
make the improvements?

On Mon, Jan 21, 2013 at 4:21 PM, Gervase Markham <ge...@mozilla.org> wrote:
> 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?

The link between Mozilla's Mission and funding the DOM and XOM
features of the Validator.nu HTML Parser that are needed neither by
Validator.nu nor by Firefox was driving the adoption of the HTML5
parsing algorithm thereby driving the adoption of Open Web formats
beyond Mozilla's usual browser context. The MIT license made sense,
because when you want to drive adoption, it makes sense to choose an
universal donor license that works for apps from super-proprietary to
GPLv2 and GPLv3.

So I think it makes sense to say: Mozilla should release software
under a "no copyleft" license at least when driving the adoption of
that software is more important than attempting to force other people
to open their code and copyleft would hinder the adoption. (Copyleft
is more likely to hinder the adoption of libraries like a parser than
the adoption of full end user products like Firefox.)

On the other hand, it doesn't seem particularly useful to use a
copyleft license unless there is a good reason to believe that Mozilla
would get more useful contributions as a consequence of copyleft
compared to the "no copyleft" scenario.

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

Compared to BSD and MIT, Apache has two downsides:
1) Incompatibility with GPLv2.
2) Having to include a longer piece of legal text.

On point #2 even without comparison to BSD or MIT: Apache License 2.0
says you have to distribute the full license text along with the work.
This is a non-issue for a large software application. It might even be
a non-issue for Web use if it is enough for the license file to sit on
a server ready to a GET with only its URL sent in JS or CSS comments
or something but the end user does not actually have to issue the GET
for it.

However, for works like fonts, images and similar, the requirement to
distribute the full license text along with the work may be onerous.
If Mozilla mandates the use of the Apache License for that kind of
works, I think Mozilla should waive the requirement to distribute the
full license text.

> 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?

Does this question apply to projects whose development Mozilla pays
for but that aren't under Mozilla governance formally?

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

[Benjamin Smedberg]

On 1/18/2013 11:06 AM, Gervase Markham wrote:
> 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.

I agree with dascher that the choice should be pragmatic; we should pick
a license which gives us the most opportunity for contributions while
protecting whatever interests we think are vital. I have no clue how
you'd measure that, though!

I personally find the GPL objectionable because of its viral copyleft,
and I have tried to avoid contributing to projects that are GPL-licensed
unless it was necessary. The per-file copyleft of the MPL is not a big
deal; I figured it was just the cost of protecting the original owner
(Netscape) and getting the project off the ground in the first place. I
never found anything particularly desirable about it, though.

Many of the small tool projects that I have written while at Mozilla I
have licensed under a permissive license, because I wanted them to be
available as sample code. I do understand how the patent protections in
the Apache license are desirable, and so I'll be using Apache for
similar projects in the future.

I tend to think that if we were starting the project over again, we
should use Apache 2. And since we mostly are experimenting with starting
over again in Servo, we should use Apache 2 for Servo.

--BDS

[Joshua Cranmer]

On 1/18/2013 10:06 AM, Gervase Markham wrote:
> 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.

As an individual, I prefer simplicity and am therefore biased towards
the idea of "pick the simplest license that works"--hence why I prefer
BSD and MIT over, say, Apache. That said, I do recognize that the
simplicity of these licenses is inappropriate for certain things, and
also that copyleft is more desirable in some scenarios than in others. A
good example here is the difference between NSPR and NSS: both are
rather low-level libraries which are not likely to benefit a lot from
copyleft, but NSPR covers things that aren't going to incur significant
legal concern and so BSD would easily work, whereas cryptography is a
legal minefield and one where I would probably opt for Apache instead.

If you want to maximize reuse, you want to make the libraries and
low-level components very liberal (so anyone can use it), and you want
to make the end applications strong copyleft (so you can use any library
you want). If you want ideological decisions, the criterion for copyleft
boils down to "Would you care if someone forked your code, made it ten
times better, and sold it?"

In terms of making this a consensus, I think it ultimately boils down to
the following rules:
1. If it is a product that we are shipping and explicitly using our
brand name for, it should be MPL. This amounts to mozilla-central and
comm-central for sure. For extensions that are under the aegis of
Mozilla (chatzilla, DOM inspector, etc.), I could entertain arguments
about not making them MPL, but at the very least consistency concerns
are much stronger here.
2. If it is a tool or library that is developed independently of our
products (e.g., NSPR, Rhino, Circus?, pdf.js, Shamway) and would be
useful to other projects, then a BSD/MIT/Apache-style license is
preferable, but MPL is tolerable.
3. If it is a website, then it should be BSD/MIT/Apache-style.

This isn't perfectly clear (it's not clear how to classify Gaia, for
example), but it should provide a rough guideline for what new projects
should elect their license to be.

> 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.

One of the problems with Apache is that it is not maximally reusable:
Apache v2.0 is (according to the FSF) not compatible with GPL/LGPL 2.1
or older, so any project that uses GPLv2 but not v3 for ideological
reasons can use a BSD/MIT-licensed project but not an Apache-licensed one.

[Gervase Markham]

On 20/01/13 00:55, Joshua Cranmer wrote:
> On 1/18/2013 10:06 AM, Gervase Markham wrote:
>> 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.
>
> As an individual, I prefer simplicity and am therefore biased towards

<snip>

Thank you, all 3 of you, for taking the time to think about this; but
could you repost in mozilla.governance, as I am trying to keep the
conversation in one place?

Thanks :-)

Gerv

[Benjamin Smedberg]

On 1/23/2013 7:10 AM, Gervase Markham wrote:
> Thank you, all 3 of you, for taking the time to think about this; but
> could you repost in mozilla.governance, as I am trying to keep the
> conversation in one place?

I can, but the original message said Followup-To: mozilla.legal.

Is governance where you want this?

--BDS

[Gervase Markham]

On 23/01/13 13:12, Benjamin Smedberg wrote:
> On 1/23/2013 7:10 AM, Gervase Markham wrote:
>> Thank you, all 3 of you, for taking the time to think about this; but
>> could you repost in mozilla.governance, as I am trying to keep the
>> conversation in one place?
>
> I can, but the original message said Followup-To: mozilla.legal.

Oh, smeg. Yes, that's true - you are all right and everyone else is
wrong. Sorry! As you were. Take no action.

Gerv

[Gervase Markham]

On 23/01/13 12:10, Gervase Markham wrote:
> Thank you, all 3 of you, for taking the time to think about this; but
> could you repost in mozilla.governance, as I am trying to keep the
> conversation in one place?

Sorry, this is all wrong. Ignore this message.

Gerv

[Gervase Markham]

On 22/01/13 13:11, Henri Sivonen wrote:
> On Fri, Jan 18, 2013 at 6:06 PM, Gervase Markham <ge...@mozilla.org> wrote:
>> 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.
>
> Served us well in what sense? What code contributions has Mozilla
> gotten because of copyleft in MPL? What code contributions Mozilla
> thinks it should have gotten but didn't get despite of MPL?

I'm not sure one could say the MPL was the tipping factor one way or the
other for a particular contribution. I can try and answer the related
question, "why is the MPL's particular brand of copyleft strength a good
choice for Mozilla?"

I think the answer to that is that the file-level copyleft sets up a
community expectation of sharing more than permissive licenses do, while
not prohibiting proprietary derivatives in the way stronger copyleft
licenses do. Some, of course, may not agree with the first half of that.

> I didn't follow the Flock case at the time. Is there a postmortem
> analyzing the Flock case and whether Mozilla's licensing policy
> resulted in outcomes Mozilla wanted in that case?

I've not seen an explicit post-mortem. I did not carefully study Flock's
licensing, but my understanding from others is that they took
tri-licensed code and made it GPL-only to prevent Mozilla from
reincorporating their changes. (Of course, there's still the question of
whether we'd have wanted to take their changes.) This is unfriendly, but
then the MPL itself is designed to allow proprietary derivative works
like e.g. Netscape 6+. It could be argued that the only difference with
Flock is that instead of making it proprietary, they wanted to appear to
some like good open source people and so used the GPL instead.

Perhaps some of the ex-Flockers around the community, now that Flock is
gone, could tell us a little about how these things were viewed inside?

>> Copyleft is a tool which we use to achieve particular ends.
>
> What are the ends in Mozilla's case?
>
> In general, copyleft serves three purposes: 1) requiring people who
> build upon the copylefted code to license their code in such a way
> that it can be integrated back into the original project, 2) making
> people see what code someone ships and 3) making how you obtain
> software not matter when it comes to right to redistribute (i.e. you
> know GCC is still under the GPL if you obtain GCC from Apple—but are
> you sure the copy of clang you obtained from Apple hasn’t gotten
> infected by the proprietary license of the dev tool package?). (GPLv3
> also tries to serve the purpose of making sure users can repair
> software on their devices themselves, but in the Tivoized world
> copyleft in general does not provide this.)
>
> In the case of the old tri-license, purpose #1 was easy to circumvent
> by someone who didn't mind #2 but who had reasons not to contribute
> back to the original project: Licensing modifications only under the
> LGPL or the GPL. MPL 2 tried to plug that hole. Is it too soon to
> assess whether plugging that hole has resulted in any code getting
> integrated into Mozilla's repositories that previously would have been
> deliberately made unintegratable?

I'd say it's too soon, yes. Although I'd also say that MPL (either
version) provides other mechanisms (such as the limited copyleft) to
keep your code from falling under the MPL if you are willing to make the
engineering effort to use them.

> When Mozilla's licensing policy was established, the expectation was
> that many proprietary-minded entities would embed Gecko into
> proprietary shells and still make improvements to Gecko itself. But
> after that time:
>
> 1) WebKit has entered the market and is perceived by potential
> embedders as good enough and has a more common license that Gecko
> (LGPLv2 vs. MPL).

....albeit one which requires a greater level of code sharing than MPL does.

> 2) The way WebKit has been used suggests that proprietary-minded
> entities that want to embed a Web engine aren't really that interested
> in contributing to the engineering of the Web-exposed capabilities of
> the engine. (That is, Apple and more recently Google are the companies
> that do the most of the core engine engineering in the case of WebKit.
> The large number of other companies that use WebKit tend to get a free
> ride when it comes to the core features of the engine and they focus
> their engineering efforts on porting the engine to their environment.)
> That is, perhaps the idea that proprietary-minded embedders would
> improve the guts of Gecko was wishful thinking all along.

A fair point indeed. It would be interesting to hear from the platform
engineers about their experience of incoming patches and their origins.

> If one considers the availability of competing alternatives as a
> factor in licensing: Should Mozilla make Servo's licensing less
> restrictive than either Gecko's or WebKit's to drive adoption once
> Servo is technically good enough?

I wonder whether it's in the best interests of the web for there to be
lots of proprietary rendering engine forks. "People won't bother to do
that" seems a bit wishful. If the engine is copyleft, one can at least
see what brain-damaged thing someone else has done, even if you don't
want to do the same thing yourself.

>> So, the first question is: if use of non-copyleft licenses has become a
>> practice, is it a good practice?
>
> Have there so far been cases where someone has improved non-copyleft
> Mozilla source and we really wish we could get their improvements and
> believe that had the code been under MPL, they'd have still chosen to
> make the improvements?

I have no idea; to know, we'd need to hear from an engineer who wanted
some source but couldn't get it.

> On Mon, Jan 21, 2013 at 4:21 PM, Gervase Markham <ge...@mozilla.org> wrote:
>> 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?
>
> The link between Mozilla's Mission and funding the DOM and XOM
> features of the Validator.nu HTML Parser that are needed neither by
> Validator.nu nor by Firefox was driving the adoption of the HTML5
> parsing algorithm thereby driving the adoption of Open Web formats
> beyond Mozilla's usual browser context. The MIT license made sense,
> because when you want to drive adoption, it makes sense to choose an
> universal donor license that works for apps from super-proprietary to
> GPLv2 and GPLv3.

I can see this as an argument against GPL-level copyleft; the FSF even
uses it when deciding whether to use the LGPL. But I'm not sure it
applies when considering the MPL. Let's imagine your "super-proprietary"
app wants to include an MPLed library. What do they have to do? Ship the
source to that library (only). Why can't they simply do that? There are
a few possible reasons:
a) technical changes to our code that they don't want to reveal
b) ideological opposition to publishing source code

Re: a) - do we really want lots of proprietary, differently-behaving
HTML5 parser forks we can't see inside?

I'm not sure what to say about b), other than that it's a really stupid
position to hold.

>> 2) If there are such circumstances, what "no copyleft" license should we
>> use? (With the licensing team recommending Apache.)
>
> Compared to BSD and MIT, Apache has two downsides:
> 1) Incompatibility with GPLv2.
> 2) Having to include a longer piece of legal text.
>
> On point #2 even without comparison to BSD or MIT: Apache License 2.0
> says you have to distribute the full license text along with the work.

Yes, albeit once, and the per-file license header is half the length of
MIT in words, and less than half of BSD.

> This is a non-issue for a large software application. It might even be
> a non-issue for Web use if it is enough for the license file to sit on
> a server ready to a GET with only its URL sent in JS or CSS comments
> or something but the end user does not actually have to issue the GET
> for it.

It depends on how you interpret the word "give" in Apache 2.0. I'd only
say that it's mind-bogglingly unlikely that you would face a copyright
suit for providing a copy of the canonical URL to the Apache License
instead of a full copy of the license itself.

> However, for works like fonts, images and similar, the requirement to
> distribute the full license text along with the work may be onerous.
> If Mozilla mandates the use of the Apache License for that kind of
> works, I think Mozilla should waive the requirement to distribute the
> full license text.

An interesting idea; although we could only do so for stuff we owned the
copyright on, or which was contributed directly to us (and so we could
say had been contributed with this rider in mind). If we used a 3rd
party Apache-licensed thing, we wouldn't have this exception. And so
we'd have to keep track of which Apache things in our tree were vanilla,
and which were Moz-flavoured.

>> 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?
>
> Does this question apply to projects whose development Mozilla pays
> for but that aren't under Mozilla governance formally?

Good question; I hadn't thought about it. Are you thinking about the
validator.nu HTML5 parser? :-)

Gerv

[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

[Wraithan (Chris McDonald)]

Gerv,

Can't say I am keen on this. we are taking away the ability for us to
license things to fit into the community they are being built for? BSD
being the way of the vast majority of python/django projects. One of the
coolest things about Mozilla when I joined was this ability. The
knowledge that my hands wouldn't be tied if I made something neat.

It appears none of the discussion made any difference because you've
gone right back to what you were originally arguing for. I feel like the
discussion may have trailed off, but is still important and an agreement
was never come to.

I've CC'd webdev as there are a lot of us who feel strongly on this and
the email didn't go out to all of them.

To distil my disagreements:
1) This takes away our ability to blend into communities we are a part of.
2) Requires the extra work of consulting legal if when releasing
something we feel strongly should be more permissive or at least,
differently permissive.
3) The discussion wasn't finished, it just happened to trail off in lieu
of other things/work/etc.

-Wraithan

> _______________________________________________
> legal mailing list
> le...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/legal

[Wraithan (Chris McDonald)]

[Michael Kelly]

I agree with Wraithan. django-browserid, for example, would be a great
case for using a common Python/Django license like BSD, as it would
help encourage adoption of Persona-based authentication in Django sites
by making it easier for developers to figure out if they can use the
library or not.

Granted, no one has come to me and said "I can't use django-browserid
becasue it's MPLv2", so I have no hard evidence for this. Doh!

-Mike Kelly

> _______________________________________________
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev

[Michael Kelly]

[Gervase Markham]

On 13/02/13 21:10, Wraithan (Chris McDonald) wrote:
> Can't say I am keen on this. we are taking away the ability for us to
> license things to fit into the community they are being built for? BSD
> being the way of the vast majority of python/django projects.

It would be great if you could help us understand why Apache (which is,
in legal effect, BSD with a patent clause) is unacceptable to that
community.

> It appears none of the discussion made any difference because you've
> gone right back to what you were originally arguing for.

My understanding was that the web dev team were keen on non-copyleft
licensing, which the licensing policy didn't allow; formally enabling
that was what this discussion was all about. If that's not the point you
were making, then there's been some miscommunication.

> I've CC'd webdev as there are a lot of us who feel strongly on this and
> the email didn't go out to all of them.

I did my best to get people involved in the discussion, including a
specific email written to the webdev list to come and get involved. If
webdevs aren't reading the webdev list, then could I politely suggest
their community engagement needs a little polishing?

Gerv

[David Ascher]

On 2013-02-13, at 1:40 PM, Gervase Markham <ge...@mozilla.org> wrote:

> On 13/02/13 21:10, Wraithan (Chris McDonald) wrote:

>> Can't say I am keen on this. we are taking away the ability for us to
>> license things to fit into the community they are being built for? BSD
>> being the way of the vast majority of python/django projects.
>

> It would be great if you could help us understand why Apache (which is,
> in legal effect, BSD with a patent clause) is unacceptable to that
> community.

Indeed, it may just be a matter of education. Maybe reaching out to someone who speaks with authority in the Django world would elucidate the question.

--da

[Peter Bengtsson]

I would be happy to use Apache2 instead of BSD if Gerv thinks that's
better.

As Will pointed out, the Python open source peeps won't scream and laugh
at me for not using BSD on my non-MPL2 projects.

And if some someone thinks BSD is a million dollar better than Apache2,
then that's just tough. Time to progress!

Peter

On 13/02/2013 13:10, Wraithan (Chris McDonald) wrote:
> Gerv,

>
> Can't say I am keen on this. we are taking away the ability for us to
> license things to fit into the community they are being built for? BSD

> being the way of the vast majority of python/django projects. One of the
> coolest things about Mozilla when I joined was this ability. The
> knowledge that my hands wouldn't be tied if I made something neat.
>

> It appears none of the discussion made any difference because you've

> gone right back to what you were originally arguing for. I feel like the
> discussion may have trailed off, but is still important and an agreement
> was never come to.
>

> I've CC'd webdev as there are a lot of us who feel strongly on this and
> the email didn't go out to all of them.
>

[Peter Bengtsson]

[Mike Connor]

The original email proposed either of MPL2 or APL2 for server code, so I'm assuming that's fine.

-- Mike

[Mike Connor]

[Mike Connor]

On 2013-02-13, at 11:46 AM, Gervase Markham wrote:

> 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."

I don't think it should be necessary to consult with licensing@ if a project is choosing one of the two acceptable licenses. This strikes me as unnecessary overhead and friction, when the policy should strive for the minimum necessary work needed to comply. Project owners should be free to choose either of the acceptable licenses based on their own circumstances.

On that principle, I would propose that we simply adopt the first three sentences of the above text, and cut the rest.

-- Mike

[Gervase Markham]

On 13/02/13 23:34, Mike Connor wrote:
> I don't think it should be necessary to consult with licensing@ if a
> project is choosing one of the two acceptable licenses. This strikes
> me as unnecessary overhead and friction, when the policy should
> strive for the minimum necessary work needed to comply. Project
> owners should be free to choose either of the acceptable licenses
> based on their own circumstances.
>
> On that principle, I would propose that we simply adopt the first
> three sentences of the above text, and cut the rest.

Fair point. First four sentences? :-)

Gerv

[Gervase Markham]

On 13/02/13 22:07, Wraithan (Chris McDonald) wrote:
> It isn't a case of unacceptable. It is a case of standing out and being
> different in ways that one is not aiming to be. Showing up at a laid
> back conference like BarCamp wearing a suit when you go to run a session
> is not unacceptable but definitely does not fit in either.

I think Will's very interesting data shows that you won't be standing
out too much. :-) Perhaps it's the equivalent of wearing chinos instead
of jeans.

> It is one of the points we were making. And if this is the best we can
> do then at least it is better than completely tying our hands and making
> us use MPL for everything. Part of our hiring process and fit for
> Mozilla is that we are good community members. We have strong ties to
> our communities we come from and as such want to continue to maintain
> their status quo rather than forcing our corporations ideas in.

Hence the discussion on changing the licensing policy. The flipside of
your point above is that we, as a respected open source project, want to
be promoting responsible licensing practice. We need to read the signs
of the times, which indicate that the software patent wars are going to
get worse before they get better. Where Mozilla leads, others follow
(see e.g. LibreOffice's adoption of the MPL 2). Which is why the
licensing team feels strongly that we should, going forward, only use
licenses with explicit patent clauses - because it helps us, and
encourages others to do the same.

Allowing Apache 2.0 into the mix is an attempt to do that, and also do
our best to meet the requirements of some communities for non-copyleft
licensing. Mozilla's community license is the MPL 2, but we understand
that not all the work Mozilla does is solely part of our own community.

> The email I replied to was not CC'd to any of the webdev mailing lists
> unlike the previous ones. Which is why I noted and fixed that.

Which has now forked the discussion into two places, because no
Followup-To was set :-| In the future, perhaps posting a pointer to
where it's happening might work better?

Gerv

[Gervase Markham]

On 13/02/13 21:55, tofumatt wrote:
> These folks are developers, not lawyers. I'm very much the same way
> when it comes to licensing; I don't want to bother with it at all and
> just do it for my personal projects out of necessity. Check out this
> post -- a developer just wants to give something away and people go
> on and on about the legal stuff.

I sympathise with those who would rather code than care about licensing.
Unfortunately, the world does not work the way many of us would like it
to work, and restrictive you-cant-do-anything copyright is the default.

(See
http://tieguy.org/blog/2013/01/27/taking-post-open-source-seriously-as-a-statement-about-copyright-law/
for an interesting comment on this.)

> The reason Apache is unacceptable is because it's not what they use
> or want to deal with. The same way most Ruby libraries are MIT, most
> Python is BSD, and that makes it pretty headache-free for developers
> who just want to write code.

See Will's data. Things are more heterogeneous than you think.

I hope also that other BSD/MIT-tending communities will read the state
of the world the same way we do, and move towards Apache 2.0 as the best
non-copyleft license available.

> Especially when a lot of the stuff we ship are libraries and
> application templates (think Mortar), non-copyleft licensing saves
> people headaches. That's a sign of truly great software: it solves
> problems without creating more. We should do the same with licensing
> for the communities we occupy.

Apache is a non-copyleft license; what you say above is part of the
reason we want to change the policy to allow it.

Gerv

[Mike Connor]

On 14/02/2013 6:41 AM, Gervase Markham wrote:
> On 13/02/13 23:34, Mike Connor wrote:

>> I don't think it should be necessary to consult with licensing@ if a
>> project is choosing one of the two acceptable licenses. This strikes
>> me as unnecessary overhead and friction, when the policy should
>> strive for the minimum necessary work needed to comply. Project
>> owners should be free to choose either of the acceptable licenses
>> based on their own circumstances.
>>
>> On that principle, I would propose that we simply adopt the first
>> three sentences of the above text, and cut the rest.
>

> Fair point. First four sentences? :-)

I thought about that, but do we really have a consensus that copyleft is
preferred by the project as a whole? In most of the discussions I've
seen on the subject, there's been strong desire from many to not require
copyleft, and very little desire to maintain copyleft. In the absence
of consensus, I am reluctant to enshrine any preference in an official
policy. I'd be okay with a link helping developers to understand the
pros and cons of the two licenses, but I don't want to put anyone in the
position having to defend their choice if they go against a
recommendation enshrined in official policy.

-- Mike

[Asa Dotzler]

Why this line "No other license is acceptable"? Or from your original
post "We should clearly and by name forbid the use of other licenses for

Mozilla-originated codebases, without specific permission and in

exceptional circumstances"?

Is this solely about the requirement for the patent protection clause?

- A

[Asa Dotzler]

I'm sorry. I was reading the wrong newsgroup. I'd missed the correct
location for this discussion, where much more context lives. I have
answered my own question.

- A

[Gervase Markham]

On 17/02/13 04:49, Asa Dotzler wrote:
> Why this line "No other license is acceptable"? Or from your original
> post "We should clearly and by name forbid the use of other licenses for
> Mozilla-originated codebases, without specific permission and in
> exceptional circumstances"?
>
> Is this solely about the requirement for the patent protection clause?

That was the driver, yes. Would you prefer a more nuanced expression?

Gerv

[Asa Dotzler]

Nope. I'm good.

- A

[Gervase Markham]

On 14/02/13 14:14, Mike Connor wrote:
> I thought about that, but do we really have a consensus that copyleft is
> preferred by the project as a whole?

Sorry for the delay in getting back to this. I've been trying to talk to
Mitchell, and she's very busy :-) I spoke to her this morning about it.

> of consensus, I am reluctant to enshrine any preference in an official
> policy.

The bottom line is that up to now we have been "MPL 2.0 only", and this
proposal is already a significant liberalization of that policy. To put
it another way, official policy already enshrines a preference. Further
liberalizations would require community-wide support for them to be
demonstrated.

So if you want to get together a coalition of people to make the case
for a further change, you are welcome to do that. But for now, we are
going to stick with my original proposal with a modified sentence 5:

"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. Please consult the licensing team before going against its
recommendations."

Gerv

[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

[fantasai]

On 01/22/2013 09:11 PM, Henri Sivonen wrote:
>
> 2) The way WebKit has been used suggests that proprietary-minded
> entities that want to embed a Web engine aren't really that interested
> in contributing to the engineering of the Web-exposed capabilities of
> the engine. (That is, Apple and more recently Google are the companies
> that do the most of the core engine engineering in the case of WebKit.
> The large number of other companies that use WebKit tend to get a free
> ride when it comes to the core features of the engine and they focus
> their engineering efforts on porting the engine to their environment.)
> That is, perhaps the idea that proprietary-minded embedders would
> improve the guts of Gecko was wishful thinking all along.

I just wanted to correct this point; there are efforts by embedders
in East Asia to improve core WebKit capabilities, because the layout
engine doesn't serve their needs. I've also encountered a Gecko
embedder who patched our layout engine, because they needed something
fixed for their use cases.

Which brings up the point that, if the existing product is sufficient,
an embedder won't put any effort into the core. But if their needs
are not met, they will work on it.

I think whether the patches get reintegrated into the main depends
mostly on the ease or difficulty of upstreaming patch. Licensing
aside, there are definite benefits (maintainability) to not maintaining
a fork.

~fantasai

[Henri Sivonen]

On Wed, Jan 23, 2013 at 4:06 PM, Gervase Markham <ge...@mozilla.org> wrote:

> On 22/01/13 13:11, Henri Sivonen wrote:
>

> On Mon, Jan 21, 2013 at 4:21 PM, Gervase Markham <ge...@mozilla.org> wrote:
> >> 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?
> >
> > The link between Mozilla's Mission and funding the DOM and XOM
> > features of the Validator.nu HTML Parser that are needed neither by
> > Validator.nu nor by Firefox was driving the adoption of the HTML5
> > parsing algorithm thereby driving the adoption of Open Web formats
> > beyond Mozilla's usual browser context. The MIT license made sense,
> > because when you want to drive adoption, it makes sense to choose an
> > universal donor license that works for apps from super-proprietary to
> > GPLv2 and GPLv3.
>
> I can see this as an argument against GPL-level copyleft; the FSF even
> uses it when deciding whether to use the LGPL. But I'm not sure it
> applies when considering the MPL. Let's imagine your "super-proprietary"
> app wants to include an MPLed library. What do they have to do? Ship the
> source to that library (only). Why can't they simply do that? There are
> a few possible reasons:
> a) technical changes to our code that they don't want to reveal
> b) ideological opposition to publishing source code
>

c) They don't want the practical trouble of figuring out what they need to
publish or the legal liability trouble in case they don't do it the right
way or forget to update stuff later and then fall out of compliance.

> >> 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?
> >
> > Does this question apply to projects whose development Mozilla pays
> > for but that aren't under Mozilla governance formally?
>
> Good question; I hadn't thought about it. Are you thinking about the
> validator.nu HTML5 parser? :-)
>

I'm thinking about both the parser and the other code that's in the
validator.

--
Henri Sivonen
hsiv...@hsivonen.fi