Digital Rights Management
A talk by Jeff Ayers of RealNetworks posed the no-doubt rhetorical question of "Linux DRM: Possible or Oxymoron?" and enumerated some of the technical points required to make DRM workable in an Open Source environment.
He pointed out that movie companies take the long view: Gone With The Wind has commercial value 67 after it first lit the silver screen. At the same time, current DRM can only prevent casual piracy and fair use by the likes of you and me, because the factories that churn out bootleg DVDs have sufficient resources to crack any encryption in short order.
The central issue, as I see it, is that the rights for a work have come to be strictly those of the originator, not the purchaser or user. As a result, the whole notion of DRM boils down to preventing access to the protected bits, regardless of the purchaser's rights, while simultaneously allowing access to the bits for specific uses. This isn't going to work, as those factories show, but that hasn't stopped a whole bunch of smart folks from trying.
The overall DRM process seems straightforward enough: Encrypt a set of bits so that only an authorized program can decrypt them. The devil, as always, is in the details, as the Sony rootkit debacle demonstrated.
As Ayers explained, ensuring that a program (or music or book or whatever) remains protected requires running the decryption program on an authorized platform. That platform, both hardware and software, must have a known configuration, which requires some sort of central certification.
Unfortunately, that means typical Free/Open-Source Software simply cannot be allowed to run, because it could readily circumvent the DRM by meddling with the decryption routines. If, however, you regard Open Source as just a cooperative development methodology rather than a component of Free Software philosophy, then you can certainly develop a system that will prevent users from recompiling any code without DRM routines. Asserting that community developers (that is, those who aren't getting paid to produce DRM routines) would participate in such a project seems, at best, a dubious proposition.
This view of Open Source DRM is TiVo written large: You can recompile the source, but your modified version won't run on your hardware without the manufacturer's authorization, which you're certainly not going to get. You may be able to do other things with the hardware, but not run any code that decrypts DRM-protected bits.
The alert reader will notice the resemblance between this view of DRM and the whole Trusted Computing initiative I described in January: The hardware verifies the integrity of the software before booting, then each software stage verifies the next before yielding control to it. Only approved software may use the hardware, so all the bits remains solidly locked down.
Hold that thought, too.
