No code has been posted to the project website on Java.net yet, but it will be made available on a "royalty-free" basis under Sun's Common Development and Distribution License (CDDL) -- which is somewhat similar to an open-source license like the GNU General Public License but affords Sun some control. Project DReaM includes a DRM architecture called DRM-OPERA as well as some technology components for digital video management and distribution.

Back in 1998, Sun CEO Scott McNealy heard a DRM startup pitch his company on a strategic partnership. After listening to the startup's CEO for a while, McNealy expressed the opinion that DRM would become "freeware." Now, seven years later, his remark has proven prescient: at least in the media and entertainment industry, there is precious little money to be made from DRM technology alone -- but with one significant exception that we will discuss shortly and that could jeopardize Project DReaM's success.

DRM-OPERA

DRM-OPERA's roots lie in Project OPERA, which came out of the Eurescom R&D initiative sponsored by the European Union and the European telecommunications industry. Sun's R&D lab contributed heavily to Project OPERA, which produced an architecture for interoperable DRM in 2003.

OPERA achieves interoperability among DRM systems -- interoperability between Microsoft and RealNetworks DRMs has already been demonstrated -- essentially by reducing DRM licenses down to a lowest common denominator of authenticating users only (as described above) and providing "play once" as an atomic licensing term that all DRM systems can understand and support. Each of the DRM systems involved in a specific instance of interoperability can manage more complex licensing terms internally and communicate them through the OPERA architecture via "play once" licenses.

This is somewhat similar to standards for home networking such as SmartRight and Secure Video Processor (SVP), which also rely on lowest-common-denominator licensing terms for interoperability between devices in a home network; but these standards also encompass device and domain as well as user authentication, the latter usually via the SmartCards that are common to the cable/set-top box industry from whence these standards came. The OPERA approach is thus the antithesis of the one advocated by MPEG, which calls for the use of a complex rights expression language (REL) to express rights and for a rights data dictionary (RDD) to map semantics of rights descriptions to one another.

There are strategic as well as technological advantages to OPERA's approach, as we'll see, but the disadvantage is that it does not work well with rights that differ from "play," such as rights to copy, move, and even render content in other ways ("print"). If a single DRM system is to control more complex rights expressions (e.g., "play 10 times" or "play for a week"), then it will not be able to support rights to export content to other systems under terms other than the simple "play once."

So, Sun is resurrecting the work it did on OPERA in the form of an open-source community Java development project. It intends to move source code from Sun Labs to a community development site called www.openmediacommons.org in the near future.

Sun claims that it has about 25 other companies interested in contributing and that interest in the effort has increased in the aftermath of Schwartz' speech in Aspen. Sun is not revealing the identities of the other companies, but we suspect that they include two types: One is European telcos and wireless carriers that were originally involved in OPERA and have been frustrated by impeded progress on the OMA DRM standards due to patent licensing -- more on that shortly -- and other issues. The other is the usual assortment of smaller software companies that tend to gather around a standards initiative that is being positioned as an alternative to proprietary "gorilla" players in a given market.

However, we suspect that this project will have trouble drawing much serious interest -- other than as observers -- from the media industry. (And its chances of getting active participation from the media industry are not improved by remarks in Schwartz's Aspen speech, reproduced as an entry in his blog, that accuse media companies of adopting a double standard regarding DRM.)

Sun's Strategy

Sun is positioning Project DReaM against the proprietary technologies that dominate DRM today -- mainly Microsoft and Apple -- which is how it typically approaches standards efforts of this sort. But it is also positioning the project against the consortia that are driving other development in the DRM arena, such as Coral (which Sun joined this past May), Marlin, and SVP, not to mention HD-DVD and Blu-ray. Marlin, in particular, has a lot in common architecturally with OPERA (including interoperability and user authentication) and is being developed under community source licensing, but Sun is positioning it -- with some justification, admittedly -- as a cabal among the group of consumer electronics firms that make up its membership.

Unfortunately, nowadays the major media companies tend to back DRM technologies in whose development they directly participate, which essentially means consortia. Sun is not really in the inner circle of media and consumer electronics activity these days -- not compared to consumer electronics giants like Sony and Philips, or even such "pure" IT companies as IBM and Intel, to say nothing of Microsoft and Apple. Sun is a major tech company but one that does not have proprietary control over any significant media data format, device, or other component of the digital media supply chain. Therefore, three potential DRM strategies suggest themselves to Sun:

1. Assiduously court both the media and consumer electronics industry and thereby attempt to influence the direction of the mainstream.
2. Offer some technology on the basis of patent licensing. More on that shortly.
3. Bet on digital media activity outside the mainstream -- what has been called "consumer created content," or as Sun puts it in the context of the Project DReaM announcement, the Participation Age.

Sun is evidently opting for the third of these choices, which admittedly is the "low hanging fruit" in this case and thus the most appealing strategy. Option 1 would involve lots of hard work and investment over a long period of time. As for patent licensing, see below.

Even so, Project DReaM covers ground already trodden in DRM. First, DRM standards initiatives have already staked out positions in non-mainstream media too. The Digital Media Project (DMP), which has been in existence for two years now, has a mission statement that is effectively a superset of that of Project DReaM. The DMP, under the direction of MPEG founder Leonardo Chiariglione, focuses its activities on balancing rights of content owners with those of consumers, not on being acceptable to mainstream media -- which, tellingly, is poorly represented in the DMP's membership. The DMP released a first spec (IDP-1) this past May, one that applies to portable devices (like Marlin) but whose approach to authentication is the opposite of both Marlin's and DRM-OPERA's: it authenticates devices and network domains, not users.

Even mainstream standards initiatives are embracing consumer created content: the sprawling Digital Living Network Alliance (DLNA) expects to release DRM-related specs in the next few months that apply to consumer created content instead of "premium" content from the mainstream media industry.

Sun has a few important points of value that it could add to DMP. One is the user authentication of DRM-OPERA, which complements the existing DMP IDP-1 spec; user authentication will undoubtedly be necessary to include in the DMP's specs at some point. The DMP may have omitted user authentication from its first spec because of the complexity of user identity management vis-à-vis the compactness of the portable devices on which IDP-1 focuses. Sun is the prime mover in the Liberty Alliance, whose ambitious approach to federated online identity management is gaining traction in the market and would be highly complementary to any interoperable DRM standard. Finally, by connecting the active membership of the DMP to Sun's vibrant Java.net developer community, Sun would be giving the DMP a significant boost in its efforts to produce real-world implementations.

Secondly, there have been at least two previous attempts to create open-source DRM software (however anathema the very idea of DRM may be to some in the open-source community). ObjectLab, a New York City-based software development firm, announced an open-source DRM initiative called OpenIPMP in 2002, based on MPEG and ISMA standards, and released an implementation 2003. The code went nowhere, and the company has been inactive since then. The other attempt was Media-S from Southern California-based Sidespace Solutions, a simple technology based on SSL that supports the Ogg Vorbis open-source codec, which has not progressed since a second beta release in 2003.

Royalty-Free?

In addition to positioning Project DReaM against proprietary DRM technologies and consortia, Sun is representing the project as an attempt to solve the patent licensing problem that has been plaguing DRM, especially ever since Microsoft's $440 Million patent litigation settlement with InterTrust last year. Sun promises that Project DReaM will result in "royalty free" DRM, a claim that strikes us as audacious, naive, or both.

There is essentially no such thing as a royalty-free DRM open standard nowadays. There is one major DRM technology available that is largely royalty-free: Microsoft's Windows Media DRM. But it's certainly not an open standard. In the consumer media market, any revenue from DRM technology per se nowadays comes not from software sales but from patent licensing.

Most DRM standards initiatives and consortia nowadays -- including those mentioned above -- have licensing authorities attached to them, which come equipped with patent pools and RAND royalty policies. Standards initiatives that avoid this issue and claim to be "royalty-free" find that their would-be implementers receive visits from patent holders demanding royalties, and even those who have licensed patents from the "usual suspects," such as InterTrust, ContentGuard, Macrovision, and others, are finding that they have not eliminated patent risk. (Even ObjectLab ran into some trouble with DRM patents regarding its open-source OpenIPMP.)

Sun intends to avoid the patent issue by using some of its own IP in DReaM and to work with DReaM community developers to invent around the existing patents. Our message to these hardy souls is twofold: one, hire a good patent attorney; two, good luck. For every patent pool (such as MPEG LA's pool for the OMA DRM standard), there is at least one core patent holder that has chosen to stay out and reserve its options to license its IP separately, as well as at least one more patent holder that is hitherto unknown and comes out of the woodwork.

(Which brings us back around to the startup company that pitched Sun on a partnership in 1998. Like many DRM startups of that era, the company went out of business. But it sold its key asset -- its core patent, one of the earlier essential patents of DRM -- to a much larger company that is now using it to make money as part of a proactive patent licensing strategy and is staying out of many of the relevant patent pools.)

Given the current spat over DRM patent royalties around the OMA standards in the European wireless industry -- which helped spawn the work that led to Project DReaM -- it is not surprising that Sun would seek to differentiate Project DReaM from other standards efforts by promising freedom from patent risk. But we remain skeptical that Sun will succeed. This problem will likely exacerbate itself if Project DReaM finds itself competing in the marketplace with Marlin, whose members -- including InterTrust and its owners, Sony and Philips -- hold many of the patent cards.

Yet Project DReaM admittedly has at least one thing in its favor regarding patents: OPERA's use of "play once" lowest-common-denominator licensing in its architecture may clear it of conflicts with the part of ContentGuard's IP that covers the use of rights expression languages in DRM implementations.

Sun's goals with Project DReaM are laudable: it wants to help accelerate growth of the networked digital media market by promoting DRM interoperability and reducing IP risk -- two elements that have indeed been hindering growth. We have no doubt that Sun's field of DReaMs will be non-mainstream consumer media. But in order to have any impact, Sun may be better off in aligning Project DReaM with existing efforts, such as DMP or even the established consortia -- and learning from the examples of similar efforts in the past -- than in trying to go off in other directions.

Get DRM Watch Newsletter

Click here to subscribe to DRM Watch