Re: Mozilla and Non-Copyleft Licensing

Joshua Cranmer <[email protected]> Sat, 19 Jan 2013 18:55:30 -0600
Newsgroups gmane.comp.mozilla.license
Message-ID <[email protected]>
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.