Re: the beef [LWN.net]

Re: the beef

Posted Oct 2, 2006 23:10 UTC (Mon) by mingo (subscriber, #31122)
In reply to: the beef by coriordan
Parent article: Busy busy busybox

There are two motivations for singling out keys.

Thanks for acknowledging that the GPLv3 does single out keys to limit the use of GPL-ed code on certain hardware. The GPLv2 did not do that, the fundamental freedom to run code on any hardware is very much in the GPLv2. A change to that concept results in a license that is not "similar in spirit", at least to me (and this should answer your original question of why i think the GPLv3 is not similar in spirit to the GPLv2). The GPLv2 did not try to define "source code" in a nonsensical way.

The key in question, no matter how inconvenient to me as a developer, is a property of the hardware, not a property of software. It is a bad precedent (and morally questionable) to extend the reach of the license to hardware design details. I thought only Hollywood wants to do that ...

Where will we stop on this slippery slope of adding more and more restrictions to our license to remove inconveniences we meet during our everyday life? Will we require hardware makers to open up specifications in the future, via the license? Will we require hardware makers to contribute money to free software developers? Where will it stop? What is the moral line? So far you have not drawn any moral line into the sand. The GPLv2 was simple in that regard: it was about the source code and the ability to copy, run and modify code. (And no, "modify" did not include "modify in any way contemplated by the developer, on any hardware, and in a way convenient for the developer".)

(Log in to post comments)

Re: the beef

Posted Oct 3, 2006 1:03 UTC (Tue) by stevenj (subscriber, #421) [Link]

The GPLv2 did not do that, the fundamental freedom to run code on any hardware is very much in the GPLv2. A change to that concept results in a license that is not "similar in spirit"

As has been explained repeatedly, you have the freedom to run the code on any hardware you want. What you don't have is the freedom to distribute GPLv3'ed code as part of hardware that forbids the user to run modified versions.

Re: the beef

Posted Oct 3, 2006 4:42 UTC (Tue) by svkelley (guest, #37299) [Link]

This is absurd. One is now restricting use of hardware if I don't allow someone to hack the GPLv3 software on the device? Complying with providing the source code is not enough? I now must give one access to programming the hardware itself, if I can do the same in the field using my special loader?

Why?

So I have a portable electronic device that I manufacture and sell. I comply with all aspects of providing access to the source code and any and all mofidications. Yet, if I do not allow one to "hack" this device through either encryption, private key, signed loader -- I am now in violation?

In my opinion, that is the quickest way to kill commercial embedded Linux development.

Sean V. Kelley

Re: the beef

Posted Oct 3, 2006 6:30 UTC (Tue) by gmaxwell (subscriber, #30048) [Link]

If you don't want someone modifying a device... don't pass ownership on to them.

If you pass ownership on to someone else but then attempt to prevent them from modifying it, I wouldn't just call that a violation of the intent of the GPL... I'd call that fraud.

Re: the beef

Posted Oct 3, 2006 21:44 UTC (Tue) by sepreece (subscriber, #19270) [Link]

There are, of course, many devices in our lives whose manufacturers make it hard or impossible for us to modify them. That's not in any way fraud, so long as they made a good-faith effort to make sure the device does what it was sold to do.

Re: the beef

Posted Oct 3, 2006 22:36 UTC (Tue) by liljencrantz (subscriber, #28458) [Link]

If you pass ownership on to someone else but then attempt to prevent them from modifying it, I wouldn't just call that a violation of the intent of the GPL... I'd call that fraud.

By your reasoning, credit card companies are comitting fraud by not letting you easily change the identification on credit cards to match those of Bill Gates.

Re: the beef

Posted Oct 3, 2006 14:47 UTC (Tue) by mingo (subscriber, #31122) [Link]

This is absurd.

yes, it is.

In my opinion, that is the quickest way to kill commercial embedded Linux development.

If the kernel moved to the GPLv3, it would be, yes. Given that the kernel is the closest to the hardware, we kernel developers will be the first ones to see the bad effects of any bad construct within the GPLv3 affecting hardware. That is i think partly the reason why the growing resistance against the GPLv3 comes from the kernel community.

And even if the GPLv3 does not yet limit wide aspects of the hardware (only certain types of keys are included for the moment), a dangerous precedent is set and the possibilities for excuses to widen the definition of "Source Code" are unlimited.

The GPLv3 in this point significantly departs from the spirit of the GPLv2, which explicitly grants the freedom of unlimited end-use and the freedom of not having GPL-ed code control works (such as hardware) independent of that GPL-ed code. Even if that end-use or hardware is highly inconvenient (and thus makes the modification of software harder) for certain classes of developers: it is an atomic bomb, a landmine or a Tivo.

Re: the beef

Posted Oct 4, 2006 9:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

> This is absurd. One is now restricting use of hardware if I don't allow
> someone to hack the GPLv3 software on the device

In case you didn't notice the GPL was always about passing "permission to hack" downstream (unless hacking was materially impossible, such as a ROM but DRM is not a ROM - if it were you couldn't hack the device either).

What's absurd is people having chosen to forgot this basic, if inconvenient fact.

The DRM=ROM argument is stupid - if DRM=ROM just use ROM and be done with it. Neither the GPLv2 nor the GPLv3 forbids it. That people beg for being allowed to use DRM instead of ROM clearly shows they are different.

Re: the beef

Posted Oct 4, 2006 13:59 UTC (Wed) by sepreece (subscriber, #19270) [Link]

Of course ROM and DRM are different. The question is whether they are difference is qualitative or quantitative. The intended end result, from the device distributor's point of view, is the same: the end user can't change the software in the device so that it does things other than what it is supposed to do.

The FSF is arguing that the difference is qualitative, and has created the "you must pass along the same rights you have"[*] argument to support that point. Nothing in the four freedoms provides a base for such an argument, but, hey, they're reasonably inventive people.

The device distributors would argue that the difference is quantitative; that preserving the ability to repair devices lowers the lifecycle cost of the device. If they had to budget for recalls to replace devices when software defects were discovered in the field, they would have to charge more for the devices to get the same profit margin.

Yes, the device distributors want to have a right on the device that the end user does not have, as a condition of using the device with their service. Some of us honestly don't have any problems with that; the FSF obviously does. That's fine - I just wish they would assert their conviction that an additional freedom is required, rather than rationalizing.

--
[*] Actually, of course, it's a subset of the rights you have - just the ones covered by the license. Also, they usually ignore the fact that in typical cases (like Tivo and cellphones), the device distributor actually asserts rather more rights over the device than are consistent with a simple transfer of ownership to the end user; they usually claim most of the rights to administer the device, at least when it's used with their service.

Re: the beef

Posted Oct 4, 2006 19:35 UTC (Wed) by nim-nim (subscriber, #34454) [Link]

> The intended end result, from the device distributor's point of view, is
> the same: the end user can't change the software in the device so that it
> does things other than what it is supposed to do.

What they actually care about is the device behaviour, and it's not even an absolute requirement, or they'd be selling welded steel enclosures not cheap plastic ones anyone can open to install mod-chips.

The intended end result is to make the device somewhat harder to modify as long as it does not cost too much. Shock! DRM is only about saving a few bucks! One could easily argue the costs of having to forgo DRM are largely couterbalanced by free access to the GPL software pool.

> preserving the ability to repair devices lowers the lifecycle cost of the
> device

Nothing forbids repairing devices in a GPLv3 world. It only forbids repair accesses closed to the device owner. That screwdrivers are widely available never stopped an appliance manufacturer from using standard screws, precisely because lowering lifecycle costs has priority over keeping the owner out at all costs.

> Yes, the device distributors want to have a right on the device that the
> end user does not have, as a condition of using the device with their
> service.

This argument does not stand:

1. many of the DRM-ed devices are intended for standalone use (media players...) with the service part completely absent or optional

2. if it's really a condition of using the service then there is something called "terms of service" for this, and it's not even deprecated by DRM, since many terms can not be DRM-enforced.

If the device is sold to the user what he does with it is none of the service provider business as long as it does not impact the service infrastructure (if it does impact the service infrastructure you can detect it infrastructure-side without device-level DRMs)

If the service absolutely depends on total control on the appliance there's a well known solution: providing the device free of charge to the user, and recouping costs with the service fee.

Of course some businesses want to sell appliances without passing control to the user, have customers provide seed money for services by paying for the required appliances beforehand, benefit from GPL code without allowing the tinkering conterpart the GPL was about and so on.

I want a pony too. Will I get one?

Re: the beef

Posted Oct 7, 2006 1:38 UTC (Sat) by vonbrand (subscriber, #4458) [Link]

The intended end result is to make the device somewhat harder to modify as long as it does not cost too much. Shock! DRM is only about saving a few bucks! One could easily argue the costs of having to forgo DRM are largely couterbalanced by free access to the GPL software pool.

One could also easily argue that the costs of other software alternatives is not significantly higher, and moreover the GPLv3 (and possibly even more agressive GPLv4 to follow, and...) creates a high potential liability cost ("But, yerhonnor, we used GPLv3ed code because it was cheaper, and the plaintif modified said code and our so modified device cut off her feet" can very easily be answered by "Then it was reckless design to leave it open to modification").

Nothing forbids repairing devices in a GPLv3 world. It only forbids repair accesses closed to the device owner. That screwdrivers are widely available never stopped an appliance manufacturer from using standard screws, precisely because lowering lifecycle costs has priority over keeping the owner out at all costs.

You'd be surprised then by the strange screws I've had to deal with... plus swabs of paint over screws, etc. Point of most of them was clearly making it harder to get inside, or making modifications visually obvious to whoever is handling the device. What if the "handling" of the device is remotely, over a network?

Re: the beef

Posted Oct 7, 2006 12:44 UTC (Sat) by nim-nim (subscriber, #34454) [Link]

> "But, yerhonnor, we used GPLv3ed code because it was cheaper, and the
> plaintif modified said code and our so modified device cut off her feet"
> can very easily be answered by "Then it was reckless design to leave it
> open to modification"

But was the reckless design to use GPLv3 or DRM instead of ROM? If you have this kind of liability hanging over your head, you can certainly afford ROM, or protected hardware jumper, or whatever

Re: the beef

Posted Oct 8, 2006 1:44 UTC (Sun) by sepreece (subscriber, #19270) [Link]

If the TC is good enough, there's no need to go to ROM. As noted elsewhere, there are disadvantages to using ROM. And it's usually sufficient to make it difficult to modify, so the user clearly has to jump over intended barriers (and thereby demonstrate that it's their fault, and not the manufacturers).

I'm neither a lawyer nor on the business side; I don't know what factors they use in deciding how hard to make it to crack the security.

Re: the beef

Posted Oct 8, 2006 9:12 UTC (Sun) by nim-nim (subscriber, #34454) [Link]

> As noted elsewhere, there are disadvantages to using ROM.

But are the disadvantages sufficient to refuse using GPLv3 software if it implies ROM?

> And it's usually sufficient to make it difficult to modify, so the user
> clearly has to jump over intended barriers (and thereby demonstrate that
> it's their fault, and not the manufacturers).

This part is easily done without blocking GPLv3 by making the update process interactive and spewing big red warnings if the updating binary is not signed by the manufacturer

Re: the beef

Posted Oct 3, 2006 15:16 UTC (Tue) by mingo (subscriber, #31122) [Link]

Firstly, the GPLv2 did not try to control works independently created of the works we created. I'm curious about the basis for your claim that it is "similar in spirit" for the GPLv3 to suddenly break this promise by trying to control hardware that includes no GPL-ed code at all (and is hence outside of the 'moral scope' of our license) - just because it's distributed together with GPL-ed code.

Secondly, does your interpretation also mean that, by recursion, in future versions of the GPL we should brace ourselves for the prohibition of the distribution of GPL-ed code on the same hardware that also contains non-GPL code? (for example closed-source code?) Because controlling that is within the exclusive rights of the copyright holder too, and by your argument it's fine to do it, as long as it makes the modification of the system more convenient?

Thirdly, the mechanism you (and the GPLv3) are proposing breaks a fundamental symmetry of the GPLv2: that if end-use and distribution together with certain independent works by one person is allowed, the same end-use and distribution with other independent works is allowed for another person too.

Let me give you an example: lets suppose i take the binary packages of the Tivo and run it on my PC. The only GPL-ed code on that system will be those binary packages. I can run it on my PC, and i can distribute that PC. But if someone else puts those very same unmodified packages on a Tivo, he would not be able to distribute that system. Nothing else on either the PC or on the Tivo is GPL-ed - only those binary packages. The code that is used is totally the same in both cases, and the hardware (and other software) is neither a modification or a derivative of any GPL-ed code. But the GPLv3 forbids the distribution of the Tivo system!

Fourthly, as the above example I gave to you, the practical effect of the prohibition of distribution of certain combinations of unmodified GPL-ed works with other, independent works simply punishes certain types of end-uses, and hence limits those end-uses. Legally it might not be an end-user limitation (because hey, in theory everyone has the ability to build a Tivo from scratch in private, right?), but the end-effect is still very much the same.