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.
_______________________________________________
legal mailing list
[email protected]
https://lists.mozilla.org/listinfo/legal
