Liability & Reputation
Posted Oct 6, 2006 18:55 UTC (Fri) by sepreece
In reply to: Liability & Reputation
Parent article: Similar in spirit?
I didn't actually claim that DRM made the products safer [and, of course, I was talking about Trusted Computer, rather than DRM]. It makes the manufacturer safer by reducing potential liability. In the particular example that started this subthread (modifying the software controlling a laser to increase its output) it presumably would also make the product safer, but that's not really what we were talking about.
You actually asked why software should be different than hardware. I wasn't really arguing that it should. The same kinds of liability and PR issues attach to hardware as well, and manufacturers typically do what they can to avoid user modification of dangerous or regulated hardware, including things like sealing cases, drilling out screw heads, and using sealed modules.
You ask now if there is a public benefit to tolerating locked-down software [I assume that's what you meant by DRM in this context.] For regulated devices, I think there is a clear public benefit; otherwise the devices wouldn't be regulated. Note that here you asking for software to be treated more permissively than hardware, where you had previously asked why they should be treated differently - there are no legal restrictions on manufacturers' ability to make hardware unmodifiable.
You posit commercial and nefarious reasons for manufacturers to deploy DRM. I certainly know of cases where manufacturers have used reversible technical measures (either hardware or software) to downgrade special versions of products, so that they could sell them at lower prices than products without those restrictions. This is sometimes referred to as "slugging". In most cases those have been in situations where there was a contractual relationship preventing the customer from (like the well-known case of the IBM unit-record equipment that could be jumper-modified to be twice as fast]. TC clearly would help the manufacturer avoid customer self-upgrades. I don't consider that to be nefarious (nor qualitatively different from the case where exactly the same end is achieved with a one-way change that makes the device non-upgradeable).
I don't expect to convince anybody who is already convinced in the other direction. If you believe the freedom of your code is paramount, and don't mind that that freedom limits its use in certain kinds of devices, that's your choice.
to post comments)