| |||||||||||||
the beefthe beefPosted Oct 2, 2006 22:34 UTC (Mon) by coriordan (guest, #7544)In reply to: Licence text and fabs by mingo Parent article: Busy busy busybox
Thanks for your reply. why does it single out keys from the myriads of existing ways of restricting hardware capabilities There are two motivations for singling out keys. One is that rigging hardware to require a key, and then distributing the hardware without the key, is something that is currently being done, and is even supporting a business model. It is practical and profitable. A second is that closing this loophole is simple and can be done in a way that only restricts the handful of people who are pushing things through that loophole. There will always be other loopholes, but maybe no one (or nearly no one) will exploit them because they are difficult, or impractical, or unprofitable. Burning software onto ROMs or locking the harddrive in a safe are indeed effective ways to prevent people being free to modify the software. The reason those scenarios are not being adressed by GPLv3 is because the two motivations that exist for keys do not (currently) exist for physical lock-out. Physical lock-out is not in wide spread use, at least not for desktop computers (I'm open to correction on that point, but the next point is reason enough on its own). Phyical lock-out is not easy to fix - not without inconveniencing users or manufacturers. GPLv3 only influences hardware design in the rare case when the designer is looking for ways to prevent users from being able to tinker with the software. Less tinkering means less contributors. We don't gain from helping people who are trying to prohibit tinkering. About talking to FSF, the best way to do this is through the commenting system. Just go to your sent emails folder, copy the text that explains your issue, and paste it into the dialogue box on gplv3.fsf.org/comments after selecting that sentence about keys. If you do this, your comment will be viewable by the public, other commenters will be able to comment on it or note that they agree with it, and then your comment will go to the 130 people in the four discussion committees (business, lawyers, software projects, individuals). The committees can also do a better job than FSF can of responding to a large volume of input, and according to members of the committees, they are being listened to. As for purple, it doesn't scare me.
(Log in to post comments)
Re: the beef Posted Oct 2, 2006 23:10 UTC (Mon) by mingo (subscriber, #31122) [Link] 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".)
Re: the beef Posted Oct 3, 2006 1:03 UTC (Tue) by stevenj (guest, #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 (guest, #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.
--
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
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
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
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] 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. 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.
Re: the beef Posted Oct 2, 2006 23:17 UTC (Mon) by mingo (subscriber, #31122) [Link] GPLv3 only influences hardware design in the rare case when the designer is looking for ways to prevent users from being able to tinker with the software. Less tinkering means less contributors. We don't gain from helping people who are trying to prohibit tinkering. Do you realize that the only effect this will have on hardware designers is not the removal of DRM but the removal of Linux? That is what reduces the number of contributors. There's no DRM in use (or planned) where it's Linux that people desire. The only DRM i can see is where there's some body of content owned by someone else, not us, which content people actually want: pay-per-view content on the Tivo, console games, DVDs, etc. So please give me a single example of current DRM use where it's not some other people's (valuable) content that is being restricted, but purely free content. So instead of growing the community, you are shrinking it. Furthermore, you are also isolating lots of users from being able to experience and understand the power of free software, because you are making it artificially harder for them to use the closed content they are interested in.
Re: the beef Posted Oct 3, 2006 1:09 UTC (Tue) by stevenj (guest, #421) [Link] Do you realize that the only effect this will have on hardware designers is not the removal of DRM but the removal of Linux? If the Linux kernel developers would prefer to subsidize DRM'ed hardware with their efforts, in order to gain more users and contributors at the expense of those users being about to modify the code, that is their choice. They can continue to use v2. (And anyway, it looks like they don't have much choice barring lengthy relicensing efforts.) This is no different from the fact that GPLv2 does not eliminate all proprietary software. If you want to maximize the number of users and contributors to your code, use BSD. Your double standard here is confusing.
Re: the beef Posted Oct 5, 2006 19:48 UTC (Thu) by AJWM (guest, #15888) [Link] > If you want to maximize the number of users and contributors to your code, use BSD.
Okay, I'll bite. How does the BSD maximize contributers?
|
|||||||||||||