Mozilla and Non-Copyleft Licensing

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

For a long time now, the Mozilla License Policy has said, paraphrasing, that new codebases written by Mozilla should use the MPL. (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. 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. 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:

  1. 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.
  2. 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).
  3. We should clearly and by name forbid the use of other licences for Mozilla-originated codebases, without specific permission and in exceptional circumstances.
  4. 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.

Join the discussion in mozilla.legal.

4 thoughts on “Mozilla and Non-Copyleft Licensing

  1. Simply put I believe the reason why licenses like MPL “dont work” for some projects is because they put personal or corporate interests above ideals (and not “mobile” or “webapp” related).

    GPL (and even more with v3) and in a lesser manner MPL puts ideals above personal or corporate interests.

    Now it’s arguable if one or the other is more useful. The past years have however proven that going for “ideal” isn’t all that bad and it worked out for quite a few huge projects.

  2. Rust recently went through relicensing (with your consultation) and decided on the seemingly bizarre dual MIT/ASL2 combo. For anybody interested the rationale is here: https://mail.mozilla.org/pipermail/rust-dev/2012-November/002664.html. The summary is that ASL2 provides patent protection and MIT gives GPL2 compatibility (which could be important for a language runtime).

    The MozillaWiki license page isn’t up to date on these developments and I don’t seem to be able to edit it.

  3. To an outside observer of Mozilla like me the proliferation of permissive licenses on recent Mozilla project is something that can be attributed not to the attributes of the licenses themselves but rather, the different mindset of the groups that came together to develop those projects.

    Most (all?) of those projects look as un-Mozillian as they get. They’re developed on a proprietary platform, using its dysfunctional issue tracker with duct-taped solutions to support developing large projects. They use permissive licenses. In effect, they’re following what is considered “hip” in today’s open source development.

    Sadly, copyleft is not that “hip” these days and neither is being in control of your development infrastructure. Software devs are not immune to trends and fashion, hence the current situation.

    To my understanding, it’s not a simple a question of licenses but rather project direction and leadership.

  4. Permissive licenses are ideal for certain purposes. One very clear example is the reference implementation of a format or protocol, where it is desirable that the format or protocol be adopted widely.

    However, even when the permissive license doesn’t have clear advantages over copyleft, it can often still work out just fine. When a project is active, reasonable people are highly motivated to contribute their improvements back regardless of license, because not doing so causes rapid “patch rot” as a constant influx of upstream changes makes proprietary improvements a constant headache to maintain. Getting your patch accepted into the main codebase means you can relax and stop worrying about that and proceed to work on something else. When this dynamic is in place, the license is significantly less important than it might otherwise be.

    There are numerous examples of projects developed under permissive licenses that are doing very well, with no significant harm resulting from their licensing permissiveness and no really noteworthy proprietary improvements being withheld from the community. Counterexamples are much less common, particularly if you restrict yourself to the modern era of widespread internet adoption and a general awareness of open-source development methodology in the IT community. IMO, copyleft licenses are mostly not as important as people think.

Leave a Reply

Your email address will not be published. Required fields are marked *