The FSF, GPLv3 and DRM 388
whats-life-without-gpl writes "FSF has a thing against DRM. This article tries to explain why RMS isn't a DRM (Note that NewsForge is also owned by OSTG) fan and how GPLv3 is gearing up to protect against it. "
Preaching to the choir? (Score:5, Insightful)
*waves to the trolls* Hi! This is for you!
1) The GPL is only ever a problem for you if you want to distribute someone else's work that they already let you use for free.
2) See point 1.
Gift horse, mouth, examination via the anus... all those are things that spring to mind when I hear complaints about how restrictive the GPL is.
He is against DRM, but that's not the point (Score:5, Insightful)
Since the beginning the idea of free software (as rms sees it) is that if you use a program, you should have the freedom to modify it, among other freedoms. So if you have a Tivo, you should have the freedom to modify the software that runs on your Tivo. If Linux is GPLed, then it's clearly not allowed for the Tivo manufacturers to ship it with a label saying 'we forbid modifying the software'. It's also not allowed under the GPL for them to try blocking your freedom another way by withholding the source code. But under GPLv2 your freedom to change the program can still be taken away, by the manufacturer making the device only execute signed binaries (for which nobody but the manufacturer has the signing key). GPLv3 as proposed is about making sure your freedom to change the software running on your computer (or Tivo) isn't taken away like this.
Of course anyone can write GPLed software that has DRM restrictions. But if you use it, you should have the right to modify it, and remove the DRM if you don't want DRM on your computer. That is the important point.
Analogously: there is nothing in the GPL against charging a sum of money for the software. You can sell it for as much as you like. But if you do, the person who receives it still gets all the freedoms to use, share and change the program.
Re:The problem with signing (Score:3, Insightful)
Re:The problem with signing (Score:5, Insightful)
Linux signing the key is different because its unenforced. Its a way of recognizing that Linux blesses this version of the kernel, but it doesn't stop you from running any other version of the kernel.
Re:The problem with signing (Score:1, Insightful)
If the company makes that decision for their own computers then that's fine. Just like I can make that decision for my computer.
The problem arises when someone wants to sell to others a device running GPLd code and prevent those other people from being able to modify the code.
The two situations aren't at all the same. It's silly to pretend that they are.
I fear a repeat of the Bison fiasco... (Score:5, Insightful)
I fear that GPLv3, by trying to force RMS's notion of "Liberty" more strongly (anti-DRM provisions, anti-closed-hardware provisions) will be a repeat: GPLv3 based software will only be used by the real FSF zealots. Everyone else will avoid it.
Let us be thankful that Linus Torvald has more of a "tit for tat" notion rather than a liberty notion, and thus selected GPLv2 only.
Re:Linus needs to join the party (Score:3, Insightful)
Technically speaking they are not ignoring the GPL.
The purpose of the GPLv2 was never to force all hardware to run your custom software, it was to force other developers to publish their own changes to your code (please note that I am talking about the intents of the GPLv2, not the intents of the FSF). In other words: feel free to modify the software... just don't expect it to run in my hardware. And Linus simply chose the GPLv2 to distribute the kernel based on its intents, and not on the FSF's agenda (ie: the "quid pro quo" argument made by Linus demonstrates this point).
I realize that there's a lot of people here that think this is wrong, and I respect that choice. But why can't Linus make his own choice? Isn't him in his full right to do so?
Re:Preaching to the choir? (Score:0, Insightful)
Re:What's wrong with TiVo? (Score:1, Insightful)
They comply with the letter of the "law", but not it's spirit. There's nothing open or free about tivo.
Re:DRM isn't the problem (Score:1, Insightful)
Re:Preaching to the choir? (Score:3, Insightful)
Re:He is against DRM, but that's not the point (Score:3, Insightful)
So fundimentally, what's the difference between hardware only running signed code, and having the code on a PROM chip? Is the GPL V4 going to end up banning the use of read-only memory?
Re:What's wrong with TiVo? (Score:5, Insightful)
Sure, by requiring signed binaries, you are restricted to run code only from TiVO. This restricts what users can do with their own hardware.
At the same time, since these devices are now on networks, there is a real possibility of them getting hacked. If TiVO ran untrusted binaries, this probably would have already happened. Of course, this happens now with Series 1 TiVO's, but you can't put them on the net without hacking, and if you are smart enough to do that, you probably have a firewall. So in some ways TiVO is doing a good thing by only running trusted code.
It is an interesting tradeoff.
Violates SPIRIT of GPL. (Score:3, Insightful)
Complying with the letter of the license is not the same thing as complying with the spirit and intent of it. The GPL is designed to ensure that the user always has control over his hardware; since the TiVo won't run modified code, the user does not have this control. QED.
Re:The problem with signing (Score:4, Insightful)
You rights under the gpl require them to let you have the source code for GPLed software they distribute and possibly change it if that is your wish. Nothing in the GPL makes a claim that you are entitled to run that code on any specific hardware, is there? Not any provision that i know of.
Having hardware and not being able to run whatever you want on it is a different story. If you want to do something the manufacturer didn't intend, then you are going to have to work around the limitations of the hardware. This includes limitations purposly implanted by the manufactuer. But, unless the hardware is GPLed, I don't see anything in the GPL guarenteeing this ability.
This is a key example of why manufacturers don't want to provide GPLed drivers. It will be construed before the day is out that there is some fundelmental rights here and assure microsofts possition on the GPL being viral. Stop and really think about it from an angle outside the everything should be free attitude and look for the real issue.
Re:The problem with signing (Score:5, Insightful)
The second draft is very explicit and well thought-out; the question is whether you agree with the intent. On the one side, RMS (and an all-star cast) with a strong philosophical position supported by well thought-out arguments. On the other hand, Linus with some spur of the moment comments opposing RMS (at least I hope Linus' comments are spur of the moment because his position is not well articulated).
Re:The problem with signing (Score:3, Insightful)
The sensible angle to look at it from is "what am I trying to achieve in licensing my software?"
If you want users of your software to receive the right to modify it then these terms are likely to suit your aims.
If you want manufacturers to be able to limit the ability of recipients to modify your code then the GPL is probably not a good license for you, and never was.
Re:The problem with signing (Score:5, Insightful)
It doesn't matter what manufactures want. They aren't obligated to support linux. They aren't forced to use linux in their closed embedded systems. But if they do use it, since it means less cost, easier maintenance and higher quality, they are agreeing to the contract under which that code may be distributed. In the case of Windows CE, there is a definite cost and an onerous contract you need to agree to. Linux to has a cost too. You need to offer the source to anyone you give the software to. Leased, bought or free, you still need to offer them that.
Re:The problem with signing (Score:3, Insightful)
Uh, no, it's just that the hardware you bought was damaged by design when you bought it. Tough, you should have bought something else. If I bought a PPC Mac would the fact that it won't boot Windows be violating my rights as an owner? No. (Of course, some of us would see that as a feature rather than a bug.)
Re:I fear a repeat of the Bison fiasco... (Score:3, Insightful)
How would the proposed GPL v3 affect average programmers in a negative way, other than denying us pieces of hardware that come with GPL binaries and source code but which we can't use with modified versions of the source?
Re:The problem with signing (Score:3, Insightful)
And the GPL can easily be extended to hardware- thats what the GPLv3 does. It ensures that if you use GPLed code in your hardware product, that the user must maintain the right to modify the code. It protects the principles of Free Software that the GPL was created for. If the hardware maker wants to take away my rights as a user, they can write their own damn software to do it with.
Re:The problem with signing (Score:1, Insightful)
DRM isn't necessarily evil. (Score:2, Insightful)
DRM can be used for good. Let's say you want to build an electronic voting machine properly. You use entirely GPL source code. All parts are off-the-shelf and well known. Everything is open to public review. However, when you actually go to send the machines out, you want to be damn sure those machines are running the same code you put on them at the factory. That means locked and tagged boxes, and that also means DRM. Under the GPLv3 draft, you'd have to publish the secret key to the world, making that security worthless.
Another case: Let's say I make a system that monitors building security. I want to be open about how it all works, so I use GPL'd hardware. However, even my customers want to make sure that the software isn't tampered with. That means DRM. Again, if I have to publish the secret key, someone could write a modified version, sign it with my key, and get it on the machine.
The GPLv3 draft makes it impossible to create tamper-resistant software. (Note, I didn't say tamper-proof, there would still be ways around it, but as part of a layered security, it is necessary.)
Bison fiasco? Numerous GPLv2 forks are unlikely. (Score:2, Insightful)
Of course, one could always make a fork of some particular project and allow GPLv2 only. Yet starting from this point it is impossible to reuse any GPLv3 code in it. Whole libraries might become not suitable for this GPLv2 fork, at least the new versions of these libraries. Maintaining such GPLv2 forks may become really difficult. Linux kernel is probably one of few projects which may stay with GPLv2 for a long time. Most small projects are likely to make a transition to GPLv3, either willingly or by using some GPLv3 code.
Re:The problem with signing (Score:3, Insightful)
But an otherwise general purpose computer that will only load specially signed binaries is "damaged by design" in the same way that a 6-slot motherboard that has had two slots filled with glue and sold (cheaper) as a 4-slot mobo is damaged by design. (And before you scoff at this example, review the history of some of the old DEC Q-Bus and VAX systems.) Another example would be a car inherently capable of 120MPH with a manufacturer-installed governor to limit it to 70 MPH.
"Damaged by design" implies adding something extra to limit the hardware's capabilities. Sure, it's the manufacturer's right to do so, and your problem if you're silly enough to buy it.
Re:DRM isn't necessarily evil. (Score:2, Insightful)
The only time the DRM comes into effect is in those individual machines that are sent out to vote with. They'll contain a signed version of the software that will refuse to run if it is tampered with. The source code would be fully available and the machines themselves are standard hardware with just an extra drm chip in them. If you wanted, you could just run an unsigned version of the voting software on a normal PC.
The point of the DRM is to help make sure the devices are safe from tampering. This is not just for voting machines, but anywhere you need a device to be tamper-resistant. From voting machines to security servers to ATMs to who knows what. There are plenty of appliace-style devices that are running computer code that could benefit from being tamper-resistant. Currently, most of them are pretty basic and use more of what we'd call electronics, rather than computers, but that's changing. How about a computer that controls a building's elevators? Air traffic control, heck, in the future we might have ground traffic controls. The GPLv3 draft completely cuts off this entire line of legitimate use out of ideological hatred of one possible use of this tool.
If they put something like "If you sell drm'd hardware, then you also have to sell a version of the hardware, at no extra cost, that does not contain the drm restriction", this entire problem would go away. People could have their secure machines, Linus could sign his kernel without having to give up his key, and everyone comes out happy.
Re:What's wrong with that? (Score:3, Insightful)
The example you site has nothing to do with the GPLV3. The fault is either with:
1) The company who released hardware built on code that allowed others to change the code in an environment where that's a bad idea. (ie, build your own fricking code, don't rely on others who want their code to be modifiable, not just easy to print out and stare at)
or
2) The moron who loaded code onto a machine that could cause problems, probably violating federal law in using a non-FDA approved device (since I imagine the FDA approval only covers the device with specific code).
The GPLV3 is not evil and didn't cause anyone's heart monitor problems, the above did.
As for a comment period, check out:
http://www.fsf.org/news/gpl3.html [fsf.org]
Scroll to the bottom, specifically the section near: "The Foundation will, before it emits a first discussion draft, publicize the process by which it intends to gather opinion and suggestions. The Free Software Foundation recognizes that the reversioning of the GPL is a crucial moment in the evolution of the free software community, and the Foundation intends to meet its responsibilities to the makers, distributors and users of free software. In doing so, we hope to hear all relevant points of view, and to make decisions that reflect the many disparate purposes that the license must serve."
Re:What's wrong with that? (Score:3, Insightful)
The only reason they would have to provide that signing key would be if they rig the hardware so that it is NOT possible to run modified binaries in any other way. This would be silly.
Instead, what they should do, is include a documented, warranty-voiding method to turn off the circuit that refuses to load unsigned binaries. As an example - you have a locked, tamper proof box (like all medical equipment) and the purchaser receives a key. They may, at their discrection, use that key, unlock the box, and change a jumper on the main board. Then replace and relock the case, reboot, and answer 'yes' to a confirmation dialogue with GIANT WARNING TEXT all over it. At this point, they can load whatever kernel they want. They've also voided the warranty and any and all FDA certifications of the box, so it's now illegal to use it for its original purpose. There could also be a permanently visible tamper indicator, I would suggest a red and green light placed prominently for all to see, clearly labeled, that would switch from green to red if the box was even opened.
There's no need to distribute any signing keys here, as the ability to run modified binaries is preserved without doing that. And legal liabilities are clearly shifted from the manufacturer in the event that a customer chooses to do that.
Re:The problem with signing (Score:3, Insightful)
GPL or not, there is not and should not be any obligation for a vender to allow you to use the equiptment they are selling any differently then thier intended purpose. The GPLv3 will probably end up with hardware venders looking elswere for thier software. It will be a step or two back in getting vender supported drivers for linux or other hardware that can even run for that matter.
I'm starting to see the value of the BSD license at this point.
Re:The problem with signing (Score:3, Insightful)
The GPL was always, explicitly, designed to allow free usage of GPL code only to those who are willing to also allow that same freedom to those downstream of them.
Why you think that people "should" be able to strip those downstream of their freedom is a mystery, since you don't support the absurd assertion in any way.
Your assertion that hardware vendors will decline to use GPL v3, to the extent it's to be interpreted as meaning a significant portion of them will do this, is argued against by history. People claimed the same sort of thing about earlier versions of the GPL, but in fact, commercial vendors that are willing to return value have gravitated overwhelmingly to GPL vs BSD projects. And for good reason. BSD is only 'business friendly' to businesses that return nothing, as it allows that, but to anyone that returns value to the community, GPL is much more 'business friendly' as it prevents competitors from taking that work without returning value in turn. If, for instance, IBM contributes code to a GPL project, they can have some confidence that they aren't strengthening their competitors by doing so. The competitors can use the code, certainly, but they are in turn obligated to 'play nice' and return their additions to the community, so IBM as well as everyone else gets value returned. Licensing under BSD, on the other hand, is a black-hole: your competitors can take your contributions, leverage them to create a product that competes with you, and give you nothing back at all.
Companies that view BSD as being more friendly to their interests do exist, of course, but they're the companies we don't want using our code anyway. They're the ones intent on taking our code, tweaking it slightly, and then using it against us. They would never contribute anything back anyway, so who cares whether they like it? They're to be avoided, not helped.
The rest of the companies, the ones that understand that business is about creating value, appreciate the GPL, once they understand it. I see no reason to think that won't be even more true of v3 than it has been of v2.
The real problem with trusted computing (Score:3, Insightful)
- bad thing:
- Tivo sign their kernels using their secret key.
- Tivo's bootloader refuses to boot any kernel not signed by tivo
- good thing (prevents trojan LKMs):
- RH sign their LKMs using their secret key.
- A RH kernel binary refuses to load any LKM not signed by RH.
As far as i understood the discussion, GPLv3 thinks that (1.1) is the problem, so it demands publishing the secret key. But that's wrong and renders (2) useless.Instead, the problem is (1.2): i cannot append my own pubkey to the bootloaders list of approved binary signing keys, although i "own" that bootloader. Instead with (2.2), i can build and run my own kernel image embedding a different list of acceptable LKM signing keys.
So if one wants to prevent such a mess like tivo, (s)he should use a licence that demands that the software is not run on devices with a write protected TC pubkey list. I'd perfectly happy with TC if i could enter the fingerprints of valid TC-pubkeys into the BIOS.
Just my 2ct, m.