Laser & DRM

Posted Oct 6, 2006 13:46 UTC (Fri) by sepreece (subscriber, #19270) [Link]

- Field upgradeability (adding new features, etc.); this is widely used in music players ["new iPod updater is available"] and set-top boxes. In the former case it's usually the owner doing the update; in the latter case the update is usually pushed by the service provider, more-or-less transparent to the user.

- Field repairs (fixing broken software); this is often included in the kind of upgrades described above; sometimes security updates are done, as for desktop software; again, it's usually either owner-initiated or pushed by the service.

- Customization in distribution; this is very important to the device manufacturers, especially for mobile phones; in this case the phone is flashed with a generic load in the factory and software specific to the carrier and/or market is flashed in distribution or at the point-of-sale; it would be possible to blow an e-fuse at that point to make all or part of the software nonmodifiable after sale, but the user would probably object, since they do sometimes ask for updates after they have the phone. There have been [very] rare phone recalls, but phone upgrades in the field are usually user-initiated.

Note that previous discussions have always centered around "user able to modify" versus "manufacturer able to modify". This ignores the more common real-world case of "user able to have the phone updated" versus "manufacturer able to update phone unilaterally".

Device manufacturers typically have no access to a device in the field [set-top boxes that are updated by a service provider are an obvious exception]. A mobile phone carrier has access, and sometimes uses it to push content updates and service-enablement updates, but generally not to update the base software. In most cases, only the user has the right/ability to initiate a software update. However, their only option is to select another manufacturer/carrier-approved load for their device.

I point this out only because it reshapes the discussion somewhat. The fairness argument has been presented as "pass along the same rights you have". In this case, the situation actually is more like "the end user can choose to upgrade the phone to a newer version of the software", which sounds much less asymmetrical.

Posted Oct 7, 2006 2:15 UTC (Sat) by mikov (subscriber, #33179) [Link]

Even if you are right and the manufacturer is resorting to DRM only because they are dirt-cheap or the device is buggy, it is certainly not the GPL's place to make manufacturers "not cheap" or to force them to sell a high quality product.

Manufacturing is a much more complex, difficult, risky and expensive process than many people realize. It is absolutely nothing like releasing software and I feel that many people in their understandable zeal for software freedom are ignoring this, probably because they don't have first hand experience with manufacturing physical goods as opposed to software.

Pragmatically speaking, I feel that since GPLv3 cannot fully prevent all restrictions to software modification (as many people pointed out a ROM is an easy option), it should not attempt it all. Further on, even if GPLv3 is ultimately the right thing to do, seeing how it is splitting the community in two before our own eyes, it is very likely to do more harm than benefit (again, as many people have pointed out).