‘Sun pushes open-source DRM scheme’
The usual disclaimer. DRM isn’t the favorite technology of Jon Noring, me and the others at OpenReader. But we’re open to compromise with publishers. If there must be DRM–the marketplace will sort out this question ultimately–let’s do it right and keep down costs to consumers and content providers. For that reason, I’m delighted to learn of Sun’s interest in DRM standards. From the Register:
Sun Microsystems stepped into the fractious arena of digital copyright protection this week with plans for an open-source, royalty-free digital rights management (DRM) standard. The Open Media Commons initiative aims to address concerns that a growing number of incompatible download schemes might frustrate consumers and hold back growth in the download market.
To get the ball rolling, Sun is releasing its code from its Project DReaM (DRM/everywhere available) program under the open-source Common Development and Distribution License (CDDL). It’s inviting other firms to join the initiative which involves the development of a device independent DRM standard - called DRM Opera - and user-based (as opposed to device-based) licensing.
Analysts said Sun would need to get content owners, software developers and device makers on board for the project to succeed. “It’s important they’re making this effort but what will be the proof points are when the rights holders (to the digital content) and device makers get on board,” Gartner analyst Mike McGuire told Reuters.
Related: Reuters story and Slashdot item and a list of people at Sun working on the DRM project.
August 22nd, 2005 at 10:40 am
For this to be distributed under CDDL, Sun doesnt seem to have a whole lot of information on its pages.
Open Source DRM means either
(a) a set of “rights management” primitives (like XrML tried to be), with the actually “Technical Protection Mechanisms” left to the individual implementor and definitely NOT open source.
(b) the code is nominally “open source”, but the compiled versions are digital signed. Only trusted implementors actually get to write software (in exchange for the appropriate fee), and on properly branded hardware.
Neither way allows the benefits of open source in fixing bugs, improving usability (especially for the visually impaired), to port to new hardware, and so forth.
If OpenReader wants to support the modifications that I mention in the last paragraph, DRM would not be an option because modifications to support a Braile output device or audio reader would allow the content to be rewritten to an unprotected file.
I am willing to be surprised if Sun’s approach is somehow different…
August 22nd, 2005 at 12:03 pm
Reminder of the disclaimer: I’m not the biggest DRM fan.
Yes, there will be leaks. But if nothing else, let’s work to make the technology more convenient for consumers. What’s more, there may yet be technological fixes to the problems you’ve suggested, such as through cooperation with makers of devices used by disabled people. Standardization could help. Anyway thanks for your valuable feedback! Keep it coming. These questions need to be raised. - David
August 22nd, 2005 at 5:24 pm
Thank you for putting up with my contrarian views.
I would like to read something more on the vision for DRM support in Openreader. This with the understanding that you are not the biggest fan of DRM.
I personally believe that DRM (or TPM) by its very nature will always be customer hostile regardless of the technology behind it.. The details are too long to go into — I keep thinking that I should write something up in an article form at some point.
The fundamental contradictions are, however, first that there is no programmatic method to evaluate fair use (to be fair, some uses require a court decision),
and secondly, there is not (and I believe CANNOT BE due to the fundamental computer science theorums, eg - halting problem) any method for determining if any arbitrary code respects the DRM policy. This means that only code known about by the system’s owner can be considered trusted, and revocation capabilities are needed… this eliminates modifiable code and open platforms.
Even topics like proof carrying code can’t help here. There is no programmaticly detectable difference between a new display driver that is implementing Cleartype (tm/whatever) versus a display driver that is encoding the data into an on-screen barcode for maximal machine readibility and error correction.
From what little i can find so far of DReaM - Sun is not attempting to address this, they appear to be focusing on the specification of “rights”. I predict that the code to actually ensure these rights will not be included.