Rusty's Bleeding Edge Page

There has been much discussion about the interaction of DRM (aka Digital Restrictions Management) and the GPLv3. I have explored this issue in depth both with those involved in the process and lawyers familiar with the issues.

This post attempts to shed some light on my concerns, as an active Free Software developer who releases code under the GPL.

The Intent of the GPL

I am not a lawyer; I started using the GPL based on other's explanations and the preamble. This explains the intent of the license to allow others to use, distribute and modify the code, and the restrictions it places on people to enforce this intent.

One restriction my use of GPLv2 places on distributors is "you may not impose further restrictions": distributors can't add their own restrictions on my code to subvert the intent of the license. This is important to me: I handed them a whole slew of rights, and if they hand this code on to you, they must also hand on those rights.

Now, I don't care how someone tries to add restrictions against my express intent: licensing, patents, hardware, software, TPM law or voodoo. Do not do it. When all else fails I expect the license to give me the legal ability to enforce my intent.

Those legal mechanisms in the license are beyond my expertise, but I do believe the lawyers when they tell me the GPL needs updating. Fifteen years of experience and fifteen years of legal changes can have perverse effects even on the best-drafted license.

The Case for Technological Prevention Measures

Several people have made the case for preventing modification of GPL software. But such arguments can similarly be used for any other licensing terms, and have found little sympathy. There might be genuine security or legal problems with releasing modified source code, for example. In which case, they simply cannot distribute. There are often cases where a party seeks a relaxation of licensing terms in order to combine with non-GPL code outside their control. I've been approached to relicense several projects, and sometimes saying no has meant that some cool software didn't exist, or became harder to create.

On prevention of modification, let me be clear: I do not wish someone to gain a monopoly on supply and support of my code. This is not a subtle issue caused by license wording, but a real tension between my intent and theirs: I intend to allow downstream modification, they want to prevent it.

Nor is this a GPLv3 issue, but the GPLv3 (draft 2) clarifies the legalese by explicitly requiring "encryption or authorization keys" as part of the Source Code in these cases, bringing this issue to the fore. And it seems to me that addressing DRM is a requirement if we are to fully implement the promise of the preamble in modern times.

Now, there is sometimes legitimate reason to loosen any term of a license, and the requirement to provide keys to execute modified versions is no exception. The question then becomes one of the size of the problem, and the cost of solving it[1]. Remember that the GPL does not have to meet every need, so deciding not to solve the problem is not a catastrophe.

Firstly, I note that by far the most uses of authentication involve (non-GPL) data, rather than programs: these are not problematic.

Secondly, projects such as signed Linux kernel modules are not problematic either. Equivalent but different signature can be generated by rebuilding the source code[2].

The classic example of program verification is that of GPL-derived voting machine software which uses a TPM to recognise modified software and prevent them from contributing votes. As the GPL sharing obligations only kick in with distribution[3], intra-company and government-controlled elections have no GPL issues. The only problem comes in distributing "unmodifiable" software, such as in home voting.[4] There are genuine reasons to want to modify this software (such as to run on Linux, or on PowerPC, or in Australia), and there is a genuine reason to want to prevent modifications (vote integrity). Note that while modification prevention is poor security[5], it is better than nothing[6].

A second example is a set-top box, which contains GPL-derived software and no longer displays the movies (for which you have paid), should it be modified in any way. Again, you cannot fix bugs, make it work in Australia, lower its power consumption or add a pause button, if you want the software to be useful, as was my intent as original author. I do not want my software to be distributed in such a restricted way, and I expect I can prevent it under GPLv2. You should not use my software if you need to do this.

Presumably, we would like to allow the former, without the latter. It is arguable whether this corner case justifies weakening the license, but let's explore it.

The Further Restrictions

There are at least two cases where further modification restrictions are already tacitly allowed by the GPLv2, as illuminated by the FSF.

The first is GPL executables on "Live CDs", the second is in ROM. In the Live CD case, the lack of modification is so mild a restriction it can probably be ignored. In the ROM case, the FSF has said that this is fine. I can only assume they feel that there has been no deliberate attempt to remove rights, merely a reasonable physical limitation.

We could extend this logic to cover other "reasonable limitations". Yet we do not want to create an exception which allows an end-run around the license requirements. An exception which allowed the license terms to be ignored if "required for functionality" would become a perverse incentive to design systems with such a requirement in order to subvert the license.

So If We Had an Exception, What Could It Look Like?

Given these constraints, any such exception would need to be minimal in scope and introduce some burden to avoid it becoming an attractive license loophole. So, if such cases are considered important, I suggest the following four step test to relax the "all the same functionality in the same range of circumstances" requirement for modified works:

1. The restrictions are the minimal required for correct functioning of the system,
2. There is no reasonable alternative implementation which could have been used to achieve similar results,
3. The correct functioning ensured by the restrictions are in the interest of the users as a whole, and
4. There must be a method by which modifications can reasonably be demonstrated not to subvert the correct functioning of the system, and modifications so demonstrated must be allowed.

The first two clauses ensures the restrictions are only open as a reasonable last resort. The third is a safeguard against systems designed solely to subvert the license. It is a weakened version of the intent that the copy recipient be given various freedoms.[7] The fourth term also places the burden on the distributer using this exception: the onus is on them to allow fixes.

I'm not convinced that opening this door is worthwhile, given the complications it would add to the license and limited nature of the problem. But if it is to be opened, I would recommend such safeguards.

Sincerely,
Rusty Russell (rusty@rustcorp.com.au),
Free/Open Source Software Hacker.

[1] There is a large case of compromise in the GPLv2: the "system component" exception which allows distribution of GPLv2 binaries which rely on GPL-incompatible libraries, as long as they are "normally distributed with the major components of the operating system". This is a case where the cost of the loophole was judged smaller than the size of the problem if GPL software could not use non-GPL system libraries (almost all of them in 1991).

[2] I went through this a few years back with a lawyer when reviewing a (RedHat) patch to the Linux module code, and seems to be addressed explicitly in GPLv3's "use of the work normally implies the user already has the key". The key is randomly generated at build time by the build scripts in this case.

[3] Or "conveying" in GPLv3-speak.

[4] A terrible idea for government elections, but they could improve representation where alternatives are even less reliable, such as widely-distributed organizations.

[5] All software has bugs, and authentication technologies do not prevent them from being exploited.

[6] Unlike proprietary code which can do obfuscated self-checks, GPL code cannot even do this due to source availability, so verification may be an answer.

[7] In this case, the individual user might want to subvert the election, so we cannot predicate the exception on their interest.

[/IP] permanent link