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!)
I’m a little confused. I’ve always understood “compatibility” to mean in the run-time sense, in that you want to write a program using some code under License X and some code under License Y, and when is that ok or not.
So I don’t quite understand how you can take someone’s code released under one license and re-release it under another license without their explicit permission. (Unless a CLA is in play, or the license explicitly allows for it.) Who defines “compatible”, and how does that intersect with copyright law? For example, if Pedantic Author and Obstinate Relicenser were to take a compatible BSD-to-Apache change to the courtroom, how would that play out?
Just going to bed but, on compatibility: this word has a load of meanings in a licensing context, so best to just let it mean the definition I give here :-)
I’m with Dolske, this just sounds wrong. If I’ve contributed to a file that says “The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software” haven’t you violated the license by taking that statement off?
Yep, I’m pretty sure you can’t re-license “compatible” code like that; specifically, you can’t do it from BSD to GPLv2 – see http://kerneltrap.org/Linux/Relicensing_Code for details of when some people discussed it in the context of an Atheros wireless NIC driver. You are, however, free to use that code – as long as you satisfy the requirements.
You maintain about:license, you should know ;) Otherwise a large set of those would probably wiped out. For example, the “Google BSD” entry is, I think, pretty standard BSD – if that could be relicensed into MPL 1.1/2, I imagine that would already be done.
Who said anything about taking the statement off? See the last para.
Mook: that page is wrong, or at least misleading. You can relicense BSD-licensed code under the GPL, as long as you continue to also obey the BSD license, which you can do because its requirements are a subset of those of the GPL. In practice, what you’d probably do is put a GPL header above the BSD header, which must be retained. Then, future changes would be GPLed and could not be copied back into a BSD-only version.
Of course, whether it’s a good idea politically, and whether people will get upset if you do it, is another question entirely :-)
Stripping the BSD license headers off is a license violation, and Theo has a perfect right to object. Adding the GPL headers is not wrong, it’s perfectly permitted by the terms of the BSD license, even if Theo doesn’t like it.
Oh, and we could take e.g. Google BSD code and make it MPL, but then changes couldn’t be contributed back upstream, so that would be fairly silly. This blog post is about what you _can_ do, not about what it’s wise to do.
Ah. So when you say “relicense” you really seem to be saying “add an extra license”. That is substantially less eyebrow-raising. :) But even if it’s legally OK, it sounds like a bad idea in general.
Well, yes and no. Let’s take an example.
jQuery is under an MIT/GPL dual license. So you can use any of the code either under the terms of the MIT license or the GPL license.
Say I have an MITed project, FooBar, and decide to relicense to the GPL. The MIT license says “this permissions notice must be retained in all copies”, so I do that, but I also put the GPL header above it, and then some text which says: “This file contains code which was originally under this license:” and then the MIT license.
This is different from the jQuery situation. You can’t legally take _any_ of this code and use it under the MIT license – you need to find an MIT-licensed copy of it somewhere. (People might still take it and use it that way, but they shouldn’t.) It has been entirely converted to the GPL, even if the MIT header is still present.
So it depends what you mean by “add an extra license”. I’d say in the second case that’s not really what’s happened, because the GPL is the only license you can use the code under. And it’s different from the first case, where there is a choice of licensing.
Having said all that, it’s clear that this is not as clear as it could be. :-) So I might update the post once this thread comes to a close.
I’ve updated the post to clarify this point – thanks for raising it.
I’ve updated the post to clarify this point as well.
I’ve updated the post to clarify this point also.