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