Advertisement
Interested in hardware, diags, validation, Linux, C, ARM, Microcode and low level programming and blazing networks?
| |||||||||||||
|
| |||||||||||||
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Posted Oct 22, 2006 23:32 UTC (Sun) by bojan (subscriber, #14302)In reply to: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) by man_ls Parent article: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)
> Just making the memory non-updateable from software might protect against casual attackers and work in most situations.
That exactly is the problem. Flexibility is lost.
Think Sony battery recall. The only way to fix the problem with those batteries is to physically replace them (because it is a physical problem). Cost for Sony? Millions.
Now imagine a mobile phone, shipped to millions of customers around the world. And then imagine a fault is found in the software in this non-programmable memory. The only way the service providers can deliver a fix is via physical recall. Again, that would cost millions. If that memory was programmable, a fix could be delivered over the network. Cost to the providers? Zero (or close to it).
And that's why service providers want hardware DRM. From the point of view of their customers in my mobile phone example, it's a good thing (i.e. they don't have to bring the phone back, there is no "downtime", they don't have to backup/restore their address books etc.). From the point of view of the providers, it's also a good thing, as they have at least some protection against people abusing the network by "hacking" the devices.
(Log in to post comments)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 0:44 UTC (Mon) by man_ls (subscriber, #15091) [Link] If fixes are going to be distributed over the network, the phone should probably require manual confirmation for the upgrade by the user. Forced upgrades are a horrible idea, as recently seen here.If that is the case, then I think it is only fair to let the customers patch and use their own versions of the software. I don't think it is a bad compromise: use GPLv3 software, let users modify/upgrade it. Otherwise, as Ciaran enumerated elsewhere: you use proprietary code and keep tight control over upgrades, or set it in a ROM (or equivalent) and don't let anyone modify it. Seems quite close to what GPLv2 was about, anyway.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 1:33 UTC (Mon) by bojan (subscriber, #14302) [Link] > If fixes are going to be distributed over the network, the phone should probably require manual confirmation for the upgrade by the user.
I'll give you an example from real life. My mobile phone prompted me one day if I'd like to update a piece of software (essentially Java runtime) to a new version, at no cost, using my provider's network. I could have picked either yes or no (I picked yes, BTW).
I never talked about any forced upgrades - I only mentioned delivery of upgrades through the network as opposed to delivery of upgrades through physical exchange of the handset. The former is much cheaper and more convenient.
> If that is the case, then I think it is only fair to let the customers patch and use their own versions of the software.
Here is a scenario. A mobile phone company starts shipping a mobile phone based on free software (let's say GPLv2) and the phone doesn't feature any hardware that would verify the signatures of the software that runs on it. As required, the company supplies the source.
A clever customer finds out how to increase the bandwidth of the phone, while retaining the same payment plan for the service provided. The "patch" becomes popular and many users follow the HOWTO and "upgrade" the phone. Service provider finds themselves in trouble, as honest, paying customers are left without bandwidth because too many people "helped themselves" to a bit more than they paid for. The company figths back, by disconnecting rogue users, but every so often a new bunch of them pop up and disrupt the network.
I don't think any service provider dreams of a scenario like this.
Yes, I know, the arguments can be made anywhere from "security through obscurity" and "DRM is essentially flawed" to "there will always be bad people". However, most service providers will see a locked, but flexible (in terms of upgrades) device better than a device completely open to abuse and with source code floating around.
Service providers can achieve what they want with free software licensed under GPLv2 and some DRM hardware, but not with free software licensed under GPLv3, as it would render DRM hardware useless. Therefore, they are unlikely to pick GPLv3 licensed software for their devices.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 6:32 UTC (Mon) by anonymous21 (guest, #30106) [Link] This argument was made for prohibiting regular phone devices from any but the ATT monopoly and Baby bells. It is good for society to be able to run cell phones that are under the control of users, same as with regular phone.
Secondly cell phones have two chips, one runs linux and the other proprietary software. They can DRM the proprietary chip, and leave the other chip/software free. Yeah, there are sensible solutions, but if cell provider wants to absolutely dictate (to the very last bit) what the user can do, cell provider need to find something else and go somewhere else.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 6:58 UTC (Mon) by man_ls (subscriber, #15091) [Link] Yes, I know, the arguments can be made anywhere from "security through obscurity" and "DRM is essentially flawed" to "there will always be bad people".It is not only that. As anonymous21 says above, the same scenario didn't work for regular phones; and someone else commented to a different article (don't remember who, sorry) that the security and reliability of the network cannot rely on the endpoints behaving. It is bad security, and it is not very good reliability either. For computers nowadays you can connect to any ISP's network directly via the broadband they provide; they perform minimal checks as to block port scanning and the like, but generally speaking the network doesn't depend on your machine behaving. As mobile networks turn to TCP/IP, something similar should happen. Mind you, this is only a bit of forward-looking analysis; the main point is that the user deserves the four freedoms. Things might not work this way; mobile networks might be always locked, and we don't need to solve their problems. They and their users will choose GPLv3 if they want to provide such freedoms and the advantages that go with them, or they will stay proprietary and closed forever. In this second scenario we cannot let them use our software to lock us up. Short term it would be beneficial, as Linux and free software would have a wider base. Long term, the bad will generated by knowing that your software is being used to the detriment of your peers would surely offset that and give free software a bad name. IMHO all of it, of course.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 7:54 UTC (Mon) by bojan (subscriber, #14302) [Link] > that the security and reliability of the network cannot rely on the endpoints behaving
Yeah, that's what I meant with security through obscurity (i.e. the network is safe as long as the client acts in a "secret" way). Very true, of course.
Given the real world experience with purchases of mobile phones and then trying to switch them over to different providers, I think the providers are still doing this to some extent. Some providers wouldn't let certain phones onto their network.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 12:42 UTC (Wed) by sepreece (subscriber, #19270) [Link] There's no "obscurity" involved. The protocols that cellular phones operate over are published and generally have been implemented by many people. The client does not "operate in a secret way".
However, the client (phone) in a cellular network has much greater scope to disrupt the network than a wired phone. That's just the nature of radio. That's why the FCC requires certification of devices that operate in cellular networks.
Obviously, there are many other ways to disrupt the network, too. Those means are generally illegal. Is it surprising that manufacturers don't wish to risk their certification and liability suits by letting third parties modify their devices?
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 0:19 UTC (Thu) by bojan (subscriber, #14302) [Link] Thanks for the clarification on wireless network disruptions. I really don't know anything about that, so I was just guessing (obviously incorrectly) the "obscurity" was the reason for wanting locked devices on the network.
> Is it surprising that manufacturers don't wish to risk their certification and liability suits by letting third parties modify their devices?
Exactly. They find a device that is both flexible (i.e. programmable via the network) and at the same time locked quite useful. Releasing keys for the software on such a device would make it unlocked again, defeating the purpose of locking it in the first place.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 0:42 UTC (Thu) by man_ls (subscriber, #15091) [Link] Is it surprising that manufacturers don't wish to risk their certification and liability suits by letting third parties modify their devices?On the contrary, it is quite the expected. That is why people are not speaking against the manufacturers. What many of us don't get is that hackers are so willing (even eager it would seem) to be their master's puppets. Many network behaviors are illegal, but I don't see hackers advocating for closed (or worse, locked) networking stacks. Well, live and see.
|
|
||||||||||||