| |||||||||||||
|
| |||||||||||||
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Posted Oct 24, 2006 15:50 UTC (Tue) by farnz (guest, #17727)In reply to: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) by bojan Parent article: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) My reading of the GPLv3 (and I could be a non-lawyer misunderstanding it here) is that the manufacturer doesn't have to give away their private keys. Instead, they could allow the owner to add their own key, so long as this gives the same access as the manufacturer's key. This lets you use DRM to (for example) detect that the user's not running your approved software, and refuse them warranty service (which is outside the scope of the GPLv3), but not to use DRM to prevent the owner from using their software on their cellphone.
(Log in to post comments)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 0:01 UTC (Wed) by bojan (subscriber, #14302) [Link] > This lets you use DRM to (for example) detect that the user's not running your approved software, and refuse them warranty service (which is outside the scope of the GPLv3), but not to use DRM to prevent the owner from using their software on their cellphone.
Which is just about the same as allowing unsigned software run on the same device - you just don't trust it. And since the TC hardware doesn't trust it, it may disable functionality of say 90% of the device, including the ability to connect to the network, see the address book etc.
If that's what FSF had in mind, then this is the same as asking the hardware manufacturers to design their hardware to be capable of running unsigned binaries. That's all cool by me, but I don't think user's freedom is completely preserved here, as the device effectively becomes crippled, making the whole thing a sham.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 8:14 UTC (Wed) by farnz (guest, #17727) [Link] Not quite; the hardware must trust the user's key enough to let the GPLv3 software behave identically whether it's signed with the user's key or signed with the vendor's key.Thus, TC becomes useful for enforcing a warranty (for example), since you can confirm that the device is running your authorised software before you agree to take the device back. It's not useful for (e.g.) preventing the user from watching movies unless they're running your authorised software.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 21:20 UTC (Wed) by bojan (subscriber, #14302) [Link] > Not quite; the hardware must trust the user's key enough to let the GPLv3 software behave identically whether it's signed with the user's key or signed with the vendor's key.
And there lies the problem - this will never happen. The whole idea of TC is that you only trust things sign with vendor's keys. The user is by definition an untrusted party.
> Thus, TC becomes useful for enforcing a warranty (for example), since you can confirm that the device is running your authorised software before you agree to take the device back.
Or, you can just run a quick md5sum/sha1sum against the binaries and find out the same.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 8:34 UTC (Thu) by farnz (guest, #17727) [Link] In other words, TC means that the vendor doesn't want the user to be free to exercise the four freedoms that Stallman wants all users to have. No wonder the GPLv3 stops this.And how exactly do you get a trustworthy md5sum/sha1sum from a device in a user's hands without TC? I was thinking in terms of a mobile phone or ADSL modem, where you might well want to not offer support if you can't confirm that the right software's running on the device; being able to check this from the other end of a phone line or e-mail conversation quickly, and avoid wasting 10 minutes while you try and support a user who's changed the software. In the TC case, you can just insist that they boot with your software before they get support.
|
|
||||||||||||