English [en]   français [fr]   português do Brasil [pt-br]  

For Clarity's Sake, Please Don't Say “Licensed under GNU GPL 2”!

by Richard Stallman

When I wrote the GNU General Public License (GNU GPL), in 1989, I recognized that changes might be necessary: the FSF might someday have reasons to publish a new version. So I called the license “version 1,” and set up a framework to enable users to upgrade programs to later license versions.

There was no customary way of doing this with a free license; as far as I know, it had never been done before. Developers had released a new version of a program under a different license, and maybe they had made new releases of old versions offering use under a different license, but they had never set up a systematic way to offer users the choice of using a future license version for already-released versions of a program.

I did not know how developers would respond to this innovation, so I decided to give each developer a choice about allowing future versions. This meant developers could release a program under GNU GPL version 1 only, or release it under GPL version 1 or any later version. The way developers state their choice is in the license notice that goes at the start of each source file. That's where the GPL says the decision is stated.

The Free Software Foundation urged developers to choose or any later version, since that meant users would be free to use that program under GNU GPL version 1, or under version 2 (once there was a version 2), or under version 3 (once there was a version 3). And they will be free to use it under version 4, if we ever have to make a version 4.

Since then, the FSF has released GNU GPL version 2 in 1991 and version 3 in 2007. Each version offers developers the choice to insist on that one license version only, or permit use under future license versions. (GPL 3 also permits the “proxy” option, where a specified Web page can subsequently give permission to use a particular future version.)

Publishing programs with license upgrade permission is vital to avoid incompatibility between programs released under different GPL versions.

Two different copyleft licenses are almost inevitably incompatible in the absence of some explicit compatibility mechanism. That is because each one necessarily requires modified versions of a program to be released under that very same license. As a consequence, code released under GPL version 2 only can't be merged with code released under GPL version 3 only.

The mechanism for compatibility between GPL versions is to release a program under “version N or any later version.” A program released under GPL-2.0-or-later can be merged with code under GPL-3.0-or-later, because “3 or later” is a subset of “2 or later”.

Some developers say, “I will release now under GNU GPL version 3 only. When I see GPL version 4, if I like it, I will relicense my program to allow use under version 4.” That will work fine if you are the only author, provided you're still alive, healthy, contactable, and paying attention at that time. But copyright lasts an insanely long time nowadays; in the absence of major reforms, the copyright on your code will last 70 years after your death, in the US (and 100 years, in Mexico). Have you made arrangements for your heirs to consider the question of relicensing your code to GPL version 4 if you are no longer around to consider it?

But trouble will happen even during your lifetime. What if we release GNU GPL version 4 ten years from now, and by that time 50 others have added to your program, releasing their added code under GPL-3.0-only simply because you did? You could approve GPL 4 for the program you initially released, but it would be a big job to contact the 50 subsequent developers at that time to get their permission for GPL 4 usage of their additions.

The way to avoid these problems is by approving future GPL versions in the license notice at the outset. Please put on each nontrivial file of the source release a license notice of the form shown at the end of the GPL version you are using.

Because we handle license compatibility this way, when people tell you a program is released “under GNU GPL version 2,” they are leaving the licensing of the program unclear. Is it released under GPL-2.0-only, or GPL-2.0-or-later? Can you merge the code with packages released under GPL-3.0-or-later?

When sites such as GitHub invite developers to choose “GPL 3” or “GPL 2” among other license options, and don't raise the issue of future versions, this leads thousands of developers to leave their code's licensing unclear. Asking those users to choose between “only” and “or later” would lead them to make their code's licensing clear. It also provides an opportunity to explain how the latter choice avoids future incompatibility.

Abbreviated license indicators such as “GPL-2.0” or “GPL-3.0” will lead to confusion too. People and organizations that don't recognize the difference between “2 only” and “2 or later” will be prone to write “GPL-2.0” in both cases, not realizing there is a distinction to be made.

Therefore, when you use SPDX license indicators, please use these:

Please do not use the old, ambiguous license indicators, which will be deprecated:

Giving developers the choice of GPL version “1 only” or GPL version “1 or later” seemed obligatory in 1989, but it has created a complexity that we would be better off without. Meanwhile, several licenses that unconditionally give users the choice to upgrade to later license versions have become widely accepted. These include the Mozilla Public License, the Eclipse Public License, and all the Creative Commons licenses. Each version says that a user is free to use the work under later versions, if any, of the same license.

Perhaps we should switch to that approach for future versions of the GNU GPL. But that is something to think about in the future.

We thank SPDX for deciding to change the the short identifiers for the GNU family of licenses to make the “or later” versus “only” choice explicit. The upcoming version of the SPDX License List for license identifiers will use the identifiers recommended above. The confusing identifiers, such as “GPL-2.0,” will be deprecated. We ask people to replace them with the new unambiguous identifiers as soon as possible.

By using identifiers that are explicit as to only or any later version, we can make the community aware of the difference and encourage developers to state their decisions clearly.

BACK TO TOP


 [FSF logo] “The Free Software Foundation (FSF) is a nonprofit with a worldwide mission to promote computer user freedom. We defend the rights of all software users.”

The Free Software Foundation is the principal organizational sponsor of the GNU Operating System. Support GNU and the FSF by buying manuals and gear, joining the FSF as an associate member, or making a donation, either directly to the FSF or via Flattr.