GPL v3 - What's New?

by Rowan Wilson on 10 September 2007 , last updated

Introduction

On 28 June 2007, the Free Software Foundation (FSF) finally published the third version of their GNU General Public License (GPL). Over the previous eighteen months the Foundation had engaged in an unprecedented public consultation exercise, publishing four discussion drafts on the web and gathering opinions via a specially written web application that allowed anyone to flag sections of the drafts with their comments or concerns. In addition to this, the FSF formed four discussion committees designed to represent the wide range of interested parties from enterprise to private users.

This document attempts to describe the major elements of the GPL v3, how it differs from its predecessor and some of the reasons for these changes. It should be noted that the GPL v3 is offered as an alternative to the GPL v2, rather than a replacement, and many projects continue to use the GPL v2.

What was wrong with version 2?

More than sixteen years separate the GPL v3 and its predecessor. In terms of information technology and software development, they have been extremely eventful years. Despite having been created for a world in which the Internet was an academic curiosity and the phrase ‘open source’ was a reference to journalistic practice, the GPL v2 has generally coped well with the changing world of IT. It is by far the most commonly applied free and open source software licence, and probably the best known.

Nevertheless, by late 2005 Richard Stallman and Eben Moglen (respectively the founder and the lawyer of the Free Software Foundation) had decided that an update was necessary. Stallman had conceived the GPL as a legal tool for protecting what he termed the ‘Four Freedoms’ (perhaps in reference to President Roosevelt’s famous 1941 State of the Union address). The FSF’s Four Freedoms relate exclusively to software usage, and comprise the freedom to run, study, redistribute and improve the software. Although the GPL v2 had spectacularly succeeded in fostering a huge corpus of software that was usable under these freedoms, Stallman and Moglen saw some technological and legal developments that had occurred over the intervening years as potentially very harmful to software freedom. A new licence could perhaps build on the enormous success of the GPL v2 while combating these new perceived threats.

So what were these threats? Broadly speaking they can be summed up as follows:

  • ‘Tivoisation’ and Technological Protection Methods
  • unintentional incompatibility with some open source licences
  • US-specific legal terminology
  • the rise of the web application as a means of realising value from software
  • (emerging long after drafting and consultation had begun) software patent non-enforcement covenants as a means of dividing the free and open source software community

In the next sections we will describe these issues in more detail, and discuss the approaches taken by the GPL v3 to resolving them.

‘Tivoisation’ and Technological Protection Methods

Named after the popular digital video recorder marketed by TiVo Inc, ‘tivoisation’ refers to the distribution of free software in a device which cannot execute modified versions. The TiVo video recorder uses software distributed under the GPL v2 to perform some of its functions, and TiVo Inc. abide by the conditions of the GPL v2 by making the source code to this software available via their website. However, crytpographic signing is required to make the TiVo unit execute software, and this makes it effectively impossible for those who want to adapt the software and reinstall it on their TiVo unit to do so. TiVo are by no means the only company to do this, although they are probably the most successful, hence the coinage. To prevent software licensed under the GPL v3 being subject to the same kind of restriction, the FSF drafted a fairly complex addition to the terms which govern distribution of software in executable form. In early drafts of the GPL v3, the FSF simply added a requirement that - if a cryptographic key or some other vital ‘Installation Information’ were needed to modify and run a piece of software on a device with which it was distributed - then the supplier had to hand that information over along with the source code. As a result of the public consultation, however, the FSF came to accept that it was not necessarily desirable for all categories of GPL-software-bearing devices to be user-modifiable in this way. Cardiac pacemakers were given as an example of something that might prevent user modification for perfectly good reasons of safety. As a result, the category of devices that must be accompanied by a usable signing key was narrowed to ‘User Products’, essentially meaning devices whose primary application is not industrial.

Another concern raised by the FSF related to the legal controls on circumvention of ‘effective Technological Protection Methods’ introduced in many world-wide jurisdictions through the adoption of the 1996 WIPO (World Intellectual Property Organization) Copyright Treaty. The treaty and its resulting embodiment in national legislation created a new way of violating someone’s copyright: cracking their copy protection. It is worth noting that you do not actually have to copy or distribute a protected work in order to fall foul of this new provision; just removing a form of protection that previously functioned is enough. The FSF decided that they were against legislation that prevented what they saw as legitimate tecnological research. As a result, the GPL v3 contains a declaration by the licensor that no code distributed under it can be considered an ‘effective Technological Protection Method’, and thus that no licensor can act against someone modifying their code under the WIPO-based legislation.

Unintended incompatibilities

The fact that free and open source software is so readily available to all sometimes leads people to make incorrect assumptions about what they can do with it. It seems natural to assume that if one can use and distribute it freely, one must also be able to combine it freely. Unfortunately this is not the case. The GPL v2 stipulates that code which it covers must be distributed (if it is distributed at all) under the GPL v2, with absolutely no additional restrictions. This also applies to any modified versions of the code, which would include software products made from a combination of GPL’d code and some code obtained under a different licence. The upshot of this stipulation is that it is only possible to combine GPL’d code with other code obtained under a small set of other open source licences. To be part of the set, a licence must only contain restrictions that are present in the GPL.

Now many open source licences contain restrictions that the GPL does not. In some cases this is exactly what the licence’s authors intended. In others, though, the authors did not want code covered by their licence to be eternally separate from GPL’d code. In the case of the Apache Software License v2, the unintentional incompatibilities arose due to clauses relating to patents. So-called ‘patent retaliation clauses’ in these licences dictated that - if a licensee started patent litigation against any of the licensors - then any patent rights granted through the licence would be automatically withdrawn. The FSF were not against these kind of clauses in principle, although Eben Moglen had publicly questioned their efficacy. So, with the GPL v3, additional restrictions such as patent retaliation clauses became an optional extra for the GPL itself. If one wanted to combine code from an Apache 2-licensed project, it would be necessary to add such a patent retaliation clause to the GPL v3 that covered the eventual release. In that way the distributor could satisfy their responsibilities to the Apache licensor and the GPL licensor, and distribute without violating either licence.

The success of the GPL v2 outside its birthplace in the US meant that its roots in American law became increasingly problematic. To alleviate this, the GPL v3 was drafted using terminology that does not spring from any specific legal tradition. As a result, far more space in the GPL v3 is devoted to definitions of terms, and this has attracted some criticism from lawyers. After all, with greater complexity comes a greater potential for miscommunication and using terminology that no lawyers are familiar with could be seen as an invitation to an argument. It remains to be seen if the great effort spent in divorcing the GPL v3 from its origins in American law will lead to greater or lesser clarity.

In addition to the definition of simple terms, some larger sections of the GPL v2 were tailored to be effective in the US but not necessarily anywhere else. For example, the GPL v2’s Limitation of Liability section was drafted in a way that was - arguably - entirely ineffective in the UK, due to its attempting to entirely exclude liabilities that can’t be excluded here. Thus the desired effect, which was to protect the licensor, was entirely reversed, in that the licensor may be left without any limitation of liability. In reaction to this problem the GPL v3 permits licensors to redraft these sections of the licence to better suit conditions under local law.

The rise of the web application as a means of realising value from software

With the rise of the Internet as a place to do business, more and more open source software is being adapted by companies to run large-scale web services for payment. Under the terms of the GPL v2, this does not count as distribution, and thus the companies in question are under no responsibility to publish the source code to their modifications. Some commentators saw this as a ‘bug’ in the GPL v2 - after all, surely the ethos of the free software community demanded that those who gain greatly from it also contribute back? Others were less convinced, and argued that the activities of web application providers were in accord with both the letter and the spirit of the GPL v2.

It was an issue that the FSF itself could not decide upon, so a sample restriction was included in the first draft of the GPL v3 for public discussion. The clause in question allowed a licensor to incorporate a specialised function into their code which returned the source code of the software if a user requested it over a network. If the licensor decided to include this kind of function, the draft restriction prevented any subsequent modifiers from removing it - indeed they were obliged to maintain it so that it always returned or ‘spewed’ the most up to date version of the source code.

However, this restriction was not retained in the final version of the GPL v3, because a satisfactory alternative was found in the work of a San Francisco-based company called Affero (who provide a system for rating and assessing online volunteers), which had already drafted a variation on the GPL v2 back in 2002 specifically to include a ‘code spew’ clause. This proved to be a neat way of handling the dilemma; those who wanted the restriction could use the Affero version of the GPL on their code, and the final version of the GPL v3 would be adapted to make code it covers combinable with code released under the Affero GPL. To go with the new version of the GPL, the FSF worked with Affero to create a corresponding version 3 of the Affero licence, based upon the GPL v3.

Software Patent Wars

The FSF’s original plan of having the entire GPL v3 composed and agreed upon in twelve months was always extremely ambitious. On 2 November 2006, Novell and Microsoft announced a complex reciprocal deal that many saw as a deliberate attempt to frustrate the aims of the FSF while remaining technically in accordance with the GPL v2. As the free and open source software community began to form a strongly negative view of the deal, it became inevitable that a lot more work would be needed to make the GPL v3 a suitable vehicle for discouraging such deals in the future.

Microsoft and Novell’s collaboration agreement is broad and complex, and its specifics are not available publicly in their entirety. The main irritant for the free and open source software community was the mutual agreement between Novell and Microsoft that they would not use their patent portfolios to litigate against each other’s customers. This had two important implications for free and open source software. Firstly, it gave strength to Microsoft’s oft-stated but never demonstrated assertion that Linux violates Microsoft patents. After all, why would Novell make the deal if they did not believe that their SUSE Linux users were at risk? Secondly, it created a division within the Linux user community. On the one side were those covered by Microsoft’s promise to Novell, and on the other was everyone else. One view was that protection from Microsoft’s patent litigation was a necessary component of any Linux distribution. If that view became widespread, it would create a severe limitation to the free use and adaptation of Linux - effectively driving users to install SUSE or face the wrath of Microsoft. Of course, if that view did indeed become widespread it would be very likely to benefit Novell financially.

The fact that the patent ‘promise’ was directed at the companies’ customers rather than the companies themselves was widely interpreted to be a deliberate evasion of the terms of the GPL v2. Had Microsoft provided an indemnification to Novell itself, Novell would have been prevented from distributing Linux, as their acceptance of what is essentially an additional requirement imposed by Microsoft (to not sue Microsoft’s customers) would have violated the terms of GPL v2 section 7.

To combat what was seen as a new method of suppressing software freedom, the GPL v3 includes two new stipulations. Firstly it dictates that anyone who distributes GPL v3-licensed code and provides a patent licence to some group of recipients must automatically extend that licence to all recipients. This would have an effect on the Novell-Microsoft deal as it includes an agreement to distribute and support each other’s operating systems. Secondly GPL v3 includes a stipulation that you cannot distribute covered code if you enter into a deal with another software distributor that involves your paying that software distributor to not sue your customers (in this case the ‘payment’ would be in the form of an undertaking not to litigate). Some doubt remains over the workability of these provisions, and whether they may trap beneficial patent-cross-licensing deals.

Conclusion

Opinion continues to be strongly divided on the new GPL. Linus Torvalds, originator of Linux and chief maintainer of the Linux kernel, has stated his dissatisfaction with it, and intends to keep on using the GPL v2. On the other hand Jeremy Allison the chief developer of Samba (the widely used free software that provides networking compatibility between Linux and Microsoft’s Windows platform) has announced that he fully approves of the new GPL and will release all future versions of Samba under v3 only. Certainly, it addresses a wider range of activities, thus widening the definition of software freedom; the only issue that remains unaddressed by the GPL v3 is the web services loophole, which is dealt with through the Affero licence. Whatever its virtues as a legal document, success or failure for the GPL v3 will be judged on both its resilience as a legal document and the number of software authors who choose it to protect their code.

Further reading

Links:

Related information from OSS Watch: