| |||||||||||||
|
| |||||||||||||
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)Posted Oct 22, 2006 23:57 UTC (Sun) by bronson (subscriber, #4806)In reply to: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) by hitmark Parent article: Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)
"from what i recall, the original problem linus and others had with the DRM part of the GPL3 was that it made it sound like the devs had to give away the private keys they used to sign patches and similar."
The problem is that, if a hardware manufacturer creates a hardware platform that will only run signed binaries, the GPLv3 requires the manufacturer to give away his private keys. This greatly limits the places where GPLv3 code may run, effectively ruling out running GPLv3 code on modern set-top boxes, mobile phone handsets, automatic teller machines, voting machines, etc. FSF employees love this restriction, Kernel devs just don't see the need.
Kernel devs only want tit for tat: if you write your code based on my code, you must make your changes available to me too. The GPLv2 is an excellent license to ensure this.
The FSF wants this in the GPLv3 too, PLUS they want the hardware manufacturer must make any modifiable software to be modifiable by the customer as well. Therefore, if Motorola can install a new firmware in their handset, the customer must be able to create and install an equivalent firmware as well.
The upside is that this restriction will hopefully cause many more open devices to flourish in the marketplace. Personally, I think this notion is rather far-fetched. The downside is that GPLv3 contains language trying to prevent code from being used in places where firmware uploads are restricted by the manufacturer. To me, it sounds like they're inserting rather shaky, contentious, and broad language to try to solve what has been so far a non-issue.
The disagreement still exists in the latest draft and this article suggests that it will never be solved: "the final version of GPLv3 will retain some clause to preserve the freedom to modify software and run it on the computer that the original software was intended to run on". (Erm, even if the user doesn't own the hardware where the software was intended to run? Say, leasing time on a mainframe or a cell phone handset?)
This discussion will continue for quite some time I'm afraid.
(Log in to post comments)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 1:04 UTC (Mon) by bojan (subscriber, #14302) [Link] > The problem is that, if a hardware manufacturer creates a hardware platform that will only run signed binaries, the GPLv3 requires the manufacturer to give away his private keys.
Excellent summary of the problem. In essence, the hardware manufacturer is supposed to go through all the trouble of desiging and manufacturing the hardware (in such a way that it is extremely difficult to find those private keys inside it) and then signing the binaries, only to give the very private keys away to millions of customers in a plain file. I would venture a guess that not one manufacturer is going to do this, as it is just plain silly.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 11:46 UTC (Mon) by nim-nim (subscriber, #34454) [Link] > In essence, the hardware manufacturer is supposed to go through all the> trouble of desiging and manufacturing the hardware (in such a way that it > is extremely difficult to find those private keys inside it) and then > signing the binaries, only to give the very private keys away to millions > of customers in a plain file. I would venture a guess that not one > manufacturer is going to do this, as it is just plain silly.
What's plain silly is pretending that DRM is a life-and-death for manufacturers, that manufacturers will design a complete expensive system, but it won't be able to perform the simplest operations (like handling several keys)
To read some people here DRM is rocket science but its limitations pile up:
Choose your ground guys, either your DRM will be a botched dirt-cheap CSS-like implementation (in which case it's not really the GPLv3 problem) or the manufacturer will go to the "trouble" of designing a solid system. In which case the GPLv3 requirements are not much different from the ones needed to :
The "one key to rule your all" postulate is no more true in the proprietary software world than in one exposed to the GPLv3
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 21:19 UTC (Mon) by bojan (subscriber, #14302) [Link] I really don't understand what your post. The question is why would someone design a secretive hardware system (regardless of how many secrets there may be) and then give those secrets away wholesale. It doesn't make sense.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 7:01 UTC (Tue) by nim-nim (subscriber, #34454) [Link] Because the security of a system and the autorisation granularity are two different things? (and note I'm using security there not secretivity wich is an altogether different and worthless concept)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 9:41 UTC (Tue) by bojan (subscriber, #14302) [Link] Correct me if am wrong, but the basic premise of trusted computing (i.e. DRM hardware) is that there is a piece of hardware that holds secrets (keys) that are very difficult to get to using "conventional" means (i.e. you have to hack the hardware to fetch them).
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
So, if there is a GPLv3 software in operation on this platform, why have the keys at all? They are pretty much public in the case of say a mobile phone (i.e. millions of people would have them), so the ones kept in hardware (whether they can be changed, expired and what not) are no longer secret, no matter how you look at it, as it is the requirement of the GPLv3 that every user gets those keys. In essence, from the point of view of the TC hardware, GPLv3 is untrusted software.
So, the authorisation granularity here boils down to "don't trust this, everybody has *these* keys". Therefore, it is more or less meaningless to distribute to large amounts of "uncontrolled" users all those keys and still have the hardware that supposedly verifies things based on the secrecy of those keys.
PS. I'm not commenting here in the validity of the TC as a security, authentication or autorisation system.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 11:29 UTC (Tue) by nim-nim (subscriber, #34454) [Link] Of course not.You don't authorize a key for everything. You authorize a key for specific level of accesses.
If your system is properly designed :
Again, the GPLv3 is only a problem for blanket one-for-all *stupid* and *dangerous* DRM (akin to deploying thousands of systems running every service as root using the same password)
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 13:45 UTC (Tue) by bojan (subscriber, #14302) [Link] > You authorize a key for specific level of accesses.
But that's the rub here. The keys shipped with GPLv3 software are practically public, making them completely untrustworthy, therefore having zero level access.
And that's the argument I'm trying to make: GPLv3 and TC (i.e. DRM hardware) are for most purposes incompatible.
So, not many would go through the trouble of implementing such a system.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 14:48 UTC (Tue) by nim-nim (subscriber, #34454) [Link] In what way a device-specific key (as is this specific device with this specific device number) is incompatible with TC (i.e. DRM hardware) or GPLv3 ?
Except as locking the owner out that is.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 22:12 UTC (Tue) by bojan (subscriber, #14302) [Link] > In what way a device-specific key (as is this specific device with this specific device number) is incompatible with TC (i.e. DRM hardware) or GPLv3?
The key is not incompatible with anything. The GPLv3 software is (for most practical intents and purposes) incompatible with TC (DRM hardware), because it requires that the very keys that are supposed to be secret are to be given away to just about everyone. It's that simple.
Why on earth would someone have a secret embedded in hardware only to give it away in a plain file, therefore making the secret, well, not secret any more? They may as well treat GPLv3 software as completely not trusted (from the TC platform point of view) - it's just about the same.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 21:26 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] TC is not entirely incompatible with GPL v3. For instance, suppose I have a machine-specific secret key and a notion of "secure level." I, the user, have to perform some action to unlock the system--that is, lower the secure level. When it's unlocked, I can add/remove/change software and then re-lock it. (The lock could even have a physical aspect, such as a jumper or switch.)
When re-locking, the machine then signs each of the added/changed software using its secret, machine-specific key, and subsequently refuses to run any software with invalid signatures. That is, until it's unlocked.
This seems like a great way to harden servers.
It should be possible to run GPL v3 software on such a system. Making a key available doesn't mean telling the person what the key is.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 22:11 UTC (Tue) by bojan (subscriber, #14302) [Link] > I, the user, have to perform some action to unlock the system--that is, lower the secure level.
TC relies on the machine (i.e. hardware) to do this. The machine doesn't trust you to do it, but only itself. Letting users unlock anything defeats the purpose of TC immediately.
You are just replacing one secret with another here and this is explicitly not how TC platforms are designed to work.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 22:39 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] The TPM technology underlying TC does not rule out owner-override. Unfortunately, no TC stack provider wants to provide it. I was speaking from this technical aspect. GPL v3 software should be just fine on a TC box with owner-override. You STILL don't get to see the key with owner-override, which was my main point. But you do get (indirect) access to it.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 23:43 UTC (Tue) by bojan (subscriber, #14302) [Link] > Unfortunately, no TC stack provider wants to provide it.
Yeah, that's the key here (excuse the pun). They don't want to trust users - that's why they are keen to implement TC in the first place.
A consumer device manufacturer or service provider that starts shipping TC on their devices is unlikely to give users the power to override anything, as it would defeat the purpose of having TC on the platform (i.e. they want to ensure that only software approved by *them* runs there). I know, that's bad and all, but that's what they want. I think in such a scenario, they are very unlikely to ship GPLv3 software on such hardware, as it would defeat the purpose of building such a platform.
Basically, FSF may as well have specified in the GPLv3 draft that you are not allowed to ship signed binaries that would run only on designated hardware. The whole thing with "you can do it, but you have to give away the keys" is a bit silly (an attempt at sarcasam by FSF? :-). Not many are going to take "advantage" of that.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 9:59 UTC (Thu) by nim-nim (subscriber, #34454) [Link] So they won't ship GPLv3 software. Or more accurately they will have to think about the consequences of blanket DRM (I'm not at all convinced all of them will rather get in bed with a difficult parter like MS just to avoid following the GPLv3 license)
Right now they can eat their cake and keep it too - but it's no entitlement
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 24, 2006 15:50 UTC (Tue) by farnz (guest, #17727) [Link] My reading of the GPLv3 (and I could be a non-lawyer misunderstanding it here) is that the manufacturer doesn't have to give away their private keys. Instead, they could allow the owner to add their own key, so long as this gives the same access as the manufacturer's key.This lets you use DRM to (for example) detect that the user's not running your approved software, and refuse them warranty service (which is outside the scope of the GPLv3), but not to use DRM to prevent the owner from using their software on their cellphone.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 0:01 UTC (Wed) by bojan (subscriber, #14302) [Link] > This lets you use DRM to (for example) detect that the user's not running your approved software, and refuse them warranty service (which is outside the scope of the GPLv3), but not to use DRM to prevent the owner from using their software on their cellphone.
Which is just about the same as allowing unsigned software run on the same device - you just don't trust it. And since the TC hardware doesn't trust it, it may disable functionality of say 90% of the device, including the ability to connect to the network, see the address book etc.
If that's what FSF had in mind, then this is the same as asking the hardware manufacturers to design their hardware to be capable of running unsigned binaries. That's all cool by me, but I don't think user's freedom is completely preserved here, as the device effectively becomes crippled, making the whole thing a sham.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 8:14 UTC (Wed) by farnz (guest, #17727) [Link] Not quite; the hardware must trust the user's key enough to let the GPLv3 software behave identically whether it's signed with the user's key or signed with the vendor's key.Thus, TC becomes useful for enforcing a warranty (for example), since you can confirm that the device is running your authorised software before you agree to take the device back. It's not useful for (e.g.) preventing the user from watching movies unless they're running your authorised software.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 25, 2006 21:20 UTC (Wed) by bojan (subscriber, #14302) [Link] > Not quite; the hardware must trust the user's key enough to let the GPLv3 software behave identically whether it's signed with the user's key or signed with the vendor's key.
And there lies the problem - this will never happen. The whole idea of TC is that you only trust things sign with vendor's keys. The user is by definition an untrusted party.
> Thus, TC becomes useful for enforcing a warranty (for example), since you can confirm that the device is running your authorised software before you agree to take the device back.
Or, you can just run a quick md5sum/sha1sum against the binaries and find out the same.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 8:34 UTC (Thu) by farnz (guest, #17727) [Link] In other words, TC means that the vendor doesn't want the user to be free to exercise the four freedoms that Stallman wants all users to have. No wonder the GPLv3 stops this.And how exactly do you get a trustworthy md5sum/sha1sum from a device in a user's hands without TC? I was thinking in terms of a mobile phone or ADSL modem, where you might well want to not offer support if you can't confirm that the right software's running on the device; being able to check this from the other end of a phone line or e-mail conversation quickly, and avoid wasting 10 minutes while you try and support a user who's changed the software. In the TC case, you can just insist that they boot with your software before they get support.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 3:11 UTC (Mon) by xoddam (subscriber, #2322) [Link] > Kernel devs only want tit for tat: if you write your code based on> my code, you must make your changes available to me too. The GPLv2 > is an excellent license to ensure this.
The GPLv2 does not ensure this. Do the GCC developers have access
The GPLv2 was written to ensure the freedom of *users* of GPL-licenced
The GPLv3 also attempts to ensure the freedom of *users*.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 18:00 UTC (Mon) by bronson (subscriber, #4806) [Link] Do the GCC developers have access to any version of the Stanford Checker?Ah yes, the old run-it-on-a-server hole. Does the GPLv3 change this? It has nothing to do with DRM, of course.
Linus' claim that GPLv2 guarantees quid pro quo for developers is false Posted Oct 23, 2006 23:56 UTC (Mon) by xoddam (subscriber, #2322) [Link] > Ah yes, the old run-it-on-a-server hole. Does the GPLv3 change this?
No. The Affero clause (one of the optional additional restrictions) can
> It has nothing to do with DRM, of course.
Sorry, I should have edited the subject line. I was addressing the claim
running GPLv3 code just on a server Posted Oct 23, 2006 23:56 UTC (Mon) by sanjoy (subscriber, #5026) [Link] Do the GCC developers have access to any version of the Stanford Checker? Ah yes, the old run-it-on-a-server hole. Does the GPLv3 change this? It has nothing to do with DRM, of course. Is the Stanford checker run as a web service to which you feed in your own code? Or do you submit your code to the company and they run their program on your code? If it's the first case, then the GPLv3 has provisions for this case. The copyright holder can add restrictions from a limited set. One permissible restriction is the so-called Affero clause. From draft 2, section 7(b)(4):
If it's the second case (you give them code, and they run the checker within the company, i.e. privately), then the GPLv3 doesn't say anything about it (except in the patent-retaliation clauses).
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 23, 2006 6:18 UTC (Mon) by anonymous21 (guest, #30106) [Link] >> Give away his private keys.Give it to the customer, not to random Joe.
>>This greatly limits... automatic teller machines, voting machines, etc.
Nope. Bank/Government gets the keys. Which is good. What is best if they can change the keys and lock the manufacturer out. Stops voting fraud.
elections are a red herring Posted Oct 23, 2006 7:25 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] With voting machines, the machines' owner is the local government agency that has bought the voting machines. The GPLv3 requirement would be that the company (e.g. Diebold) that manufactures the machines cannot hoard the keys. The effect is that the agency that owns the machines, not the manufacturer, is in control of upgrades. It's the same deal with ATM machines; the bank is the owner and a DRM limit just puts the bank in charge of security.Of course, that also means that GPLv3 is of limited use in blocking Tivo-ization. Many of Tivo's competitors use the business model that the set-top box belongs to the satellite company, you just rent it. Since you aren't the owner, then presumably GPLv3 doesn't say you have to get the key; the machine never changes hands.
elections are a red herring Posted Oct 23, 2006 13:18 UTC (Mon) by MathFox (guest, #6104) [Link] It's the same deal with ATM machines; the bank is the owner and a DRM limit just puts the bank in charge of security.An ATM is usually placed at a bank office; they are not handed to bank-customers. A bank storing Linux CD's in one of their vaults is certainly not distributing. Many of Tivo's competitors use the business model that the set-top box belongs to the satellite company, you just rent it. Since you aren't the owner, then presumably GPLv3 doesn't say you have to get the key; the machine never changes hands.I disagree here: when I lend you a Linux CD in a box I am distributing Linux to you. Why would CableCo not distribute Linux to you when they rent you a Linux flash image in a set top box?
elections are a red herring Posted Oct 25, 2006 12:52 UTC (Wed) by sepreece (subscriber, #19270) [Link] Go back and read the distinction between "propagating" nad "conveying" in GPLV3 draft 2.
kernel devs and job security Posted Oct 23, 2006 17:22 UTC (Mon) by man_ls (subscriber, #15091) [Link] Kernel devs only want tit for tat: if you write your code based on my code, you must make your changes available to me too.I would say we may as well call things their proper names. Some kernel devs only want to expand the Linux user base so they can land better jobs. They already know how to program for the Linux kernel and have plenty of toys to install it onto; making their skills scarce would only benefit them. "Tit for tat" + "see but don't touch" is a good way to ensure that only professionals can play and leave amateurs out. In contrast, GPLv2 always tried to give users the same rights as developers. GPLv3 follows this pattern nicely. Those with good jobs and scarce talents don't have to care about the same issues as the unwashed masses, or so they think. Luckily not all kernel devs are like this; and Linux is not even the only kernel. If Sun plays its cards well, and makes OpenSolaris GPLv3, we might still see a radical change in the free software panorama in a few years. Just don't hold your breath until you are running a GPLv3 system.
GPLv3 Solaris?!?!? Posted Oct 24, 2006 0:00 UTC (Tue) by xoddam (subscriber, #2322) [Link] > If Sun plays its cards well, and makes OpenSolaris GPLv3
Hahaha!!!! Now *that* would put the cat amongst the pigeons!!!
Honestly, I will be very very amused (not to mention pleased) if this
GPLv3 Solaris?!?!? Posted Oct 24, 2006 6:42 UTC (Tue) by man_ls (subscriber, #15091) [Link] Honestly, I will be very very amused (not to mention pleased) if this highly unlikely scenario comes to pass.Honestly, me too. But Sun's CEO is at least evaluating the option; that is one big step that kernel devs have not taken yet. I'm sure Sun would not object to distributions being called "GNU/OpenSolaris" :P
GPLv3 Solaris?!?!? Posted Oct 24, 2006 7:37 UTC (Tue) by khim (subscriber, #9252) [Link] Actually it makes perfect sense. Exactly because linux kernel developers don't like GPLv3! If Sun will do this then for any casual observer (who knows nothing about difference between GPLv2 and GPLv3 but knows how to read and so knows that GPL always recommended "GPL X.X or any later version" - Sun can helpfully point any observer to that phrase in any case) it'll look like linux developers rejected Sun's contribution, few developers who prefer GPLv3 (I'm not sure how many are out there but I'm pretty sure while it's not majority it's non-negligible number as well) will have something to play with (while HURD is still the pipedream) and they will have the means to merge with Debian... And Solaris will not be usable for embedded market any time soon - so there are not a much to lose. So while I do not think it'll happen soon (Sun is slooow) - it can happen.
GPLv3 is designed to ensure the software user's freedom Posted Oct 24, 2006 12:16 UTC (Tue) by bignose (subscriber, #40) [Link] > The problem is that, if a hardware manufacturer creates a hardware> platform that will only run signed binaries, the GPLv3 requires the > manufacturer to give away his private keys.
In the case where the vendor chooses to distribute code they received under GPLv3, yes. This is an explicit feature of the (still-in-development) GPLv3, not a problem.
> This greatly limits the places where GPLv3 code may run, effectively
Not at all. Any of those devices can contain code under GPLv3. They just can't prevent the user from having all the freedoms the vendor received in the GPLv3 code. This may make the DRM pointless, but since DRM is antithetical to user freedoms, that should be welcome.
The big lie keeps getting repeated: that somehow DRM is inevitable and necessary. It's not at all necessary, and it's not inevitable; the devices are defective by design, and GPLv3 is a way for people to ensure their code doesn't rob users of freedom. Just like the spirit of the preceding versions of the GPL.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 0:15 UTC (Wed) by bojan (subscriber, #14302) [Link] > The big lie keeps getting repeated: that somehow DRM is inevitable and necessary. It's not at all necessary, and it's not inevitable; the devices are defective by design, and GPLv3 is a way for people to ensure their code doesn't rob users of freedom. Just like the spirit of the preceding versions of the GPL.
OK, so devices are defective by design. Who's going to order more of these devices to be made (since these are defective)? Service and content providers. You think they will care about users' freedom or their profits more? DMCA and similar legislation explicitly allows them to do all this. You reckon they will just say "pass" because they value our freedom more?
If the signed GPLv2 software that runs on those devices with DRM hardware was to be relicensed today to GPLv3, the end result would not be more freedom to the users in the form of GPLv3 software running on these devices, but replacement of GPLv2 software on them with proprietary software. I would like to believe that somehow GPLv3 is going make the world better and force content and service providers into obedience, but that's simply naive.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 1:11 UTC (Wed) by bignose (subscriber, #40) [Link] > You think [vendors who design malfunctioning devices to restrict user's freedoms] will care about users' freedom or their profits more? DMCA and similar legislation explicitly allows them to do all this. You reckon they will just say "pass" because they value our freedom more?
I think the GPLv3 is designed to give free software developers an option for licensing their work such that it cannot be abused this way.
> I would like to believe that somehow GPLv3 is going make the world better
I can be more specific about the "somehow". It's exactly the same way as the GPL has always done: allow work to be released as free software so that a compelling body of work is licensed in a way that preserves user's freedoms.
> and force content and service providers into obedience, but that's simply naive.
The license can't force anyone to do anything; it grants them more options than they would have in the absence of the license. Whether they choose to exercise those options is their choice.
The GPL, as a copyleft license, is designed to make the choice to preserve user freedoms more attractive, by having desirable works licensed such that those freedoms cannot be restricted to recipients of the work. It can't force anyone to do anything that isn't already forced by copyright law.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 1:48 UTC (Wed) by bojan (subscriber, #14302) [Link] > The license can't force anyone to do anything; it grants them more options than they would have in the absence of the license. Whether they choose to exercise those options is their choice.
Aha, my point exactly. If Linux went GPLv3 today, Tivo wouldn't ship it any more, as it would violate their contracts with content providers. They would exercise that choice faster than you could say "no DRM".
So, your original "Not at all" to bronson's point that GPLv3 rules out running such software on TC (i.e. DRM enabled) hardware is obviously not true. A theoretical possibility of someone doing something silly (like shipping supposedly secret keys to everyone) doesn't make it any closer to being reality. People just won't do it, as long as practical and legal surrounding allow them to do something that can earn them more money.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 1:58 UTC (Wed) by bignose (subscriber, #40) [Link] > If Linux went GPLv3 today, Tivo wouldn't ship it any more, as it would violate their contracts with content providers. They would exercise that choice faster than you could say "no DRM".
Fine. Note, though, that it's *their choice* to do this.
> So, your original "Not at all" to bronson's point that GPLv3 rules out running such software on TC (i.e. DRM enabled) hardware is obviously not true.
In that scenario, the GPLv3 isn't stopping them from shipping the software on that hardware: it provides an explicit permission to do so, so long as they permit their users to exercise the same freedoms they received in the work.
That they don't *like* the terms, or that it might violate an agreement with some other party to restrict users's freedoms, is a problem of their own making, not of the GPLv3.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 3:49 UTC (Wed) by bojan (subscriber, #14302) [Link] > That they don't *like* the terms, or that it might violate an agreement with some other party to restrict users's freedoms, is a problem of their own making, not of the GPLv3.
And the only thing that GPLv3 licensing of Linux in Tivo's scenario would achieve, would be to take Tivo developers out of the free software community. The end users would end up with less freedom, as they wouldn't even be able to get Tivo's source and run it on their own boxes (let alone start a business based on that source), as all devices would simply ship with proprietary software. Ditto mobile phones and other similar devices. Now that would be the problem of GPLv3 making, for sure.
And that is, I guess, what kernel developers don't want to happen. They see their hard working colleagues making a living out of GPLv2 piece of software and at the same time contributing all of it back, only to be expelled from the community by something that's completely beyond their control (Hollywood's push to DRM hardware).
If hardware manufacturers decide that it is of benefit to them to ship dual-mode hardware (i.e. where TC can be turned off, overridden etc.) for the tinkering effect, they'll do it regardless of GPLv3 (remember, many smaller proprietary software makers, with no access to keys, may need to tinker too). And that's because those GPLv3 binaries, signed by practically public keys, will be just the same as any old untrusted software running on the platform (i.e. gotten from somewhere without any keys).
Bottom line: GPLv3 will probably have close to zero effect in stopping TC (i.e. DRM hardware). Nobody (or close to it) will be able to exercise any of those GPLv3 freedoms on DRM enabled hardware anyway, because nobody (or close to it) is going to ship GPLv3 code with keys attached.
Why bother at all?
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 14:07 UTC (Wed) by bignose (subscriber, #40) [Link] > the only thing that GPLv3 licensing of Linux in Tivo's scenario would achieve,
I'm not sure where you got your crystal ball, to predict all possible outcomes.
> would be to take Tivo developers out of the free software community.
Tivo already removed those developers from the free software community, by releasing a device that subverts the freedoms of the recipient. That's completely against the spirit of the GPL, even version 2, so GPLv3 is being written to help avoid that outcome in future.
> Bottom line: GPLv3 will probably have close to zero effect in stopping TC (i.e. DRM hardware).
Nothing can be done about software already released under terms that don't prevent this abuse. What can be done is to create a body of software that can't be subverted in this manner, to ensure that those who do respect freedoms in software can protect them in their future works.
Very similar to how a body of software was created and licensed under terms designed to avoid the freedom restrictions of proprietary software. The naysayers insisted that would never be worthwhile, either.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 21:22 UTC (Wed) by bojan (subscriber, #14302) [Link] > Tivo already removed those developers from the free software community, by releasing a device that subverts the freedoms of the recipient.
So, you remove all Tivo patches from Linux before you compile and run it, right?
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 23:37 UTC (Wed) by bignose (subscriber, #40) [Link] > So, you remove all Tivo patches from Linux before you compile and run it, right?
Non sequitur. We're talking about preventing abuse of GPL software in the future.
GPLv3 is designed to ensure the software user's freedom Posted Oct 25, 2006 23:54 UTC (Wed) by bojan (subscriber, #14302) [Link] Yeah, so much for the "GPL spirit"... How very convenient.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 0:25 UTC (Thu) by bignose (subscriber, #40) [Link] You've lost me.
We've been discussing how the GPLv3 is an attempt to address problems found with the existing GPLv2. One of those problems, we both seem to agree, is the potential to revoke freedoms that the GPL tries to guarantee for recipients of the work.
The existing code isn't the problem; the GPLv2 still does what it does. The problem is the distribution of that code to recipients in such a way that they can't exercise the freedoms enjoyed by the distributor. The GPLv3 is being designed to guarantee that can't happen.
Then you suddenly talk about removing code outside that context. That's a non sequitur. In the absence of anything new, I'm getting weary of this exchange.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 1:21 UTC (Thu) by bojan (subscriber, #14302) [Link] > You've lost me.
You mentioned the "GPL spirit", according to which, Tivo are in violation (of whatever that may be). Since you seem to be so keen on it (the spirit), why not live by your own principles now, instead of waiting until a GPLv3 licensed kernel is released? Wouldn't that be a moral thing to do? You may sense a bit of sarcasm there - it's not unintentional. And yes, this part is all rhetorical.
As for "getting weary of this exchange", that would be because you think that I have some kind of "crystal ball" of predicting outcomes. I do not. Instead, I try to present the arguments that would seem logical (at least to me):
- GPLv3 requires that keys be distributed with software (fact)
- device manufacturers, content and service providers find locked devices useful, therefore they will keep manufactuing them (fact)
- device manufacturers find free software option useful, as it reduces the cost of manufacturing the device (fact)
- giving keys away would make the devices unlocked again (fact)
- therefore, not many are going to have a locked yet unlocked devices, as it would be just silly (my conclusion)
- therefore, not many are going to get a chance to exercise GPLv3 freedoms on any of those devices, because not many are going to ship that combination of hardware/software (my conclusion)
- therefore, attempts to increase freedom through the use of GPLv3, would only have the effect of reducing the free software developer community, by forcing many embedded developers into proprietary software (my conclusion)
- by not introducing the anti-DRM clauses into GPLv3, people would at least have a chance to get the source for use on other devices or to start their own free software based business, while increasing free software licence compatiblity and therefore bringing more free software communites together (my conclusion)
You seem to be talking about some kind of theoretical possibility that GPLv3 will bring more freedom to users, without pointing to any real world mechanisms or forces that would make that happen. What good is this theoretical freedom, when nobody is going to write software to take advantage of it? How are users going to enjoy more freedom by not running free software?
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 1:50 UTC (Thu) by bignose (subscriber, #40) [Link] > GPLv3 requires that keys be distributed with software
Or that no keys be required at all.
> device manufacturers, content and service providers find locked devices useful, therefore they will keep manufactuing them
The "therefore" is true only to the extent that it continues to be profitable to do so. DRM is gaining widespread dissatisfaction as its ramifications become known. I find the idea that such devices are inevitably going to become ubiquitous to be a very defeatist position.
> device manufacturers find free software option useful, as it reduces the cost of manufacturing the device
This is completely at odds with restricting the freedoms of the recipient. If you mean "device manufacturers find zero-cost software [...] useful", that's irrelevant here.
> therefore, not many are going to get a chance to exercise GPLv3 freedoms on any of those devices
That's true under *any* free software license. The devices you describe are explicitly designed to restrict the freedoms of the recipient, so that they cannot exercise the freedom to modify and run the software.
Since such distribution doesn't allow exercise of the freedoms in the GPL, the GPLv3 is being designed so that those who would distribute in that way can't pretend to offer those freedoms.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 2:20 UTC (Thu) by bojan (subscriber, #14302) [Link] > The "therefore" is true only to the extent that it continues to be profitable to do so.
Oh, you better believe that part. Content and service providers are making sure that's the case. Why do you think we have DMCA?
> DRM is gaining widespread dissatisfaction as its ramifications become known.
Widespread? Wouldn't be so sure about that. What seems widespread on LWN, may not be even known in the real world. I reckon upward of 90% of Tivo users neither know nor would care if they found out that their system has DRM enabled hardware. And I think I'm being generous to the people that know and care here.
> This is completely at odds with restricting the freedoms of the recipient. If you mean "device manufacturers find zero-cost software [...] useful", that's irrelevant here.
No, I mean free software. Especially copyleft free software, as they can enjoy the benefits of sharing the development cost with other companies (i.e. other members of the community). Or are we saying now the GPLv2 software is not copyleft free software, because GPLv2 is violating the spirit of GPL (the mind boggles :-)? I certainly hope not.
> That's true under *any* free software license. The devices you describe are explicitly designed to restrict the freedoms of the recipient, so that they cannot exercise the freedom to modify and run the software.
My point exactly. So, the devices are the problem here - and one that GPLv3 isn't going to solve. At least with GPLv2 you get to have developers that keep hacking the software (therefore making it relevant) and let other people have access to such source (to run on other devices). With GPLv3, however, those communities die and the software soon becomes irrelevant in that area.
Which gives? Less free software, not more. Surely, less free software is not better than more free software. Except, of course, if GPLv2 software doesn't count as free software any more.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 2:35 UTC (Thu) by bignose (subscriber, #40) [Link] > > The devices you describe are explicitly designed to restrict the freedoms of the recipient, so that they cannot exercise the freedom to modify and run the software.
> My point exactly. So, the devices are the problem here - and one that GPLv3 isn't going to solve.
No copyright license can solve that problem, and the GPLv3 isn't designed to do so.
The problem GPLv3 is addressing, in this case, is the unwilling contribution by free software developers to explicitly non-free distribution.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 2:44 UTC (Thu) by bojan (subscriber, #14302) [Link] > The problem GPLv3 is addressing, in this case, is the unwilling contribution by free software developers to explicitly non-free distribution.
A noble goal, for sure (I'm not being sarcastic here, I promise).
However, in the case of Linux (or other similar software) this would have a side effect of killing the development efforts of many of those developers. So, instead of just killing "non-free distribution", communities and a lot of contributions useful elsewhere would be killed with it as well. All of which is just collateral damage to FSF, I guess.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 2:54 UTC (Thu) by bignose (subscriber, #40) [Link] > this would have a side effect of killing the development efforts of many of those developers. So, instead of just killing "non-free distribution", communities and a lot of contributions useful elsewhere would be killed with it as well.
I guess our crystal balls must be tuned to different futures. I plan to keep working toward the future I see in mine.
Thanks for the discussion, I'm stopping here.
GPLv3 is designed to ensure the software user's freedom Posted Oct 26, 2006 3:00 UTC (Thu) by bojan (subscriber, #14302) [Link] > Thanks for the discussion, I'm stopping here.
Thanks for your time. I enjoyed the discussion.
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 15:56 UTC (Thu) by lysse (guest, #3190) [Link] > The problem is that, if a hardware manufacturer creates a hardware platform that will only run signed binaries, the GPLv3 requires the manufacturer to give away his private keys.
Does it, though? or does it merely require that the manufacturer provide some means of ensuring that the user can run a binary they compile? The two requirements are not identical, after all.
For example, a manufacturer could provide a GPL'd program, running under Linux, that sends a specific request to the device (via USB, Bluetooth, whatever) and causes the device to yield a key which can be used to sign a binary that will run on that device (and only that device). The manufacturer could make that part of the GPLv3 source distribution that it is required to provide.
Is that permissible under the GPLv3? If not, could the GPLv3 be reworded so that it is? And would that satisfy the objections?
Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) Posted Oct 26, 2006 20:37 UTC (Thu) by bojan (subscriber, #14302) [Link] > For example, a manufacturer could provide a GPL'd program, running under Linux, that sends a specific request to the device (via USB, Bluetooth, whatever) and causes the device to yield a key which can be used to sign a binary that will run on that device (and only that device). The manufacturer could make that part of the GPLv3 source distribution that it is required to provide.
This is just about the same - the user is put in the position of trust. They don't want that - they want to trust only the device. I know, that's really bad and all, but that's what TC is all about.
|
|
||||||||||||