This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!

Re:Would someone please explain Linus DRM

Posted by: lordcorusa on February 04, 2006 01:53 AM
<snip>But would this apply to other devices, like a mobile phone?</snip><snip>I personally would like to be able to view the source for the code running on my phone to make sure it doesn't have any flaws</snip>
But what happens when (1) you find a serious bug in your phone's code, report it to the vendor, and the vendor replies that they don't intend to fix the bug, for whatever reason? Or (2) same scenario, but what if your vendor tells you that your phone model 101K is "obsolete" and that you can upgrade to a new 101L for just $99? Or (3) what if you just want to add some really cool functionality to the phone that the phone company doesn't want? There are both ethically based (#3) and practically based (#1, #2) reasons for the freedom to modify GPLed apps and run them.
<snip>Is it a good idea for people to be able to control what information their phone sends or receives?</snip><snip>but I'd also want to be sure that not just anybody to load whatever code they see fit and impersonate me or interfere with my service</snip>
In your mobile phone example, you are misplacing responsibility for network security. It the responsibility of the phone vendor to ensure that their physical hardware is not capable of doing anything it should not. For example, the phone should be incapable of transmitting at a power level higher than that authorized by relevant government standards. Likewise, it is the responsibility of the network provider to ensure network security. For example, the phone network should use some kind of authentication system to ensure a given client (phone) is who it claims to be; the network should not just accept the client's word. If, as I infer from your post, the phone hardware vendors and network providers are cutting corners with physical and network security and using this as an excuse to lock us out of our right to use modified GPL software, then it is their responsibility to fix their flaws.

There is another little wrinkle in that bit of your post that reinforces my earlier point. What if you find out that your phone, in its vendor-supplied configuration, allows remote entities to upload software onto your phone? What if you think the security is too lax on this update process, but your phone company disagrees? Under the current regime, you won't have the ability to fix the problem yourself.
I still think it's a little extreme for a software license to be dictating how a hardware device that runs the code is manufactured
The whole point of any version of the GPL has always been to guarantee all users of the software 4 freedoms, including the rights to modify the software and run modifications. To some extent, this has always implied certain restrictions on hardware, in that the hardware must not be designed in such a way as to render those rights unexercisable. This draft of the GPLv3 just makes that implication explicit. Furthermore, hardware vendors are not unduly restricted. For example, the phone manufacturer could still cut corners and use a general purpose radio, but could limit that radio using some ultra-small non-GPLed firmware or microkernel, on top of which all of the GPLed software could run. This would be neither a technical nor ethical violation of the 4 freedoms, and only the most hardened open-hardware folks would oppose it. What ordinary Free Software people oppose is the use of our GPLed software in environments such that users (and by user we mean owner of the hardware) are effectively not allowed to modify our GPLed software and run it.
On the other hand if that prevents the hardware from loading encrypted software that isn't released to other people yet is required for the code to run, again, I'm for that.
This is exactly the situation this draft of GPLv3 intends to prevent. Preventing this situation may by extension prevent some "security by top-down control of clients", but I think that kind of security is just a specialized form of "security by obscurity" anyway.


Return to Torvalds versus GPLv3 DRM restrictions