Re: Kernel developers' position on GPLv3

Posted Sep 23, 2006 13:45 UTC (Sat) by mingo (subscriber, #31122)
In reply to: Re: Kernel developers' position on GPLv3 by jeroen
Parent article: Kernel developers' position on GPLv3

That DRM is a tool is correct, but the GPLv3 doesn't go against DRM.

i used to buy this (relatively new) line of the FSF, but then i read the actual text of the GPLv3 draft, which in Section 1 says:

The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances.

this attaches keys to the source, fundamentally. And since we all agree that modified source must be given out, the keys have to be given out too. The GPLv3 draft does carve out a few exceptions in later sections, but the damage has already been done here in Section 1: by attaching keys to the source we implicitly and explicitly judge the tool of hiding keys to be immoral! (because by hiding it you are "not giving out the modified source code")

if this "we attach keys to the source" definition in Section 1 is removed then all the DRM problems are solved - no need for the later exceptions either. This portion of section 1 is the big problem.

(Sidenote: this new "we dont go against DRM" position of the FSF is quite inconsistent with earlier positions they took - which questions whether they truly consider this whole issue so fundamental that no compromises are possible)

to post comments

Re: Kernel developers' position on GPLv3

Posted Sep 23, 2006 14:50 UTC (Sat) by mattmelton (guest, #34842) [Link]

I'm trying to guage your view here mingo...

Assuming there is a product called the MattRouter 2.2b. A Tivo'ized network router running Linux 2.6.

Would something along the lines of,

"The Corresponding Source also includes the ability to be executed, modified and installed in the recommended or principal context of use, such that it can implement all of the same functionality in the same range of circumstances"

be more up your street?

To me, such a change would mean proprietory uploaders and bootloader-compilers would have to be included with the source. These uploaders (etc) can implement the DRM provisions (such as encryption) before they are copied to ROM.

As long as I had the indirect ability to fulfill "the recommended or principal context of use, such that it can implement all of the same functionality" from source, I'd be happy.

... that is, if your agrument rests on the provision of keys alone.

GPLv3 DRM clause

Posted Sep 23, 2006 15:33 UTC (Sat) by jeroen (guest, #12372) [Link] (2 responses)

The whole DRM section is just a natural evolution of the GPL. But to understand that you've to look where the whole GPL is about. That's the freedom of the user.

To give an example: when I bought my wireless router that was running Linux I had the freedom to replace the firmware with my own version of Linux. I'm glad I was possible to do that, because now I've got nice set of iptables rules, QoS, etc. on it. But what if they suddenly decied that it is required that the firmware image was signed (like Tivo does)? Then I would be able to get the code, but I wouldn't be able to patch it and put it on my router. So they took away my freedom to run my own code on the router. This is what I consider immoral. It also clearly goes against the spirit of the GPL.

So what does the GPLv3 do against this? It requires that if you sell a device that requires a signature to upload firmware, the user should be able to generate that signature too, so that he is able to exercise his freedom to change the software running on his device. But this doesn't prevent a company that buys some of those devices to keep the signing keys in a safe place so that random employees can't flash the device with untested firmware or malicous people can't put a firmware with trojans on it. So the DRM functionality is still there, it just can't be used against the purchaser of the device.

If you have the opinion that users should have the right to fix bugs in their software, then you should actually like this clause. And even if you don't agree with that, I don't see any reason why you would have a problem with it. I haven't seen any arguments against it yet, except the bogus statement that you're forced to give away all your private keys.

I also didn't claim that the FSF isn't going against DRM. They clearly are, because they have the opinion that the tool itself is bad, and I agree with that (just like I think that tools like nuclear weapons are bad). But the GPLv3 itself isn't really going against DRM, only against the use of DRM to circumvent the GPL.

GPLv3 DRM clause

Posted Sep 23, 2006 20:25 UTC (Sat) by mingo (subscriber, #31122) [Link] (1 responses)

the big, big problem with this argument is that: this is not what Tivo did. Tivo never made their PVR "hackable". They never "benefited" from hackability, they never cycled back improvements that happened via hackability - they at most found it an annoyance. Later on they have added a special bootloader to a new generation of boxes, which would only load an OS kernel signed by Tivo. There was no stealth 'DRM-ification' of existing Tivo boxes. Furthermore, all the source code and their modifications, along with binaries (that do load on a Tivo) are made available by Tivo, just as required by the GPL. Plus, you can probably still mod your Tivo by soldering off their BIOS and putting your own BIOS in. Furthermore, a Tivo very obviously does not look like a general purpose computer, it does not smell like one and does not play one on TV. It is made, marketed and sold as a PVR, with no guarantee whatsoever that it would even contain a single screw to allow you to open the lid.

So all this vilification of Tivo is totally misplaced in my opinion.

How Tivo benefitted from hackability

Posted Sep 24, 2006 23:21 UTC (Sun) by coriordan (guest, #7544) [Link]

The problem with Tivo is not that they did a stealth operation, but that they like Linux because it's hackable, and they benefit from the freedom to tinker the software (to make it do TV stuff and to add spyware to gather data about your use of your TV), but then they rig the device to prevent the downstream recipients from benefitting from this same freedom.

This contradicts the GPLv2 world. In the nineties, the GPL made all software users of GPL'd software interact as equals. Quid pro quo. Share and share alike, etc. Then Tivo found a technology which let them distribute GPL'd software without treating the recipient as an equal. So some words need to be added to GPLv2 to restore the deal that GPLv2 gave everyone in the nineties.