Controversy over GPLv3 draft reflects the 'incompatibility' of DRM with open source

Yesterday, after a long public comment period, the Free Software Foundation (FSF) released a second draft proposal for version 3 of the GNU General Public License (the GPL).  With many of the public comments focusing on the way the initial draft may have over-reached in its restrictions on the mixture of Digital Rights Management (DRM) technology with GPL-licensed software, the second draft looked to assuage those concerns with toned-down language.  CNET News.com's Stephen Shankland reported:

The Free Software Foundation has revised provisions concerning the thorny area of digital rights management in a new draft of the General Public License released Thursday....The approach in the second draft of GPL version 3 "only directly restricts DRM in the special case in which it is used to prevent people from sharing or modifying GPLv3-covered software," the foundation said in a statement. "GPLv3 does not prohibit the implementation of DRM features, but prevents them from being imposed on users in a way that they cannot remove."....The foundation didn't bend on the overall thrust of the new DRM provision: Manufacturers of a device that incorporates GPL software may not use that software unless they extend the software's full freedoms to users.

Shankland goes on to report on the specific language and what it means:

The license also says if some form of digital key is required for software to be installed or to run--even if that key is in hardware--it must be included in the software as well so that users can run modified versions the software....Source code that must be supplied with GPL software must include "any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use," the second draft said. "The fact that a key...is present in hardware that limits its use does not alter the requirement to include it in the corresponding source."

But, despite efforts to address the concerns raised during the public comment period, controversy has already erupted over the second draft as Linus Torvalds and others are already voicing opposition.  Torvalds is known to many as the father of Linux -- probably the most popular software to ever be licensed under the GPL and, as an operating system, Linux is the most likely of all GPL-licensed software to appear side-by-side with DRM technologies.  Wrote Shankland in a subsequent report:

The second draft of a revised General Public License has been released, but Linus Torvalds--founder and leader of the best-known software project governed by the GPL--remains unconvinced of its merits....Whereas the GPL version 2 was a basic "quid pro quo" arrangement that required anyone modifying source code to make the changes public, the draft of GPLv3 extends much further, Torvalds argued....GPLv3 "basically says, 'We don't want access just to your software modifications. We want access to your hardware, too,'" Torvalds said. "I don't think it's my place as a software developer to judge how hardware works around it.......Say I'm a hardware manufacturer. I decide I love some particular piece of open-source software, but when I sell my hardware, I want to make sure it runs only one particular version of that software, because that's what I've validated. So I make my hardware check the cryptographic signature of the binary before I run it," Torvalds said. "The GPLv3 doesn't seem to allow that, and in fact, most of the GPLv3 changes seem to be explicitly designed exactly to not allow the above kind of use, which I don't think it has any business doing."

Torvalds isn't alone in his criticisms. Accroding to Shankland's first report:

"I'm not sure the changes in the DRM provisions address a lot of the criticisms of draft 1 about the FSF using this document to try to extend control to the systems the software is run on," said Edward Naughton, an intellectual property attorney with Holland & Knight. "Notwithstanding the comments that accompany the draft, the language still seems to reach to hardware platforms. That strikes me as a real reach."

Now comes the question of whether or not the Free Software Foundation and those who disagree with it will just have to agree to disagree.  That's because, when you boil this issue down to its very essence, DRM is incompatible with true open source.  DRM is about locking something up. Open source, at least FSF style, is about making things free.  Any practical examination of how the two may work together under the hood reveals one major problem that only Sun appears to have come close to solving (and even then, it's not pure open source). The idea behind DRM is to protect the copyrights of content publishers by putting digital locks on that content -- locks that can only be removed by software that those publishers trust. That's because once the lock is removed, it's up to the software what happens next. For example, the software may enable a song to be played back. Or, it may enable a song to be burned to a CD 5 times.  But the software doesn't copy an unlocked version of the song to Bittorrent on the Internet. 

In the case of DRM schemes from companies like Apple and Microsoft, content publishers like the various record labels trust that Apple and Microsoft will, in the playback software and devices (eg: iTunes, iPods, Windows Media Player, etc.) they make, respect their wishes once the content is unlocked. Apple and Microsoft can assure this because no one but Apple or Microsoft has the source code to their playback technologies. But, if the playback (or "reader" in the case of text) software is open source-based, then open source developers are free to change what happens next (after the content is unlocked). Naturally, content publishers who favor DRM aren't comfortable with this idea because there are no guarantees that open source developers will respect their copyrights in whatever "happens next" once the locks are removed. 

This incompatibility between DRM and the freedom of open source developers to tinker with the inner workings of software is in many ways responsible for the current state of the industry where, with no truly open DRM technology to turn to as a widely supported industry standard, content publishers have little choice but to go with closed proprietary solutions that are themselves incompatible with each other (ie: DRM technologies from Apple and Microsoft).  The net result is producing an untenable situation where, once consumers make investments in content from one source (eg: Apple's iTunes Music Store), they will forever have no legal choice but to use Apple's playback technologies (today, that's the iTunes software, iPods, and a couple of phones from Motorola) or to throw away the hard dollar investment in the content they've purchased the rights to and start over.

In Project DReaM, Sun is attempting to deal with the problem with a framework where open source software is first certified to respect the wishes of copyright holders before it is given the keys to unlock DRM-protected content.  Once the source code is certified, the binary product of that source code (the actual software) is digitally signed and from that point forward, so as long as the digital signature remains in tact (proving the software hasn't been hacked), that software is allowed to remove the locks off of DRM-protected content.  Critics of the approach argue that the idea of certifying software to make sure it only does certain things is the equivalent of placing restrictions on what open source software developers can do which is the antithesis of open source software.  This is true.  But Sun response also holds water. With no other solutions on the table, what's better? The Projeect DReaM approach or the closed proprietary approaches that open source developers can t touch at all? The third answer is to get rid of DRM which I personally would love to see happen.  But, as long as the entertainment industry continues to insist on some form of protection for its content, DRM isn't going to go away any time soon. 

And thus, the impasse the industry is at, on that's characterized by the FSF's poster child for the position it's staking out.  That poster child is the TiVo recorder which operates on pretty much the same principle that Project DReaM does.  To the extent that TiVo recorders are appliances running an embedded version of Linux, the GPL's original author Richard Stallman has objected to the way TiVo uses Linux in its personal video recorders in a way that checks for a correctly digitally signed version of the code.  PVRs like TiVo already serve as "DRM clients" to the various cable TV providers and there have been isolated cases where cable operators have remotely operated the DRM levers resulting in the deletion or disabling of progams that were saved ("recorded") by customers.  By requiring a version of Linux that's digital signed by the manufacturer of a PVR, content publishers (eg: movie studios) and providers (eg: cable networks) are assured that software developers can't replace the operating system and thereby take control over "what happens next" once content that's delivered to the box has its DRM protection removed.

Fundamentally, as I have written before,  the word open (as in "open standards" or "open source") is, as far as I can tell, irreconcilably incompatible with DRM.   I trust that with all the brilliant technical and legal minds at Sun, if they best they can come up with is something in the middle where the code is open source, but the system isn't 100 percent open, then that's the also the best the FSF can hope for if it is going to assuage the DRM concerns in any way. Either that, or the FSF and those who want more liberal terms for DRM in the GPLv3 will have to agree to disagree.  For source code licensed under GPLv3, that impasse could affect adoption and community involvement.  Or, alternatively, licensors can do what Linus Torvalds is doing with Linux -- stick to GPLv2.

Lastly, although it has nothing to do with the DRM, HP apparently objects to the most recent draft of the GPL as well (not that the Free Software Foundation concerns itself with the interests of large commercial vendors).  Accordng to Shankland:

One major company still isn't satisfied. Hewlett-Packard, which sells Linux servers and is involved in the GPLv3 revision process, wants changes to how GPLv3 treats patents...."HP had hoped that the second draft would clarify the patent provision...to ease concern that mere distribution of a single copy of GPL-licensed software might have significant adverse intellectual property impact on a company," said Christine Martino, vice president of HP's Open Source and Linux Organization, in a statement. "Unfortunately, the concern lingers in draft 2."