Mozilla and Non-Copyleft Licensing

[tl;dr: starting a discussion in 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

Defeating the Peter Principle

A Freakonomics blog post which covered the Peter Principle (see Question 3) got me thinking. The Peter Principle is explained as follows:

Dr. Peter is one of our favorites. His book The Peter Principle: Why Things Always Go Wrong came out in 1969. He first expressed the principle that bears his name like this: “In a hierarchy, each employee tends to rise to his level of incompetence.” Once an employee reaches his level of incompetence, his superiors will recommend no further promotion, leading to “Peter’s Corollary”: “Every post tends to be occupied by an employee incompetent to execute its duties.”

How do you defeat the Peter Principle in your organization? How about this: as a condition of promotion, any employee agrees that they may decide to (or be asked to) return to their previous job, but keep the pay and benefits package from the higher-level job.

The idea here is to remove the financial disincentive for the employee to admit they aren’t doing well and say “OK, fair enough, this job isn’t for me; let me go back to what I’m good at”. If they are ever promoted again, their original salary or salary scale is used to determine their new pay, so they can’t yoyo up and down, collecting a compensation bump each time. One may want to impose a minimum term in the new job, and/or require management permission and agreement for the step-down. This would mean some lower-level employees cost the company more than others, but it might well be a whole lot cheaper than having the wrong person doing the wrong management job, badly. It could perhaps be seen as the price management agrees to pay for promoting the wrong person in the first place.