GPLv3 Myth #3: GPL forbids DRM

In our continuing series on the world's most popular (and least understood) free/open source license, today we look at a controversial subject: Digital Rights Management (DRM). There are two sides to DRM that often get mushed together in discussions: restrictions on content and restrictions on code. We take a look at each one separately and discuss where GPLv3 stands on each issue.

In our continuing series on the latest version of the world's most popular (and least understood) free/open source license, today we look at a controversial subject: Digital Rights Management (DRM). My colleague David Berlind has another name for DRM: Content, Restriction, Annulment, and Protection (CRAP).

Disclaimer: This information was culled from a variety of sources, including the GPLv3 web site, interviews with experts involved in the process, and analysis from various industry watchers. However this isn’t intended as legal advice.

Myth 3: GPL forbids DRM.

False. GPLv2 was created in 1991, before the time of RIAA lawsuits and electronic voting booth debacles. Early drafts of GPLv3 took an activist, anti-DRM stance, prompting an outcry from the open source community. It wasn't because people like DRM technologies such as copy protection, anti-tampering cryptography, and time bombs -- quite the opposite is true -- the issue was whether or not anti-DRM agendas had any place in a software license.

There are two sides to DRM that often get mushed together in discussions, which tends to confuse things. They are:

  • Restrictions on content (audio, video, PDF documents, etc.)
  • Restrictions on code (C++, Java, C##, whatever)

Let's take a look at each one separately. People who follow this full time will probably cringe at my over-simplifications, but I'm just trying to get across the general idea.

Restrictions on content When most people think of "DRM" they're thinking of restrictions on content. For example, when you buy a song at a music site and then find out you're not allowed to copy it to your other computer. Typically this is accomplished from some form of cryptography - content is stored in an encrypted format which can only be decoded if the licensing terms are met. Crackers (sometimes called hackers but I don't like to use the word that way) take great delight in breaking these protection schemes to allow content to be use freely (including, maybe, uploading it to the network so anyone can use it without paying anything).

One of the ways that media companies discourage cracking is the infamous DCMA (Digital Millennium Copyright Act) and related WIPO treaties. It criminalizes production and dissemination of technology used to circumvent these restrictions.

GPLv3 does not tackle DRM directly but it does tackle DCMA. In section 3 it says:

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

In non-legal-speak, when you distribute GPL code you're giving permission to do the things that DCMA forbids. So DRM isn't disallowed per se, but you make it easier for people to work around your DRM. Dedicated crackers are going to work around it anyway, but now they can be more open about it.

Restrictions on code The whole purpose of GPL (any version) is to ensure access to the source code that is covered by the GPL. And the purpose of that is ostensibly to allow a knowledgeable user to modify that code. The only reason you'd want to modify code is so you can run it, so GPLv2 had an implication that users should be able to run modified code. Well, that seems obvious but what about an embedded device like a voting machine, a phone, or (you knew I would mention it) a TiVo?

Early drafts of GPLv3 said that people distributing programs with GPL code in them absolutely had to allow anybody to modify and replace and run that code. Many people including device manufacturers worried this might open the door to service disruptions and other shenanigans, especially on networked devices. Linux creator Linus Torvalds summarized the problem nicely when he wrote:

I literally feel that we do not--as software developers--have the moral right to enforce our rules on hardware manufacturers. We are not crusaders, trying to force people to bow to our superior God. We are trying to show others that co-operation and openness works better.

In light of such comments, the final release of GPLv3 removed all mention of "digital rights" and "technical restrictions". However it does say that for "user products", like TiVos and alarm clocks, users have to be provided with information that would allow them to install modified software into the products.

There are two big exceptions. First, there's the non-user products, like voting machines and airplanes. They are exempt from this rule. Second, there are devices that because of hardware design (such as unflashable-ROM) don't allow anyone to modify the software, even the manufacturer. These devices are also exempt.

Conclusion GPLv3 does not forbid DRM protections on content or code outright. However the usefulness of any protections on content is limited a bit because you're giving permission for anyone to circumvent them. Restrictions on code are weakened by GPLv3, especially in user/consumer products, by the requirement to provide installation information (i.e., if you can install a new version, you need to let others install a new version).

The result is a compromise between the desires of content and code creators, and the freedoms of the ultimate consumers of all this technology. When you're deciding what license to use for your own code, only you can determine whether GPLv3 goes too far in one direction or another.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All