One new feature of the MPL 2.0 is that it allows you (without dual-licensing) to incorporate MPL 2.0 files into a larger project licensed under the GNU GPL or LGPL.
We’ve written a document to help developers who want to incorporate MPL 2.0 code into (L)GPL-licensed projects. It explains what to do with the boilerplate, and how best to respect the intention of upstream developers.
Niche, but useful if you’re in that niche :-)
I bet that title sent shivers of pure pleasure up and down your spine, didn’t it? :-) This post explains why all modern open source licences have patent clauses, what they do (and don’t do), and why you should use and recommend licences which contain them. This question is relevant to discussions of licence choice.
I am not a lawyer, although I do sometimes play one in real life. If in doubt, consult the real deal.
This analysis will focus on the 3 most popular modern licences with patent clauses – the Apache License 2.0 (“APL”), the Mozilla Public License 2.0 (“MPL”), and the GNU General Public License 3.0 (“GPL”).
The APL (section 3) and the MPL (section 2.1, 1.11, 1.2, 1.3) say that if you make a contribution to the code, you have to grant all users a licence to any patent you hold which is infringed by your contribution, or by the whole thing as a result of adding your contribution. In the case of the GPL (Section 11, para 2), you have to grant a licence to any patent you hold which is infringed by any part of the modified work, at the time you contributed to it, whether you wrote or changed that part or not. So the GPL’s grant is wider in scope than the other two.
The above affects contributors. There are also clauses which relate to users. In the case of the MPL (section 5.2) and the GPL (section 10, para 3), you lose your right to use the software at all if you launch a patent suit against someone else regarding that software. In the case of the APL (section 3), you lose any patent licences you might have got to the code (which may be none), but you don’t lose your copyright rights.
In the case of the APL and MPL, they don’t make a contributor grant a licence to patents which the code already implemented before they came along, or which someone else made the code implement while they were contributing. In all cases, if the code is changed in the future by someone else to implement a patent, the licences don’t make the contributor grant a licence to that patent. (I.e. if BigCorp has a patent on the Bar algorithm, and they contribute some non-Bar-related code to project Foo, you can’t get a free license to the Bar patent by changing Foo to implement it.) And they don’t protect you at all from the patents of people who are neither contributors nor users, including patent trolls.
Patent clauses do not solve the software patent problem. But they do mitigate it and, in the presence of the problem, they do help build collaborating communities. That is why all modern open source licences have a patent clause, and why you should only use and promote licences which have them, and encourage others to do the same.
When an open source project or codebase is considering a move from one licence to another, one question which may affect whether they go ahead or not is whether they have to track down and ask permission of all the contributors. (Another question is how many people will be upset by the change; that is out of scope here. This post is about what is possible, not about what is wise.)
By “relicensing”, I mean “make it so that the code can only be used by following the terms of the new licence”. This is distinct from dual-licensing, where the code can be used under either set of terms. For example, jQuery is dual-licensed MIT/GPL, and so it can be used and redistributed under MIT, or GPL, or both.
When you relicense, you may have to continue following the terms of the old license as well, or you may not – it depends on the exact licences concerned. If a project moves from the MIT licence to the GPL licence, users would need to obey both sets of terms – although the MIT requirements are a tiny subset of the GPL ones; the only relevant term in the MIT licence is “preserve this notice”. By contrast, if a project moves from LGPL 2.1 to GPL, as permitted by LGPL section 3, then you delete the LGPL boilerplate and replace it with the GPL one, and only GPL terms apply from then on.
So when do you have to ask in order to relicense? You don’t have to ask if:
The last bullet is a tricky one; what makes two licenses, A and B, compatible? “Compatible” is a word used with regard to licences in a number of senses. Here, I mean that it’s possible to migrate from users/distributors being required to obey License A to users/distributors being required to obey License B (and possibly A as well; see above). The first thing to note is that compatibility of this sort is not symmetric – A → B does not imply B → A. To be certain in any case requires an analysis of the two texts, but in general:
Being specific, the following compatibility diagram, while incomplete, may help with the most common open source licenses. “+” means “or later” where such a clause is optional.
MIT/BSD → Apache 2.0 → MPL 2.0 → LGPL 2.1+ → GPL 2.0+
↓ ↓
LGPL 3.0+ → GPL 3.0+ → AGPL 3.0+
This diagram is meant as a guide only, and does not cover some particular twists; for example, it does not reflect the Apache 2.0/GPL 2.0 incompatibility, and you can only relicense from the MPL to a GPL license if you combine with existing GPLed code and dual-license the MPLed part. But it gives the general idea.
A separate question is: what boilerplate headers do I put on the relicensed files? A big part of that question is whether you end up having to obey both licences or just the new one, and that depends on the two licences concerned. So this question is complicated enough that it’s best to ask for advice for any specific case. (But implementing the answer is probably a lot easier than chasing down hundreds of contributors!)
[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:
Join the discussion in mozilla.legal.
In 2005 and 2006, I wrote a fortnightly series of online-only columns for The Times newspaper. I attempted to get them to agree to a free content license for the text, but I was unsuccessful. At that time, there were far fewer precedents for that sort of thing, and I didn’t have nearly enough clout to persuade them to make an exception for me.
Still, I decided that the experience was probably worth it, and the money was useful. (Although my cousin, who is in the publishing industry, told me later that they paid me significantly under the going rate; and they also paid on 45-day terms, which I think is pretty shoddy behaviour.) I wrote a couple of pieces with which I was really quite pleased. And I was happy that, even if I didn’t have full rights, everyone could read them. I eventually stopped submitting work when my editor stopped replying to my emails.
Recently, revising my website, I came across the page where I linked to them all – but they are no longer available to read on the public web. They are behind the Times’ paywall. And, although I do have copies of the text I submitted, because I don’t own the rights, I can’t put up mirrors. So, I can no longer share my creative work with people who might want to read it.
Lesson learned: only release your creative work under free content licenses.
Regular readers of this blog may remember some of my chronicles, under the name “Protecting Germans”, of the efforts of our German legal team to deal with “subscription trap” websites, which are particularly a problem in that country. Such sites try and trap you into signing up for a subscription to get software which is available for free download elsewhere. Firefox is regularly abused as one of the popular software programs whose ‘availability’ prompts users to register on such websites.
Now, I am pleased to be able to tell you that a couple of months ago, in the Hamburg criminal court, sentence was passed on 7 operators of such fraudulent download websites, handing down sentences of 3 years and 9 months for the ringleader, and shorter sentences and fines for the other accused. This is the first ever criminal trial against the operators of subscription trap sites, and the judgment has been eagerly awaited by the public prosecutors in other German cities, who are building cases against other people involved in such schemes.
It is important to note that the court partly founded its judgement on the infringement of Mozilla’s trademarks. The main focus of the proceedings from the outset was on criminal fraud (vis-à-vis the consumers) and the trademark infringement claims were only given their due attention and relevance as a result of our supportive work. (Mozilla participated in the proceedings as one of the harmed rights-owners.)
Furthermore, the main proof which persuaded the court of the defendants’ intention to infringe Mozilla’s trademarks was their knowledge of the civil injunctions we had obtained as early as 2007 and 2009 against two of their websites.
We therefore feel that our support and participation in the proceedings was truly significant and worthwhile. The German press has been applauding the decision, which will hopefully set a precedent for other criminal proceedings against online fraudsters.
I personally feel that this is a vindication of our policy of maintaining and defending the Mozilla trademarks, and especially the Firefox trademark.
You can also read the official Mozilla blog post about this.
15541 files changed, 48359 insertions(+), 494914 deletions(-)
So that’s about 450,000 fewer lines of code in the codebase…
This is a public service announcement. There is a top-level directory in mozilla-central (and similar repos) called “other-licenses”. Don’t put any more code in it. Really. There’s now even a README saying so.
Longer version: this directory is not for non-MPLed code, it’s for non-MPL-compatible code, of which we have very little. There is some stuff in there which shouldn’t be, but let’s not make it worse, OK? :-) Keep your code where it logically lives; don’t make your life harder than it needs to be. If you really think you are importing code which needs to be in there, you should be talking to licensing@mozilla.org first (as with any code import) and explicitly saying you think that this is where it should go, so they can tell you that you’re wrong ;-)
If you are a software engineer, or in fact any sort of engineer, I strongly suggest you take careful note of what I will call “Lindholm’s Law”:
Never send a recorded communication containing a statement of opinion or decision on an IP-related legal question to someone who is not a lawyer.
Tim Lindholm’s unfortunate statement, contained in an email which was the subject of heavy legal argument in Oracle vs. Google, was:
We conclude that we need to negotiate a license for Java under the terms we need.
Even though one of the addressees of the email was a lawyer, and even though the email said “Attorney Work Product” and “Google Confidential” at the top, the court ruled that it was not attorney-client privileged, and could be used by Oracle in court. Read why.
Harvey Anderson, Mozilla’s General Counsel (that is, chief lawyer), has written a couple of blogposts recently on Mozilla and software patents.
Also noteworthy is Twitter’s announcement today of the “Innovator’s Patent Agreement” (IPA), a model agreement for companies to come to with their employees, such that the company can still file for patents on the employee’s inventions but those patents can only be used defensively. You can read the draft IPA on GitHub, and even fork it and submit pull requests :-)
You couldn’t make it up. The vote on an amendment to some “orphan works” legislation in the EU’s Legal Affairs committee (which has the responsibility of “safeguarding the integrity and trustworthiness of the legal framework as a whole in Europe”) was lost 14 votes to 12. Nothing wrong with that, except that there were only 23 voting members. In other words, there was a 113% turnout – a figure of which Vladimir Putin or Robert Mugabe would be proud.
When it was pointed out that these 3 phantom votes could have affected the outcome, a re-vote was nevertheless denied.
Front-runner for “understatement of the year” goes to Christian Engström, Member of the European Parliament for the Swedish Pirate Party, who said:
“What can I say? There is a lot of room for improvement when it comes to democracy in the European Union.”
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:
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.
We’ve shipped it :-)
A blog post will be forthcoming soon on what this means logistically for the Mozilla project, in terms of our announced migration to use the MPL 2 for Mozilla code.
Mozilla is on the verge of completing an 18-month process to revise the Mozilla Public License (MPL), the licence it has used for most new code since the original release of the source code in 1998. MPL 2 is about half the length of MPL 1.1, has many provisions removed which have become onerous to comply with, and has better compatibility with other licences.
Many in the Mozilla community, including the project leadership, have reviewed drafts of the upcoming version and are eager to adopt it, in place of the tri-licensing scheme we currently use. (The MPL 2 is compatible with the LGPL and GPL, like the tri-licence.) We’d like to make sure all of the Mozilla community is aware that a decision on upgrading our code to the MPL 2 will be made shortly, and if there are any issues with doing so, we’d like to know about them before the licence is finalized.
We invite project participants to review the licence and raise any issues or questions they may have.
There is also a document about the upgrade process, which explains how we would go about it. Feedback on the proposals therein – both in mechanism and scope – is also very welcome.
Feedback can be sent to the mozilla.governance discussion forum.
I have recently had several reports of emails circulating like the following. These emails are fraudulent – Mozilla is not giving away £750,000, and if we did, we would not just randomly email people and offer them the money.
Sir/Madam,
Your E-mail Address has won (Seven Hundred and Fifty Thousand Great British Pounds only) GBP750,000 in the Mozilla Firefox Online promo recently conducted. To claim the prize, contact us back for confirmation at: <address removed>
Congratulations!
Yours faithfully,
Sir. Nelson Gordon
Coordinator Mozilla Firefox Online Promo
Hopefully this blog post should show up in web searches for people who are smart enough to check before replying.