GPLv3, User Products Clause

I’ll split my comments on the third draft of version 3 of the GPL over a series of posts, each focused on one aspect of the license.

The User Products clause has appeared in every draft of the GPLv3, in various forms. It has been called the “TiVo clause” and various other names, but by any name the basic principle is the same. It addresses situations where a company, such as TiVo, sells a hardware product that runs free software, and releases the source code of their modified version of the software (satisfying the GPLv2), but employs some technological measure to prevent the installation of user-modified versions of the software onto the hardware.

The third draft of this provision in GPLv3 is a significant improvement over earlier drafts. The terms are now in the section on distributing compiled versions of the code, they’ve abandoned the dubious assertion that encryption keys are part of the “source”, and changed to a definition of “Installation Information”:

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

Another advantage of this change is that it moves away from a very narrow definition of a particular technology used in tamper-proofing (“encryption keys”), to a definition based on results (the ability to run the modified code). In the earlier drafts it would have been too easy to employ an alternate technology for tamper-proofing that complied with the letter of the license while circumventing the intention of the license.

What the third draft doesn’t fully address is the concern that there are legitimate uses of tamper-proofing hardware, primarily in security applications. The first and second drafts would have blocked all combinations of GPL licensed software with tamper-proofed hardware, whether it was being used to prevent end-users from adding features to their digital video recorders, to lock down the software on household or office security systems, or to prevent dangerous modifications to hospital equipment. The third draft weakens the restriction, limiting it to consumer electronics. In the PDF of rationale for the third draft they comment:

Most, if not all,
technically-restricted devices running GPL-covered programs are consumer
electronics devices, and we expect that to remain true in the near future.
Moreover, the disparity in clout between the manufacturers and these users
makes it difficult for the users to reject technical restrictions through their
weak and unorganized market power. Even if limited to User Products, as
defined in Draft 3, the provision still does the job that needs to be done.
Therefore we have decided to limit the technical restrictions provisions to
User Products in this draft.

The FSF deserves credit for listening to the companies who reviewed earlier drafts and expressed concerns about the limitations of the “TiVo clause”. But the resulting compromise leaves them in the odd position of distinguishing which companies need to comply with the restriction by how they intend their hardware or software to be used. This seems odd considering that one of the fundamental tenets of free software is that the distributor doesn’t get to impose their purposes on the user. It has a strange effect too: why should an office security system be allowed to use tamper-proofing, while a home security system can’t? It opens up the potential for some very messy court cases where a company works to demonstrate that they didn’t intend their product to be a used as a “consumer product” but only for business applications. Basing the definition of “User Product” on the Magnuson-Moss Warranty Act is also an unfortunate choice, dragging a large history of US case law into what’s intended to be an international license.

I’ll leave aside the question of whether a software license is the right place to address hardware freedom. It certainly isn’t the most effective place to address it. A more compelling scenario (and a better parallel to the success of the GPL in software) would be releasing large quantities of open hardware designs and components with licensing terms comparable to the GPL, then relying on the free availability of the designs and comparatively low cost of the components to revolutionize the hardware industry.