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.
tags: open source
| comments: 6
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/5379
Comments: 6
"I'll leave aside the question of whether a software license is the right place to address hardware freedom"
If the ability to use and modify software is compromised by copyright law, this is an issue of software freedom. If the ability to use and modify software is compromised by hardware, this is an issue of software freedom. The only difference between tackling copyright restrictions on software and tackling hardware restrictions on software is that the latter is new. In neither case is this an issue only of software source code.
Don't confuse the specific historical measures taken to pursue software freedom with the general principle. You wouldn't accept criminal law that punishes horse theft with hanging but doesn't have anything to say about car theft or credit card skimming. Don't ask for equivalent change blindness in free software licenses.
Releasing lots of hardware designs either requires that manufacturers be forced to make hardware that allows GPL software to always be installed or requires that the creators of those designs allow manufacturers to tivoise the designs and lock out free software. The former can be achieved just as well with a software license. The latter simply concedes the point but does so in a way that allows failure to be blamed on the market. Neither case is better than the GPL tackling tivoisation in the way that is currently proposed.
I don't understand how this provision of the license affects Digital Rights Management used by content companies.
The anti-DRM clause is "3. No Denying Usersí Rights through Technical Measures". I'll address it in a separate post.
If the ability to use and modify software is compromised by copyright law, this is an issue of software freedom. If the ability to use and modify software is compromised by hardware, this is an issue of software freedom.
The ability to use and modify the software isn't hindered at all by tamperproofing. You can modify TiVo Linux and install it on your own hardware. The only thing that's hindered is your ability to install new software on the particular piece of hardware that's tamperproofed.
Releasing lots of hardware designs either requires that manufacturers be forced to make hardware that allows GPL software to always be installed or requires that the creators of those designs allow manufacturers to tivoise the designs and lock out free software.
Releasing hardware designs doesn't require either of those things. It requires ingenuity and hard work to develop and test the designs. It requires the foresight to adopt business models based on manufacturing and support rather than on proprietary designs. These are exactly the same things that were required to make free software a success, just applied to a new domain.
The former can be achieved just as well with a software license.
The User Products clause does not force manufacturers "to make hardware that allows GPL software to always be installed". The GPLv3 will have no effect unless GPLd software is already installed on the hardware. It's highly likely that the clause will only encourage manufacturers to stay away from GPLd software in the first place, thus escaping the clause entirely. So, no, a software license can't achieve the same result as real efforts in hardware freedom.
"What the third draft doesn't fully address is the concern that there are legitimate uses of tamper-proofing hardware, primarily in security applications."
But what we're talking about here isn't tamper-proofing in the security sense that is usually meant by the term. After all, a sufficiently determined attacker (and this not a very high threshold) can still physically modify the hardware.
What we're taking about is just inconveniencing legitimate users from exercising their legal rights.
For the legitimate security uses you are referring to, what is really needed is "tamper evident" software, which can be accomplished via far more transparent means, none of which (as far as I am aware) are precluded by the GPLv3 language.
I do, however, agree that limiting the restriction to 'User Products' makes little practical sense.
"The ability to use and modify the software isn't hindered at all by tamperproofing. You can modify TiVo Linux and install it on your own hardware. The only thing that's hindered is your ability to install new software on the particular piece of hardware that's tamperproofed."
If the ability to run the software in a particular context is removed, then the ability to run the software in a particular context is removed. This is bad both from a rights and a gift/sharing point of view and needs tackling if confidence in both is to be maintained.
"Releasing hardware designs doesn't require either of those things. It requires ingenuity and hard work to develop and test the designs. It requires the foresight to adopt business models based on manufacturing and support rather than on proprietary designs. These are exactly the same things that were required to make free software a success, just applied to a new domain."
The thing that was required to make this a success for Free Software was the removal of the danger of cashing out. This was effected by the GPL. Without similar protection for hardware this will not happen. Interestingly, if hardware is designed to run software then the requirement that software be freely modifiable can have some bearing on this.
"The User Products clause does not force manufacturers "to make hardware that allows GPL software to always be installed"."
No, it requries that manufacturers who take GPL licensed software and install it on their hardware respect the rights of their users.
The User Product Clause ensures that GPL-licensed software modified by a hardware vendor can always be modified and re-installed on its original installation platform. This is a defense of freedom and therefore a good thing. Anything else is BSD, which is lovely for economic exploitation but useless for user freedom.
"The GPLv3 will have no effect unless GPLd software is already installed on the hardware."
Yes, this is the limit of the GPL's effectiveness anyway. GPLv3 will have no effect on Vista unless MS decide to link to a GPLv3 library for example.
"It's highly likely that the clause will only encourage manufacturers to stay away from GPLd software in the first place, thus escaping the clause entirely. So, no, a software license can't achieve the same result as real efforts in hardware freedom."
The GPL wishes to protect your ability to run GPL-ed software wherever it is found. Where this requires reacting to the abuses of hardware vendors it should not be confused with attempts at hardware freedom, however obviously important that may be.
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- Rob Myers on GPLv3, User Products Clause: "The ability to use and...
- Michael R. Bernstein on GPLv3, User Products Clause: "What the third draft d...
- Allison Randal on GPLv3, User Products Clause: If the ability to use a...
- Allison Randal on GPLv3, User Products Clause: I don't understand how ...
- Rob Myers on GPLv3, User Products Clause: "I'll leave aside the q...
- JVDeLong on GPLv3, User Products Clause: I don't understand how ...
RADAR TOPICS
JVDeLong [03.29.07 08:10 AM]
I don't understand how this provision of the license affects Digital Rights Management used by content companies. Some of the FSF staff commentary expresses huge antipathy to all forms of DRM. But Bruce Perens recently wrote that the interpretation that v3 forbade DRM is all FUD. For a non-programmer, the language is murky.
This issue is crucial to content companies, which are unlikely to embrace any software that precludes DRM (however much some in the tech community are opposed to it), which in turn will have a huge impact on whether software programs such as Linux can adopt v3.
Clarification would be much appreciated.