License Compatibility and Relicensing

by Richard Stallman

If you want to combine two free programs into one, or merge code from one into the other, this raises the question of whether their licenses allow combining them, or prohibit combining them.[1]

There is no problem merging programs that have the same license, if it is a reasonably behaved license, as nearly all free licenses are.[2]

What then when the licenses are different? In general we say that several licenses are compatible if there is a way to merge code under those various licenses while complying with all of them. The result, often, is a program with parts under various different compatible licenses—but not always. Such combinability, or the absence of it, is a characteristic of a given set of licenses, and is not dependent on what order you mention them in. The set of licenses also controls which license is required for the combined program.

We divide licenses into three classes: lax (also “permissive” or “pushover”), intermediate, and copyleft. A lax license does nothing to interfere with putting the code into proprietary software. A copyleft license prohibits that, by requiring all reuse to be in programs under the same license. An intermediate license puts some conditions on adding proprietary code but does not try to prohibit it.

In general, lax permissive licenses (modified BSD, X11, Expat, Apache, Python, etc.) are compatible with each other. That's because they have no requirements about other code that is added to the program. They even permit putting the entire program (perhaps with changes) into a proprietary software product; thus, we call them “pushover licenses” because they can't say “no” when one user tries to deny freedom to others.

In a combination of programs under lax licenses, each part carries the license it came with. When the code is merged to the point that the parts can't be distinguished any more, that merged code should carry all the licenses of the merged parts. Since all the licenses are lax anyway, this causes no practical problem except that the list of licenses gets long.[3]

By the same token, lax licenses are usually compatible with any copyleft license. In the combined program, the parts that came in under lax licenses still carry them, and the combined program as a whole carries the copyleft license. One lax license, Apache 2.0, has patent clauses which are incompatible with GPL version 2; since I think those patent clauses are good, I made GPL version 3 compatible with them.

The one important exception is the original BSD license, because of the “obnoxious advertising clause.” This condition required a specific notice in all advertising of any product containing any code released under the original BSD license. This was, and is, incompatible with all actual copyleft licenses. It was also a pain in the neck for every distro, as programs accumulated with similar but different advertising requirements. At one point, a BSD distro required over 70 different notices.

I mostly eliminated this problem by convincing a dean, Hal Varian, to arrange for UC Berkeley to publish the “modified BSD license” (without the advertising clause) and rerelease the code of the Berkeley System Distribution under that. Nowadays the original BSD license is (fortunately) rarely used, but we must still take care not to talk about “the” BSD license.

In general, two different copyleft licenses are unavoidably incompatible unless they have explicit compatibility provisions. This is not due to a mistake in the details; it's inherent in the idea of copyleft. The idea of copyleft is that “Modified and extended versions must be under the same license.” If license A (on program P) says extended programs must be under license A, and license B (on program Q) says extended programs must be under license B, they have an irreconcilable disagreement; the license of the combined program which includes code from P plus code from Q would have to be A, and it would have to be B.

This is why GPL version 2 is incompatible with GPL version 3; it could not be avoided. Likewise, the conditions of CC-BY-SA 4.0 would be inherently incompatible with those of CC-BY-SA 3.0, and the authors could not have avoided this.

There are two approaches for avoiding the incompatibility problem caused by different versions of copyleft licenses.

The FSF uses the approach of asking people to release programs under “GNU GPL version N or any later version.” This licensing is compatible with version N, and also with N+1 (because it offers version N+1 as an option). When you combine code under “GPL 3 or later” with code under “GPL 2 or later,” the license of the combination is their intersection, which is “GPL 3 or later.”

We hope we will never need to make a GNU GPL version 4, but nothing is perfect and we can't assume we have anticipated all the issues. By releasing your code under GNU GPL 3 or later, you permit your code to upgrade to GNU GPL version 4 if we ever need one.

The other approach is to make each version of the license explicitly allow upgrading to later versions. The Mozilla Foundation uses this approach, as does PHP. Creative Commons, uses it for CC-BY-SA: version 4.0 (the current version) explicitly permits any user to upgrade to later versions of CC-BY-SA for modified works.

Only the GNU licenses give authors a choice about whether to permit upgrades to future license versions. When I wrote the first version of the GNU GPL, in 1989, I considered including a license upgrade option as is found now in CC licenses, but I thought it more correct to give that choice to each author. Thus, the author could release a program either under “GPL 1 only” or “GPL 1 or later.”

Since then, I have come to question the wisdom of that decision. Programs such as Linux, which allow only one GNU GPL version and reject license upgrades, cause practical incompatibility.[4] If we ever make a GPL version 4, perhaps we should include an upgrade clause that automatically permits relicensing to higher-numbered versions, 5 and up.

Some copyleft licenses allow cross-copyleft combinations with an explicit relicensing clause giving permission to put the code under a different copyleft license. For instance, the CeCILL gives explicit permission to relicense code to GNU GPL version 2 and later versions. If program P is under the CeCILL, and you want to combine it with program Q that's under GPL version 3 or later, the CeCILL says you can do that and put the combination or merged code under GPL version 3 or later.

Explicit relicensing permission is not the same thing as compatibility (though relicensing code can make it compatible with other code) and it is not symmetrical. For instance, the CeCILL gives explicit permission to relicense code to GNU GPL, but the GNU GPL does not permit relicensing to the CeCILL. Thus, you can't combine those two programs P and Q and distribute the combination under the CeCILL; that would violate the GPL in its use of program Q. The only permitted way to release that combined program is under the appropriate GPL version(s).

Likewise, CC BY-SA 4.0 explicitly permits relicensing modified versions to GNU GPL version 3, but GPL version 3 does not permit relicensing to CC BY-SA. This issue should never arise for software code; Creative Commons says its licenses are not meant for code, and says that the license to use for code is the GNU GPL. But there are other kinds of works, such as hardware designs or game art, where you might have occasion to merge material released under CC-BY-SA with material released under the GNU GPL. This can be done through CC BY-SA's explicit relicensing permission.

Unfortunately, CC BY-SA 4.0 does not permit relicensing to future GPL versions. What you should do, when you relicense material under CC BY-SA 4.0 to the GPL, is specify yourself as a license version proxy to indicate whether future GPL versions have been authorized for that material. If someday there is a GPL version 4 and Creative Commons decides to allow relicensing from CC BY-SA to GPL version 4, you as proxy will be able to retroactively authorize use of that relicensed material under GPL version 4. (Alternatively, you can ask the authors of that material to give permission right away.)

The ordinary GNU General Public License and the GNU Affero General Public License are two different copyleft licenses, so they are naturally incompatible. We have set up a special kind of explicit compatibility between them: you can include source code under the GNU GPL version 3 together with other source code under the GNU Affero GPL in a single combined program. This is permitted because both of those licenses explicitly say so, and the effect is that the GNU AGPL applies to the combined program. However, you can't simply relicense code from the GNU GPL (with or without “or later”) to the GNU Affero GPL, or vice versa; neither of these licenses gives permission for that. Note also that the GNU Affero GPL version 3 is not a “later version” of the ordinary GNU GPL version 2, because the GNU Affero GPL and the GNU GPL are two different series of licenses.

The GNU Lesser General Public License, version 3, is really the GNU General Public License version 3 plus some added extra permissions. GPL version 3 (section 7) says you can always remove added permissions, and by doing so you get the same code under the ordinary GNU GPL version 3. If a program permits use under GNU LGPL version 3 or later, you can relicense it to GPL version 3 or later; for each future GPL version N (N > 3), we will make an LGPL version N which consists of the GPL version N plus added permissions.

As for GNU Lesser GPL version 2.1, that explicitly permits relicensing to GNU GPL version 2 or later.

Intermediate licenses are those which have substantive requirements on redistribution but are not copyleft licenses. Examples include the Eclipse Public License and the Mozilla Public License. Intermediate licenses tend to be incompatible with any copyleft licenses because their requirements don't permit the combined program to be under the copyleft license. The Mozilla Public License permits relicensing to the GNU GPL except when the code explicitly denies this permission.

Finally, what about dual licensing?[5] A dual license is a disjunction: it means that the same program carries a choice of two or more different licenses. For instance, older versions of Perl carried a dual license: the disjunction of the Artistic License and the GNU General Public License. This meant that each user could choose to use and redistribute Perl under one license or the other, or under both in disjunction like the Perl release itself. A disjunction is compatible with a set of other licenses if any one of the license choices in the disjunction is compatible with that set.

When you choose a license for your code, please choose GNU GPL version 3 or later, or some license compatible with that. This is the way to make your code combinable with nearly all the corpus of free software. Choosing GPL or AGPL, version 3 or later, will also do the utmost to defend freedom for all users of all versions of your code.

Combining code

When a set of licenses are compatible, that means you can legally combine or merge a number of programs each licensed under one of those licenses. How, then, is the combined program licensed?

Each free software license says you must keep the license with the code that is covered by it. So in a strict sense, the licensing of the combined program includes the licenses of all its parts. However, sometimes you want a summary answer to the question of how the combined program is licensed. Which licenses does someone using the combined program need to pay attention to?

To compute that, you start with a list of all the pertinent licenses. Then you can delete from the list any license which is subsumed by another in the list.

We say that a license A subsumes license B when compliance with license A implies compliance with license B.

For instance, the GNU GPL version N and the GNU Affero GPL version N both subsume the GNU Lesser GPL version N, and all three of those subsume the GNU Lesser GPL version 2.1.

Any GNU license, version N, subsumes the Apache 2.0 license provided N is at least 3.

The GNU GPL, version N, subsumes all versions of the Mozilla Public License that are compatible with it.

The Apache 2.0 license subsumes the BSD, Expat, X11, ISC and CC-0 licenses. BSD 3 clause subsumes BSD 2 clause. The BSD licenses subsume the Expat, X11 and ISC licenses and CC0.

This is not meant to be a complete list, but if we are informed of other cases worth mentioning, we will add them.

When some license is subsumed, you still need to include a copy of it with all distribution of the combined program.

Footnotes

It is not inconceivable that other legal issues might arise about a specific combination of programs, issues not related to the copyright licenses of the programs to be combined. We discuss only the implications of the licenses themselves.
The main license in actual use that isn't reasonably behaved is the license of TeX: if two programs are licensed just the way TeX is, there is no authorized way to distribute a merged version of them.

The TeX license permits distribution of a modified version only in the form of the original version plus a differences file. If A and B are separately released that way, then merged, distributing the merged program as A plus a change file violates the license of B. Distributing this as B plus a change file violates the license of A. Distributing this in any other way violates both licenses.

It is no coincidence that TeX was released in 1982: our community has learned, since then, to write reasonably behaved licenses.
When distributing in source code form, it is usually sufficient to leave the license notices in the source code as they stand; extra license notice requirements typically only come up for lax licenses when distributing binaries without the source code.
In addition, GPL version 2 still allows binaries to be made nonfree by hardware that rejects all but special signed binaries, and still does not allow distribution of binaries by torrent. We fixed those problems, and others, in version 3, but we can't change version 2.
Some use the term “dual licensing” to refer to selling exceptions, but that is a misnomer. See Selling Exceptions. Note that if the program on which the license is sold includes any code that is not in the free (libre) release, that's not selling exceptions, that's nonfree software.