“MPL Boilerplate at Mozilla” FAQ

The mozilla-central and comm-central MPL 2 switchovers (bug 716478) will happen soon, once I figure out how to fix the build and test errors from the tryserver. In the mean time, people who are making new patches have asked for some guidance on how to deploy the new MPL 2 boilerplate. This is it:

  • There is no need to switch the headers in the files you touch in the normal course of your work; doing so just makes merge conflicts more likely
  • When adding headers, e.g. to new files, Mozilla policy is to use this boilerplate
  • We request that you not change it, other than adapting it for another comment character

Some people have asked whether they should add the names of contributors anywhere. The answer is “no, please, there is no need”.

The MPL 2 (in Exhibit A) does permit people to add “additional accurate notices of copyright ownership” to the boilerplate. The purpose of this language is to allow copyright headers from other licenses to be included when necessary for compliance with those licenses, when portions of code are copied in. It can be used for other purposes, but Mozilla officially discourages those types of uses in our codebases.

Adding a personal copyright notice has no additional legal effect, because copyright is granted by default, and it clutters up the head of the file, because such notices cannot later be removed unless someone is very sure they no longer apply (section 3.4). They also tend to “spread” as code is copied from one file to another, because the extra notices should (although don’t always) go along. Copyright notices are not a “credit mechanism” – we have about:credits for that, or, in some projects, an AUTHORS file.

However, if a contributor feels strongly about it, we will not turn away patches which contain, in addition to their primary purpose, additional copyright notices referencing that contributor for files with significant changes. These should be of the form:

Portions Copyright (C) <year> <name>.

and should be part of their own comment block, not the main license comment block. But again, please be clear that this practice is legally unnecessary and leads to practical inconveniences.

Comments are closed.