Linux: GPLv3, DRM, and Exceptions (KernelTrap.org) [LWN.net]

Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)

Posted Oct 22, 2006 20:39 UTC (Sun) by man_ls (subscriber, #15091) [Link]

I think we can drop the ROM idea now.

As has been pointed out elsewhere, ROM doesn't mean literally "a ROM chip with the technology used on 8-bit computers". Technologies change fast. Don't take it literally; the important issue is to have some kind of permanent memory which cannot be modified. It might be flash memory without a programmable interface, a PROM, or whatever technology is used ATM. Just making the memory non-updateable from software might protect against casual attackers and work in most situations.

Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)

Posted Oct 22, 2006 23:32 UTC (Sun) by bojan (subscriber, #14302) [Link]

> 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.

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.

Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)

Posted Oct 26, 2006 14:12 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Just making the memory non-updateable from software might protect against casual attackers and work in most situations.

You mean, like, signing the contents and refusing to run if the signature isn't right?

Linux: GPLv3, DRM, and Exceptions (KernelTrap.org)

Posted Oct 22, 2006 23:57 UTC (Sun) by bronson (subscriber, #4806) [Link]

"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.

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:
- it will depend on a single critical top-sekret key
- it can't differentiate access levels
- it can't differentiate between components
- it's unable to print the simple warnings that would make the manufacturer legally safe against user performs an unsupported update
- etc, etc

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 :
- integrate several products (several keys)
- handle migration when a corp is bought by another one (oh no 2 keys!)
- handle certificate expiry (need to update keys!)
- protect against leaked keys (need to replace keys!)
and so on,

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 :
1. the key allowed to update the embedded browser is not the one allowed to authorise media or update the ehternet firmware or whatever and
2. each device has a unique owner key, so publishing it only "compromises" one system

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
to any version of the Stanford Checker?

The GPLv2 was written to ensure the freedom of *users* of GPL-licenced
software. Not to enforce or encourage reciprocal gifts from and to
developers of the software.

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
address it to some extent.

> It has nothing to do with DRM, of course.

Sorry, I should have edited the subject line. I was addressing the claim
above (expressed also by Linus Torvalds on Groklaw) that people who
improve GPLv2 software are somehow obliged to contribute their
improvements "back", presumably meaning upstream. No such obligation
exists with any version of the GPL -- the obligation is to *users*, not
the original developers.

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 a modified version of the material they cover is a work intended to interact with users through a computer network, that those users be able to obtain copies of the Corresponding Source of the work through the same network session;

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
highly unlikely scenario comes to pass.

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
> ruling out running GPLv3 code on modern set-top boxes, mobile phone
> handsets, automatic teller machines, voting machines, etc.

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.