On forking and license patching
Alexandre Oliva
In a world in which nobody stopped others from adapting and sharing software, we wouldn't need measures to defend users' freedoms to run, study, adapt and distribute software, with or without modifications. Unfortunately, we don't live in such a world. All the time, for various reasons, people are thinking of new ways to deny users the possibility of adapting and running software for any purpose, or of sharing it with others. Enters the GNU General Public License.
The GPL was designed to ensure that Free Software remains Free for all its users. It's a license that uses copyright law to arrange for anyone who modifies or distributes the program to refrain from denying other users' the Free Software freedoms. Like any complex work, it may contain errors.
Historically, errors in the GPL have been omissions: failure to clearly cover certain possibilities of denying users' the freedoms they ought to have. Possibilities that, in some cases, only materialized as a result of new laws, or as a result of creative minds looking for means to exploit the license and the code it covers.
Foreseeing this situation, the FSF, creator of the GPL, has always recommended authors to license their works not only under a specific version of the GPL, but rather under that version "or any later version" published by the FSF, under a public commitment that later versions would be similar in the spirit of respecting and defending users' freedoms such that Free Software remains Free for all its users.
With this arrangement, whenever a hole is found in the license that enables any licensee to deny other users the enjoyment of the freedoms, a newer version can be published that plugs the hole, and software published under terms that follow the recommendation can trivially adopt and collect the benefits of the new defenses in any improvements introduced from that point on.
License compatibility
Under this light, almost by definition, newer revisions of the GPL will be incompatible with the earlier revisions, because the whole point is to plug holes in them. This amounts to further restrictions, which the earlier versions would prohibit in the absence of express permission to follow the terms of later versions.
For various reasons, some developers chose to cut their license patching path. Not only have they diverged from the recommendation of the FSF, denying users the ability to follow the terms of newer versions of the license; they have also painted themselves into a corner in which not even themselves can patch holes in the license without getting express agreement from all copyright holders of the project.
Provisions along the lines of "or any later version", but that refer to some other license or entity, would have helped alleviate this problem. But they were not taken. As a consequence of this decision, these developers are unable to patch their licenses, and they're also unable to merge improvements for their works that are only available under incompatible licenses, such as newer revisions of the GPL.
Everyone who followed the recommendation of the FSF will remain able to trivially integrate license upgrades published by the FSF, and to integrate improvements made available under terms that also follow this recommendation.
It is not fair for developers to blame the FSF for their inability to merge code published under newer versions of the license. It is a consequence of their own short-sighted decisions.
Forking projects
Opposition to the better defenses for freedom added to revised versions of the GPL, or to confusion induced by misinformation spread about these defenses, often results in concerns about forking of projects licensed under the recommended terms.
Such forks, that could sprout in attempts to avoid the restrictions established by the new revision of the license, would stick to a fixed earlier version of the license, while the original project adopts a later baseline license version.
From that point on, the two lines of development can no longer cooperate. The original project can't merge improvements made for the fork, because the license of the fork won't permit combination with the more restrictive later revisions of the license, and the fork can't merge improvements made for the original project or other projects that similarly upgrade the license baseline and stick to the FSF recommendations, because the fork rejects the stronger defense of freedoms.
This forking is most often a bad thing for all parties involved. Splitting the community and duplicating efforts like this is far more likely to lead to wasted efforts than to enrich the software diversity in the long term.
But in this case too, faulty reasoning attempts to shift the blame of the fork onto the FSF. The FSF is consistently pursuing the goals it publicly set for itself and for the GPL, maintaining the same spirit while patching holes. It is the forkers who make the decision to fork, to depart from the path suggested by the FSF, that enables modification and sharing of code, while defending the freedoms of users from threats as they arise.
It is not fair to blame the FSF for the bad consequences of decisions made by the forkers themselves.
Conclusion
The FSF recommendation to release software under the GPL or any later version is intended to ensure the continued ability to share software among developers who share the goals of respecting and defending users' freedoms.
Specific versions of the GPL may be used to serve other goals, but this is no guarantee that revisions of the license will still serve those goals. Each version will remain available for use by those who pursue the goals it matches, and no copyright holder can possibly be forced to relicense her/his work under a license s/he doesn't want to use.
Any inability to share code between projects that are committed to respecting and defending users freedoms, and projects that pursue different goals, should not be framed as consequence of the FSF's pursuit of its public goals set before the licenses even existed. It's rather an exposure of differences between the goals of the projects. Having been able to share code for some time was just a lucky coincidence.
Only using the GPL with the recommended practice, understanding and accepting its goals, ensures the ability to share code with others who share the same goals and follow the same practice. Departures from the practice or from the goals are consequences of adopting the license without sharing its goals and without following the recommended practices. The FSF should not be blamed for others' decisions.
Copyright 2007 Alexandre Oliva
All rights reserved for now, because this is still an early draft. Please don't publish the URL or quote this article before its final publication.
Permission is NOT YET granted to make and distribute verbatim copies of this entire document without royalty provided the copyright notice, the document's official URL, and this permission notice are preserved.