Relicensing: When Do You Have To Ask?

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 project has formally aggregated copyright (e.g. each contributor has signed a CLA), and the aggregate copyright holder agrees; or
  • The move is to a later version of the same licence, and either the license allows that (e.g. the MPL), or the license boilerplate on the files permits it (e.g. the standard GPL boilerplate); or
  • The move is to a “compatible” license.

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:

  • Two permissive licenses are compatible if the terms of A are a subset of, or can be complied with at the same time as, the terms of B.
  • Permissive licenses are usually compatible with copyleft licenses, with the notable exception (according to the FSF) of Apache Public License 2.0 → GNU General Public License 2.0.
  • Two copyleft licenses are not compatible unless A has a specific provision which allows relicensing under B.
  • Copyleft licenses are never compatible with permissive licenses (that would destroy the copyleft).

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!)

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

Cut Off From My Own Creations

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.

Another Victory: More Germans Protected

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.

The ‘other-licenses’ Directory: Don’t Use It

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 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 ;-)

Lindholm’s Law

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.

Mozilla and Patents

Harvey Anderson, Mozilla’s General Counsel (that is, chief lawyer), has written a couple of blogposts recently on Mozilla and software patents.

  • The first was about the Microsoft purchase of the AOL/Netscape patents;
  • The second contains some more general thoughts on Mozilla’s patent strategy.

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 :-)

EU is 113% Democratic

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.”

“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.

MPL Upgrade for the Mozilla Project

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.

Hoax: Mozilla Firefox Online Promo

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.


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>


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.

Brain Patents in Bangladesh

How would it feel if someone told you they had a patent on the way part of your brain worked, and you were not allowed to use it without paying them money?

I have recently been on a trip to Bangladesh. The main language in Bangladesh is Bangla, which they take very seriously. I wrote the first draft of this blog post on 21st of February, which is “Shohid Dibosh“, Language Martyrs’ Day, in Bangladesh. Back in 1952, Bangladesh was East Pakistan – Pakistan then being one nation in two parts, separated by a thousand miles of India. At least five Bangladeshis were shot dead during a protest about wanting Bangla to be the national language of their part of Pakistan, rather than everyone having to learn Urdu, the language of West Pakistan. (Bangladesh became independent in 1971.) Bangladeshis see their right to use Bangla as one paid for in blood.

So, with the coming of computers, Bengali people wanted to use their computers in their language. But Bangla has its own script (the alphabet has about 60 characters, but no case distinction), and there was no way to type it. A keyboard layout and software was needed. The first popular system was created by a Bengali named Mustafa Jabbar, who had a publishing company. He came up with a layout and software to translate the key presses into code points, and some fonts to display them. This system is known as Bijoy. As businesses switched to computer-based publishing, they adopted Bijoy.

In 1989, Mr Joppa was granted a copyright on his keyboard layout, and in 2004, a patent. That meant that all Bijoy keyboards sold required a license from him, and they all came with his software – for Windows or Mac. Patents in Bangladesh have long expiry times – 50 years from the death of the inventor. (In the US and Europe, the time is 20 years from the date of filing.) For a long time, this was the only system available – so many people learned it. Even when others were invented, Bijoy came bundled with every keyboard and matched the markings on it – so there was little incentive to purchase anything else.

However, the original Bijoy software output character codes in the ASCII range, like all of those incompatible ISO charsets from the 1980s. This causes a number of problems, the biggest being that you need the right font to read the result, and if you don’t have it, you’ll see a load of gibberish.

With the coming of the Internet, this became a serious problem. There was no way of communicating over the Internet in Bangla with any certainty that the recipient’s computer had the right fonts and could read what you are writing. The solution to this problem is Unicode – a system where every character in every writing system in the world is uniquely identified by a number, instead of different scripts all sharing the numbers less than 256. Yet no version of Bijoy supporting Unicode was forthcoming – and there was nothing at all for Linux. And no-one else could solve this problem because of the patent.

To get around this Ankur, the Bengali open source organization, made a new layout, called Probhat, which was semi-phonetic. (Two T-like sounds were mapped to T and Shift-T, and so on.) But it was not very popular. Most people still used Bijoy.

Mr Joppa has actively defended his keyboard patents, claiming that they extend even to similar keyboards. Mehdi Hasan Khan, an undergraduate student, made another keyboard system which was fully phonetic – i.e. type Bangla sounds with Latin letters (e.g. “Shohid Dibosh”) and it would produce the right Bangla characters (“(শহীদ দিবস”). This is how Bengalis had been communicating on the net anyway, so they were used to it. He called it Avro, and (after a while) made it free and open source. But he also included in his system “Unibijoy” – a layout like Bijoy but with 8 keys different, and which output Unicode characters, so people who knew Bijoy could also start typing Bangla on the Internet without reprogramming their entire brain.

Mr Joppa sued him, claiming that Unibijoy was a copy of Bijoy. The case was settled out of court in mid-2010, and Mr Mehedi had to remove Unibijoy from his software.

In 2008, the Bangladesh National Election Commission produced over 10,000 computers to be used for a census of Bangladesh. They used the Avro software with the Unibijoy layout, because the Bijoy licensing fee was too high – so Mr Joppa sued them too. (That case is still proceeding.)

The only organization too big for him to sue is the Bangladesh government. The Bangladesh Computer Council – BCC – designated a form of Bijoy (also slightly modified) as the national keyboard layout. As yet, they have not been sued.

Finally, in 2010, Mr Joppa did produce Bijoy for Linux, which outputs Unicode – but it is closed source.

So now, today, there are not one but at least four ways of writing Bengali – Avro, Probhat, BCC and Bijoy. (For reference, at the bottom of this page I have made a list of how you activate each in Ubuntu Linux.)

If you learnt how to type Bengali any time before 2003, you probably have Bijoy burned into your brain. And switching keyboard layouts is hard. Latin language users – ever tried the Dvorak keyboard? Or Americans/Brits – ever sat down at a computer in France, discovered the top row of keys begins AZERTY, and been reduced to hunt-and-peck? Having the layout you know taken away from you cripples your ability to interact with a computer. Yet Mr Joppa claims he has a patent on your brain working with his system, and if you want to use it, you have to pay him and use his software.

This patent would probably not be classified as a software patent. But it still sucks. There are some types of thing which should not have owners – and human-computer interfaces are definitely one.

The World Intellectual Property Organization website has another telling of this story, with quite a different slant. According to them, all of this constitutes a great success.


As far as I understand it, the ways to use each keyboard system in Ubuntu are:

  • Avro – go to the Avro site and install his package for your distribution. Switch your input method system from iBus to SCIM, then pick the newly-installed Avro input method and the Avro keyboard layout.
  • Probhat – change your keyboard layout to the Probhat keyboard, which comes with Ubuntu. You don’t need an input method editor.
  • BCC – change your keyboard layout to the “Bangladesh” keyboard layout, which comes with Ubuntu. You don’t need an input method editor.
  • Bijoy – if you want to use free software, you have a problem. Mr Joppa’s opposition means there are no good solutions for using Bijoy in Linux with free software. Your best bet is probably to use BCC, and learn the differences.

Thanks to Mahay Alam Khan and Shabab Mustafa for checking draft versions of this post. Any errors remain my own.

Protecting Germans: Translated Subscription Trap Interview

With many thanks to “”, who did the original translation (which I have cleaned up a little), here – now with English subtitles – is the subscription trap investigation from German TV, in which our lawyer Anthonia Zimmermann is interviewed. It’s about 14 minutes long, and well worth watching.

Pull down the Universal Subtitles dropdown, and select “English”.