|
Electronic Self Help and DRM
|
|
By Ed Foster, Section Columns Posted on Thu Apr 08, 2004 at 08:40:24 AM PDT
|
 |
|
It's come to my attention that I've been derelict in my duty. As the guy who sounded the alarm for lo those many years about UCITA and electronic self help, I should have made something clear. Just because UCITA is now basically a dead issue doesn't mean that electronic self help is no longer a threat. It is still very much with us - it just goes by another name.
|
|
Electronic self help -- the ability of a software company to remotely "repossess" its software when it decides you're no longer entitled to the program -- was the single issue that most galvanized opposition to UCITA, particularly the opposition of corporate IT customers. When they contemplated the scenarios in which the self help provisions would allow software publishers to hold a gun to their head, IT folks got very nervous. And the more they understood the enormity of the security risks posed by the backdoor mechanisms needed to remotely disable software, the more determined they grew to fight UCITA's enactment.
In other words, if it hadn't been for electronic self help, UCITA would probably be the law throughout the land now. And yet, as my readers well know, it is more and more likely that any program you buy will have some backdoor mechanism that can remotely disable your software. It's not called electronic self help, it's called Digital Rights Management (DRM) technology. And it's not given legal status by UCITA (except in Virginia and Maryland, where UCITA remains on the books), but by the Digital Millennium Copyright Act (DMCA).
Of course, companies like Microsoft, Adobe, and Symantec would say the DRM they use for product activation isn't intended to remotely disable their programs. But can we trust them to tell us what their true intentions are? Most product activation is based on technology from DRM vendors similar to the Macrovision C-Dilla software used by Intuit last year for TurboTax 2002 product activation. Such technology offers a host of phone-home and spyware capabilities to choose from should the software publisher wish to implement them.
And that's just the DRM we know about. Software publishers are under no obligation to tell us they're employing DRM in their products. If fact, the DMCA implies they have the right to be as secretive as they want. That's because the DMCA endorses DRM in a rather backhanded kind of way - by saying that no person shall "circumvent a technological measure" used by copyright holders to protect their works. So while requiring users to keep their hands off DRM, the DMCA puts no requirements on what kind of technological measures the copyright holders can choose to implement.
In context of the electronic self help scenario, there is one other important aspect of the DMCA I should mention: the DMCA "takedown" provisions. Under the DMCA, copyright holders get to demand that anything they claim infringes their rights be removed immediately. The music and movie industries have pushed this to the point where the right of copyright holders to wreak havoc in the pursuit of any infringement claim, no matter how spurious, now appears to be sacrosanct. So if a software publisher in a dispute decides to bring your company to its knees by alerting their DRM to turn off your software, they are only following their clear mandate under federal law.
It's one thing to connect the dots between electronic self help and DRM, but is there anything that can be done about it? Well, I can offer one do-it-yourself tip for how IT managers can try to smoke out DRM-infested software. One reader recently passed on this language from a software contract he'd seen:
"The vendor shall not include any Vendor Induced Inhibiting Code (or VIIC) or any other inhibitor data or software licensed under this agreement. VIIC is defined as any deliberately-included application or system code that will degrade performance, result in inaccurate data, deny accessibility, or adversely effect, in any way, programs or data or use of the system. The vendor represents, warrants and covenants that the licensed software and all software upgrades shall not contain any computer code that would disable the licensed software or impair in any way its operation based on the elapsing of a period of time, exceeding an authorized number of copies, advancement to a particular date or numbers or other similar self-destruct mechanisms (sometimes referred to as "time bombs," "time locks," or "drop dead" devices) or that would permit the vendor to access the licensed software to cause such disablement or impairment (sometimes referred to as a "trap door" device)."
It's certainly worth asking for such a VIIC provision in your software contracts, if only to hear the explanation for why they can't. Of course, there is the small problem that software publishers seems to have a definite preference for non-negotiable licenses, and the VIIC language won't help in those cases. And that leaves us with the bigger issue that we've been discussing here for last few months. How do we get software publishers to play fair with DRM? I hope soon to have a lot more to say on that subject, and I hope to hear your thoughts as well. Write me at Foster@gripe2ed.com.
--------------------
Post your comments about this column below or write me directly at Foster@gripe2ed.com. To receive this column every week in my free e-mail newsletter, please go to my
subscription page and follow the instructions to opt-in for the EdFoster mailing list. |
|