While I was on vacation last week, I noticed that Cory Doctorow issued a scathing review of Sun's Project DReaM in response to my podcast interview of Sun Labs director of engineering Tom Jacobs who heads up development of DReaM. Under the auspices of an organization called the Open Media Commons, Sun is pitching DReaM as an open standards and open source DRM (digital rights management) technology (I prefer the acronym C.R.A.P.) that will do to the proprietary versions of DRM that are out there (like those from Apple and Microsoft) what the Sun-founded Liberty Alliance did to Microsoft's proprietary Passport identity system. Most of the content we want will be saddled with DRM, and the producers of that content cannot be convinced otherwise. Based on Sun's assessment that better than 90 percent of the world's credentialed transactions rely on Liberty-based credentials, Sun says Liberty is why Passport never got much traction.
In his writeup (headlined How Sun's "open DRM" dooms them and all they touch), Cory calls the open source nature of DReaM into question when he quite correctly picks on two key aspects of the technology. The first is that any code that claims to support it must run as signed code before it will be allowed to unlock locked content. Not only must a Certificate Authority play a role in code signing (adding complication), the code must be tested by some independent outfit to make sure that it upholds the sort of DRM principles that movie studios, record labels, and other publishers require. Significant expense could be involved; expense that could lock out certain open source developers thereby stifling the innovation that open source is known for. The second aspect that Cory zeroes in on is DReaM's reliance on "trusted hardware."
Even though DReaM isn't yet in the market, it's important to know that the existing proprietary solutions that are out there involve very much the same architecture. Although the code isn't signed in Certificate Authority fashion, the DRM principles that code-signing guarantees are upheld by the closed nature of the systems. For example, Apple and Microsoft must guarantee movie studios and record labels that the DRM systems they put into the market will adequately serve publishers' intentions when it comes to their content (eg: what restrictions -- what the "R" in DRM should really stand for -- such as expirations and limits on copying can be technologically enforced). Since the only code that's available is pre-compiled executable code (like Apple's iTunes Software or Microsoft's Windows Media Player) and it comes from pre-ordained sources (sources that have passed muster with content publishers), it's the equivalent of code-signing. Companies like Microsoft and Apple can probably even tell if their compiled code has been tampered with (eg: a virus) and trigger content license revocation.
Although they're not hardware enforced trust (a la a Trusted Platform Modules or TPMs), software products like iTunes and Windows Media Player also do their best to emulate a trusted hardware environment where there's a connection between the content license and the identity of the licensee. Anyone who has used iTunes knows how, before music can be purchased from the iTunes Music Store and played back, an iTunes account (usually credit-card based, but sometimes not) must be established and associated with each instance of the iTunes software and/or an iPod (in both cases, marrying identity to machine). Hardware-based trust -- the sort that DReaM works with -- is more bulletproof than that sort of software-based trust (TPM-like hardware is found in only a handful of systems like Lenovo's Thinkpads). But some argue that even though software trust is easily broken (in the context of DRM, this is known as "circumvention": an act that's strictly prohibited by the Digital Millennium Copyright Act), hardware-based trust has problems of its own. For example, how to make the hardware encoded keys portable for legitimate reasons (using more than one system or simply upgrading to another system).
To the extent that a link is created between content and identity, third lesser known and discussed issue with respect to how the existing systems work are the proprietary identity systems on which they're built. Today, the closed nature of those systems has yet to rear it's ugly head. But tomorrow, particularly with user-centric identity systems like YADIS (for contextually sharing personal profile information) and the Higgins Trust Framework (for cross-domain authentication), users may end up bemoaning proprietary identity management systems if they don't federate with more broadly accepted and open systems (sidebar: there will be connectivity between Higgins and Microsoft's InfoCard. But what role, if any, that could play in Microsoft's PlaysForSure DRM ecosystem, I couldn't say).
To the extent that DReaM also relies on identity, one can't downplay the potential Liberty Alliance connection. In refraining from using the word "open," might a benevolently dictated DRM layered on top of a benevolently dictated identity framework do?
As opposed to not settling for DRM at all, the question for many is whether to settle for a somewhat vendor-independent (and to some extent, studio-independent) DRM. For the trainwrecks it has already caused and for ones it will cause, many of us abhor DRM in the first place and have tirelessly campaigned against it. My biggest beef with DRM has always been the proprietary versions of it gaining traction in the marketplace and the amount of unprecedented power that the top one or two DRM systems in the marketplace will afford to their purveyors. Power over content publishers. Power over end users. One need not look far for the evidence.
Already, record studios are in a power struggle with Apple.
Purchases of downloadable music now account for 6 percent of the record industry's total sales and of that 6 percent Apple is the dominant player. Additionally, that 6 percent number doesn't tell the whole story about the strength and growth of the online channel. Where as the 6 percent of record industry revenues is dominated by the sale of 99 cent songs, a lot if not most or all of the remaining 94 percent is based on the sale of complete albums which tend to cost $12 or more on Compact Disc. In other words, whereas the sales of downloadable music may only account for 6 percent of overall revenue, it accounts for a significantly larger percentage of overall items sold. Apple's iTunes music store recently eclipsed the 1 billion song mark. iTunes has gotten so big that record labels have no choice. No choice but to use it. No choice but toplay by Apple's rules. For example, in the recent feud between Apple and the major record labels over download pricing, the record labels didn't have much choice but to go along with Apple.
Likewise, Apple keeps its DRM close to the vest having only licensed it to Motorola for a handful of phones. The double-whammy is that as music buyers amass their collections of music, they may eventually become disappointed to learn that, because of Apple's failure to make its DRM more broadly available to other device manufacturers, their music collections won't work on anything but iPods and a few of Motorola's phones. So, you're an iPod owner that likes that hot new device from iRiver or Creative? Or that music capable phone from Nokia, HP, or Samsung? You have two costly choices. Throw out your iTunes purchased music collection and start over using yet another proprietary DRM scheme (which could land you in the same position a few years down the line) or find a way to break the DRM off your existing collection (comes with DMCA-provisioned fines and jailtime if you're caught). Content publishers are crazy about the situation either. They, according to Sun's Jacobs, see content portability as being important to the sucess of their business in the digital age.
Unfortunately, to get that portability (the sort that could be gotten through using more commonly practiced standards such as FLAC, MP3, and MP4), content publishers (record labels, movie studios, etc.) are not willing to give up on the protection (DRM) and laws (DMCA) that to them are the only viable instruments for keeping their businesses from going to hell in a handbasket. Without both, publishers argue, Internet-based piracy of their copyrighted material would ruin them. We can hate DRM all we want. But the cold stark reality is most of the content we want -- whether it's music, movies, Cable TV, still images, and even text documents -- will be saddled with DRM and the producers of that content cannot be convinced otherwise.
So, from the technology side of things, we can bitch and moan about DRM all we want. But as long as publishers remain unconvinced (and as long as no real viable alternative to their content exists -- which, in the big picture has proven to be the case, especially with video and movies), the lockdown will continue. This brings us full circle to the question of DReaM's openness and neutrality. So right is Cory Doctorow about DReaM not being open source that he drew an indirect but corroborating response from Sun president and COO Jonathan Schwartz. Schwartz was directly responding to a post (see Is DReaM a Nightmare?) by Sun chief open source officer Simon Phipps' who wrote:
In my view, [Project DReaM] has unfortunately conflated two different debates. By invoking F/OSS it automatically brings with it the worldview that implies. In the dialectic of that world, software is considered to either promote liberty or to promote monopoly, with F/OSS always promoting liberty. By associating DRM (which can never promote liberty) and F/OSS (which always does), anyone is guaranteed to come across as initially clueless, it is a semantic inevitability. This is the justified attack that Cory makes and he has my respect and broad agreement in making the point.....Project DReAM is not an open source play. I can't help believe that DRM will be a fact of life for at least the next five years. My view is that it's a disaster for modern culture, not least because it destroys "fair use" rights by quantising discretion. But, like death and taxes, it seems inescapable. So given we have to head into this void, the DReaM approach is to try to create a system that is the least worst option.
....my views hew close to Mr. Doctorow's, as well. But there's no hiding from the reality that important deployments are occurring, today, that mandate DRM - absent an alternative, what's deployed [today] will be far more insidious than what DReaM presents. Certainly less developer accessible. So can DRM promote freedom? No. But Sun can promote freedom of choice, while we work toward a world in which DRM, as defined today, is no longer relevant.
When I first started railing against proprietary DRM, I took a more conciliatory approach. I said if we have to have it, at least give us an open standard that isn't so restricting to our fair use (fair use in my eyes, not someone else's). Buying a song at the iTunes Music Store and loading it onto an Escient Fireball Music Server in my basement so it can serve music to my bedroom or my kitchen was the sort of simple, non-pirate like usage I had in mind.
But, after the Electronic Frontier Foundation's Brad Templeton showed me how the terms DRM and open are oxymorons, I slipped right down the slope I was on, forsaking all forms of DRM. I still do. It's rotten, complicated, and problematic. On the one hand, Cory is right. DReaM subverts open source. So too is Brad. There is no such thing as open source DRM. Given that Catch-22, if DRM on content is as sure a bet as death and taxes are but we can't have open source DRM, perhaps we are down to the least worst option after all.