FSF should separate GPLv3 changes

Commentary: The process of producing the third version of the GNU General Public License (GPLv3) may not be doomed, but, as Linus Torvalds and other kernel developers heat up the rhetoric, it does seem stalled. If the process continues in the way that it has been going, a large number of current users of the GPL may not switch to the new license. Unless the free and open source software (FOSS) communities are willing to risk the possible consequences of that result, it’s time for a change of tactics.

The trouble with GPLv3 is that it contains the accumulation of 15 years’ worth of changes. Some of these changes, such as improvements in the clarity of the language or attempts to make the license more acceptable in a variety of international jurisdictions or to cover BitTorrent downloads, might be accepted with hardly a dissenting comment, if they could be agreed upon separately. Even those who prefer the GPLv2 would probably admit that such changes are necessary improvements that make the license easier to understand and use.

Others changes, such as language about digital rights management technologies and patents, are more controversial by several orders of magnitude. Yet stakeholders have no way to accept or reject the controversial elements separately; they must accept or reject the entire GPLv3. This either-or situation greatly reduces the odds of reaching a consensus.

One solution would be to give stakeholders a chance to accept or reject individual provisions while still producing a new license. I see at least two possible tactics that would achieve this result.

The first tactic is to model GPLv3 after the Creative Commons License, and divide the license into a general section and a series of conditions. The general section would be the text of GPLv2, perhaps modified by the changes for clarity and internationalization. The conditions would be the controversial provisions, which users could mix or match according to their preferences. This change would require massive rewriting, but is less far-fetched than some might think, considering that the drafters of GPLv3 have already taken a step in this direction in the second draft by making the Lesser General Public License simply a version of the GPL with an additional provision. The question is whether the Free Software Foundation would be content to leave the controversial issues as options. Also, the tactic could lead to the same situation that prevails in Debian with the GNU Free Documentation License, in which some forms of the license are accepted and others are not.

The second tactic is to back away from having all the changes accepted at once. Instead of winning consensus on every section at once, the goal would switch to phasing in the changes over several revisions, starting with the non-controversial parts. This approach would give everyone a chance to adjust to the changes, and to discuss the controversial ones as thoroughly as necessary. Most of all, it would safeguard the process. Instead of leaving the community with all or nothing, a series of revisions would at least give us a few improvements if the process broke down at any point. In other words, it would be the safe and responsible choice.

Perhaps just as importantly, it would also remove the false sense of urgency created by an arbitrary deadline. FOSS developers know better than to harness themselves to rigid deadlines; why shouldn’t FOSS license-makers?

Given Eben Moglen’s recent renewed invitation to the kernel developers to join the process — an invitation that ignores questions about the process itself — a change of tactics probably isn’t going to happen. Adapting any new tactics would implicitly mean admitting that the present tactics are failing, and that admission would come hard after all the time people have invested in them. Yet the blow to the Free Software Foundation’s prestige that a change of direction might cause would be nothing compared to the one caused by a complete failure of the process. Moreover, while the FOSS communities might survive the coexistence of GPLv2 and GPLv3, another possibility is that such a situation would remove one of the unifying elements of the community. In particular, as the recent discussion shows, it could make open source and free software supporters opponents rather than allies.

For all the praise it receives today, I suspect that GPLv2 would have been as much criticized as GPLv3 if consensus had been sought for it. Its acceptance probably had more to do with the fact that it was already available than with the perfection of its contents. Compared to the commercial software licenses that were most people’s only point of comparison, it would have been too radical a change for everyone to accept.

Even though GPLv3 is in its second draft, it’s not too late to consider changes to the process and the contents. The inconvenience of such midstream changes may be nothing compared to the consequences of staying on the present course.

Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for NewsForge, Linux.com and IT Manager’s Journal.