Re: Kernel developers' position on GPLv3

Posted Sep 23, 2006 12:21 UTC (Sat) by jeroen (guest, #12372)
In reply to: Re: Kernel developers' position on GPLv3 by mingo
Parent article: Kernel developers' position on GPLv3

GPLv3 doesn't force anyone anything as much as the GPLv2 does. If you don't like the terms, you don't have to use the software. Write your own software. But I don't want that people use the software I write for things I don't like, such as using it a tivo-like system.

That DRM is a tool is correct, but the GPLv3 doesn't go against DRM. It goes against companies who sell DRM systems without giving users the keys to modify the software on the system. That's an use of DRM that I consider evil. And of course I would like to prevent people doing that with my software.

And how many iteration did the linking clause in the GPLv2 have? We don't know, because AFAIK the drafts were never public. Maybe there have been ten or twenty. Does that make it a bad clause? I don't think so. Linux also needed several rewrites of the packet filtering framework to get it right. Does that make packet filtering a bad thing? I don't think os. The fact that something is hard to get right isn't an argument for not doing it.

The linking clause is also not tailored to the many moral viewpoints that exist, if you listen to the BSD camp. Is that a reason to remove the linking clause of the GPL?

If you would actually think about the hypothetical situation of the GPLv2 not yet existing and then evaluating the GPLv2 according to the same criteria as being done here on the GPLv3, the result would be that GPLv2 is a bad license too. It tries to dictate morals on other people (the moral of that you should give users the freedom to hack their software), there exists many moral viewpoints about it and it is hard to get right.

to post comments

Re: Kernel developers' position on GPLv3

Posted Sep 23, 2006 13:45 UTC (Sat) by mingo (subscriber, #31122) [Link] (4 responses)

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)

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.