The following editorial was contributed by Ciarán O'Riordan of FSFE. Working for FSFE since April 2005, Ciarán has been raising public awareness and participating in public discussion on GPLv3 since the launch in January 2006 and contributes heavily to FSFE's GPLv3 project.
Discussion draft 3 of GPLv3 is due in early November, approximately. Before that is finalised, I'd like to review the debate over DRM and the Linux kernel developers. Discussion draft 3 may be the final discussion draft, so I'd like to encourage discussion of this issue so that people can make comments now (via gplv3.fsf.org) which can be taken into account for draft 3.
GNU GPL version 2 is a great licence. It's an amazing licence when we remember that Richard Stallman wrote it pretty much on his own with some legal counsel. This year, the community's input is solicited and four teams comprising 130 people have been formed to research each issue raised by the community. With fifteen years of hindsight, and will brains from around the World, I think we can write an even better licence.
The decision for whether the Linux kernel will relicense to GPLv3 can really be made when the official GPLv3 is published in early 2007. Relicensing Linux will not be simple, due to it's hundreds or thousands of copyright holders, but it can be done if there is a will. (I previously wrote about how this works in "Can the Linux Kernel Relicense?") Right now is the time for debating what the licence can do, should do, and what options it should leave open. In this article, I'll focus on DRM.
What GPLv3 says about drm:
About DRM, draft 2 says you may distribute the software:
...provided you also distribute any encryption or authorization keys necessary to install and/or execute modified versions...
(From Section 1, paragraph 4)
For the vast majority of distributors of GPL software, this requirement has zero impact because in normal circumstances, no keys are necessary to install and/or execute the distributed software. The rare special case that will be impacted by this clause is where software is being distributed as a software+device bundle and the Device is Rigged to Malfunction if it detects any software that hasn't been somehow authorised by the hardware distributor.
From following the debate over GPLv3 and DRM, I think the requirements are quite a bit smaller than one would imagine if they read only second-hand sources. There are some more DRM-related words in GPLv3 draft 2, but I think the above quote is the bulk of the substance.
Why is the drm stuff there?
For three reasons:
(A) Freedom. The philosophy of the Free Software movement is that computer users should be free to help themselves by modifying the software on their computer. If running a modified version requires a password, then the recipient of the software must be given the password so that they can make use of this freedom to help themself.
Since the start, this has been offered as the reason to support the DRM clause. In hindsight, that was probably a mistake. Freedom is the reason for the Free Software movement, but it is not the beginning and end of why combating DRM in our licences is a good idea - just as freedom isn't the only reason why people used GPL version 2. On to the other two...
(B) Developer community. This can be summarised as: More tinker-proof boxes = fewer tinkerers. Hacking the Tivo is pointless because the computer won't boot if the software is modified. In this way, Tivo computers are tinker-proof. The GPLv3 prohibits distributing the software in a system that uses DRM to prevent tinkering.
Tivo are not the only ones making tinker-proof boxes, but Tivo are the only ones I can see that are likely to walk away if Linux moves to GPLv3. This is because Tivo are the only distributors of tinker-proof boxes whose business model rests on controlling their users.
The other distributors of tinker-proof boxes fall into two categories. One is a subset of router manufacturers. I don't believe they have a deep interest in preventing tinkering. If they are have to allow tinkering in return for getting continued software updates, I don't think they will walk away. That way, we gain more co-developers. The second category is makers of devices which are regulated by government or standards bodies, and for these there are still the options of putting it in ROM or putting it behind a locked door. (See: Preventing modification: put it in ROM?)
(C) Catastrophe prevention. If the current trend of general purpose computers were replaced en masse by tinker-proof computers, this could be a catastrophe for Free Software. I've no idea how likely this scenario is, but it is obviously possible. There are at least three ways that it can happen:
Where do we go from here?
Reasons (A) and (C) are why the final version of GPLv3 will retain some clause to preserve the freedom to modify software and run it on the computer that the original software was intended to run on.
Many Linux kernel developers have rejected reason (A), but I haven't seen substantial discussion about reasons (B) or (C). There's plenty more time for discussing these points.
If the Linux kernel developers decide that none of those three reasons are agreeable, there is another option. Draft 2 of GPLv3 provides infrastructure for adding exceptions (called "additional permissions" in section 7a) to the licence.
The Linux kernel developers might add an exception saying that distributors don't have to pass on to recipients any required keys or passwords.
All such exceptions can be removed by others, but simply removing the exception only makes an irrelevent copy. If I offer to distribute a copy of their software with the exception removed, Tivo will simply ignore my version and use the version from the Linux kernel developers.
The only possible conflict that could still remain is that I can take Linux, remove the exception and additionally make my adjustments, and distribute my modified version under pure GPLv3. So my intent is respected for my version, and the Linux developers' intent is respected for their version. The Linux developers may not like that I can do this, but the impact of my version will limited by the fact that my code won't be accepted into the main kernel tree.
In this GPLv3+DrmException scenario, Linux will miss out on the advantages I see with reasons (A) and (B) above, but it would still retain much of the value of reason (C). This is because while there is no catastrophe imminent, being able to remove the exception later means that if a catastrophe ever looks imminent, and it looks like GPLv3's protections against DRM might be useful, then the Linux kernel developers have the option of removing the exception and using vanilla GPLv3.
So for reasons (A) to (C), I think something like the vanilla GPLv3 would be best, but GPLv3+DrmException also has advantages over GPL version 2 - one of which is that it means having an escape route. Having an escape route is valuable not only because you might need it, but also because the existence of an escape route reduces the chance that you will ever need it - people don't invest in an attack that is easily escaped from.
(For ease of linking, each paragraph in this article has a html anchor.)
(c) FSFE 2006. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.