Recent Features
| |||||||||||||
Licence text and fabsLicence text and fabsPosted Oct 2, 2006 20:23 UTC (Mon) by mingo (subscriber, #31122)In reply to: Licence text and fabs by coriordan Parent article: Busy busy busybox
It's difficult to respond to your statement that draft 2 of GPLv3 is not similar in spirit to GPLv3 when you don't reference the text to say how. I sent that feedback to the FSF some time ago. The final reply, after some discussion where i explained my points, was silence. So lets put the discussion out into the open, maybe that improves the quality of communications. For example, lets take the definition of Source Code from Section 1, gpl-draft-2006-07-27 (gplv3 second draft): The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. I understand that this is that drives the anti-Tivo push, but what do encryption keys have to do with source code? If a hardware maker decides to put a "virtual ROM" on his box and sell the hardware in such a restricted form so that it will only run kernels that match a certain hash (besides putting the hardware into a 10"x10" sealed, translucent plastic cube and painting it purple), what does the hash check in the hardware have to do with any source code? And if there is any connection, why dont we include "box that can be opened via a standard screwdriver, so that it can be modified without damaging it" into the definition of the source code? Why dont we include "and all specifications of the hardware have to be provided too, so that the modification of software can be performed without damaging the hardware"? Why dont we include "dont paint the box purple because that color scares away free software developers trying to modify the box!"? Why does the GPLv3 redefine source-code in such a way, why does it single out keys from the myriads of existing ways of restricting hardware capabilities, and where will that process stop? But most importantly, why does the GPLv3 get into the business of trying to dictate hardware design? The GPLv2 didnt do that. I hate the MPAA/RIAA's behavior as any other guy on lkml but still i dont get down to their deplorable tactics.
(Log in to post comments)
Licence text and fabs Posted Oct 2, 2006 22:21 UTC (Mon) by stevenj (guest, #421) [Link] If a hardware maker decides to put a "virtual ROM" on his box and sell the hardware in such a restricted form so that it will only run kernels that match a certain hash (besides putting the hardware into a 10"x10" sealed, translucent plastic cube and painting it purple), what does the hash check in the hardware have to do with any source code? That's a bad example, because that's not forbidden by the GPLv3. Making the hardware look at, say, the MD5 hash of the kernel before running it does not require any secret encryption keys. The basic principle is simple: if the hardware manufacturer can modify the software in the user's box (as opposed to building a new box), then the user should be able to also. This principle explains why the FSF didn't consider any of your other examples like forbidding boxes without screwdrivers (or boxes painted purple??), since in that case the hardware manufacturer can't do anything the user can't.
Licence text and fabs Posted Oct 2, 2006 23:38 UTC (Mon) by mingo (subscriber, #31122) [Link] That's a bad example, because that's not forbidden by the GPLv3. Making the hardware look at, say, the MD5 hash of the kernel before running it does not require any secret encryption keys. Firstly, i did not talk about an MD5 hash of the kernel. Secondly, read the GPLv3 draft again, it is not limited to "secret encryption keys" alone. See Section 1: The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. (emphasis added) Note the "encryption or authorization" language. It is not limited to encryption keys alone. Anyway, what does the "key" have to do in the definition of source code? By putting this into the Source Code definition, we are implicitly judging the act of "not sharing a key" immoral - because it's now judged to be an act of "not sharing the source code". (The GPLv3 does carve out a few exceptions in later sections, but the damage has already been done in this section.) As it has been acknowledged by another poster here who seems to be intimately familiar with the GPLv3 process, the goal of this definition is to dictate what the hardware does, to remove the inconvenience of certain types of hardware limitations. My observation is that the GPLv2 did not do this, never tried to do this, and that trying to control what hardware does is immoral. (and pointless btw., as i explained it in other replies in this thread.) What "inconvenience" will we try to remove via the license come GPLv4? Perhaps the inconvenience of not getting money in exchange of the nice free software we are writing?
Licence text and fabs Posted Oct 3, 2006 0:58 UTC (Tue) by stevenj (guest, #421) [Link] You're being deliberately obtuse to score cheap rhetorical points. You didn't specify an MD5 hash, but you specified a "hash" (no serious cryptographic hash requires a secret key) and, in any case, your example was a "virtual ROM". I explained how to create a virtual ROM without requiring secrets of any kind and in compliance with the draft GPLv3—no encryption or authorization "key" exists or is required, in the same way as for a physical ROM. The only problem comes if the manufacturer wants the ability to modify the software while denying this ability to users. My description of the rationale for restricting this and not ROMs being one of parity (between distributor and recipient) comes straight from Eben Moglen and RMS, not from hearsay, so Ciaran is mistaken in implying that distinction is merely "convenience": If Manufacturer A wants the software he sells in the hardware to stay one version forever, he has a simple way to do it: he can put the software in ROM. He has no power to modify it, and the user to whom he gives it has no power to modify it. That doesn't violate GPL version two and it doesn't violate GPL version three, in current draft. We will not publish a draft that would be violated by that conduct. What we object to is the attempt to say "I will keep the right to modify the software, but I won't allow you to have the same right of modification that retain" because that's simply a technical way of evading the requirement of the licence to pass along all the rights you got. The fact that you continually depart from the text of the draft license and ignore extensive evidence of the true rationale to conjure scare scenarios that don't exist does not inspire confidence in your analysis. And, by the way, your argument that it is "immoral" could equally well be applied (and has been applied, usually by BSD advocates) to GPLv3—this is the usual argument against "viral" clauses. The usual retort is that it is simply quid pro quo: if you want to distribute my code as a part of your software (or hardware), you need to satisfy my conditions. And the conditions of the GPL have always been aimed at the same thing: giving every user (whether the manufacturer or the end-user) the same ability to modify, run, and redistribute the code. You may disagree with this goal, but you have yet to provide any convincing argument that the GPLv3 departs from this spirit.
Licence text and fabs Posted Oct 3, 2006 14:13 UTC (Tue) by mingo (subscriber, #31122) [Link] The only problem comes if the manufacturer wants the ability to modify the software while denying this ability to users. So how does this differ from the situation of old-fashioned ROMs that contain GPL-ed code? Do you get an EEPROM burner with every toaster that includes a ROM? Do you get free training to be able to use that burner? If the write pins of the ROM were burned out, but it's still easily replaceable by the manufacturer, do you get free ROM chips to replace them with? If the ROM is in a disposable cartridge that has some weird physical form factor, do you get free access to the cartridge manufacturing process, to be able to "modify" the ROM and produce new cartridges? You dont, and it would be unreasonable to require that in a free software license. And the same is true for a "virtual ROM", which is easily upgradeable for the manufacturer but hard to upgrade for others. What this new language in the GPLv3 does is what the GPL never did and never purported to do: it limits the ability of end users to use GPL-ed code. Yes, hardware makers are end users too, and the new GPLv3 language limits their end-use. This sets a far more dangerous precedent than any supposed dangers of the harder-to-tweak nature of the Tivo brings with itself. It shows to new contributors that our prior words cannot be trusted. The GPLv2 clearly says: end use is not limited in any way, shape or form. Now the GPLv3 tries to limit the ways in how hardware makers can use our binaries. That is an unacceptable change of the bargain to me. I dont care how inconvenient the Tivo is to us, we have no moral grounds to limit end-users. This was clear in the GPLv2. In what way will you change the bargain next time around? Ask for samples of free hardware perhaps to make modification easier? Ask for specs and training and access to personell to make modification more convenient? Or, to make it really convenient for all of us, do you plan on asking for money in exchange of them being able to use all this wonderful free software? It would of course be "similar in spirit" to previous versions of the GPL, because without money to live how can anyone do the modifications to begin with? The 4 freedoms would be toothless if developers werent reimbursed for their efforts, right? And no GPLv3-proponent so far was willing to answer this simple point: where is the moral line? Now that the GPLv3 starts limiting end-use, where will that limitation stop? And as i said it before: there will always be freeloaders that only use our works and dont give back. /We cannot force them to give back/. Still the community and our users are giving back /a lot more/ than what the text of the license requires - because what drives this whole thing is not your paranoia to punish freeloaders, but the basic mechanism of getting modified source code back. Your vendetta against DRM will only turn away new contributors (and old contributors) alike. It already caused real damage within the community. (read the article you are commenting on.)
Licence text and fabs Posted Oct 3, 2006 18:57 UTC (Tue) by walken (subscriber, #7089) [Link] > Yes, hardware makers are end users too
No they are not - not under any common definition of "end user".
Someone who's a distributor is not an end user - the product does not *end* up there, it gets *distributed* instead.
I'm sorry but you're twisting words again.
Licence text and fabs Posted Oct 4, 2006 2:40 UTC (Wed) by sanjoy (subscriber, #5026) [Link] the GPLv3 tries to limit the ways in how hardware makers can use our binaries. That is an unacceptable change of the bargain to me. It might unacceptable if it were such a limit. However, there is not, despite many claims to the contrary. Use, in common parlance and in copyright law, means running the program. Under the GPLv3, hardware makers may freely run the program for any purpose. For example, they may and probably do run it to test whether it recognizes all the hardware or does not crash when given random input. They may even find solutions to any crashes, modify the program, and run the modified version (so long as they don't violate the patent-retaliation clause). There is no restriction on use. Recipients of such hardware are also free to use (run) the program, as they do every time they turn on the device. No restriction on use there either. The only restriction is on distribution, which copyleft licenses by definition restrict. If the manufacturer distributes the program, perhaps embedded in a device, the manufacturer must give you the source code so that you can modify it; and under the GPLv3 the source code also includes the manufacturer's magic key so that you can install your modification. This requirement is a restriction on distribution: "You may distribute provided that you do XYZ." It is not a use restriction. In what way will you change the bargain next time around? This question is based on the incorrect premise that the bargain changed. With the GPLv3 as with the GPLv2: You may use the software for whatever purpose you want, modify it even, but if you distribute it (perhaps modified), you must give others the same rights. --Sanjoy Mahajan
Licence text and fabs Posted Oct 6, 2006 21:51 UTC (Fri) by petetron (guest, #8495) [Link] So how does this differ from the situation of old-fashioned ROMs that contain GPL-ed code? Do you get an EEPROM burner with every toaster that includes a ROM? Do you get free training to be able to use that burner? If the write pins of the ROM were burned out, but it's still easily replaceable by the manufacturer, do you get free ROM chips to replace them with? If the ROM is in a disposable cartridge that has some weird physical form factor, do you get free access to the cartridge manufacturing process, to be able to "modify" the ROM and produce new cartridges? You are being obtuse. In the case of something like Tivo, the company can push new software updates to the device over the internet without the consent of the user. As another example, if a device is tied to a particular service, the company could compel the user to upgrade the firmware by making the service incompatible with older versions. In either case where GPL software is involved, the user should have the choice as to whether to accept the new version of the software, and if not, to still be able to use the hardware they BOUGHT and PAID FOR in the way they see fit (by patching the GPL'd code). That requires being able to change the source code. If you distribute GPL software in ROM, you still need to distribute the source code. That's just as much the case with the GPLv2 now as it would be with GPLv3. However, unless the company sends men in black to your house to replace the ROM chip in the dead of night, with ROM there simply doesn't exist the same ability to force unwelcome upgrades on your device. That's a key difference and why your argument about EEPROM is absurd. What this new language in the GPLv3 does is what the GPL never did and never purported to do: it limits the ability of end users to use GPL-ed code. What are you talking about? In the most literal sense, requiring people redistribute source code is a limitation on their rights to keep their modifications to the code hidden. But it is through this mechanism that the essential goal of the GPL is asserted, which is that software which is placed under the GPL remains free to be used, modified and redistributed by anyone. And as i said it before: there will always be freeloaders that only use our works and dont give back. /We cannot force them to give back/. But we can force them to give it back, that is where copyright and contract law comes into play enforcing the text of the GPL. It is evident that you completely misunderstand the legal and social contracts that the GPL is built on. Perhaps you read the BSD license and are just confused?
Licence text and fabs Posted Oct 3, 2006 14:33 UTC (Tue) by mingo (subscriber, #31122) [Link] And, by the way, your argument that it is "immoral" could equally well be applied (and has been applied, usually by BSD advocates) to GPLv3this is the usual argument against "viral" clauses. The usual retort is that it is simply quid pro quo: if you want to distribute my code as a part of your software (or hardware), you need to satisfy my conditions. You are materially misrepresenting the "Quid Pro Quo" that existed in the GPLv2, and you have inserted a condition (see the word in bold above) that was never there. Using our license to affect works independent of our work (such as hardware) was never part of the Quid Pro Quo deal. If my software is distributed with works that are independent of my software, i have no moral right to limit that distribution. (Yes, we have the legal power to do so, but there are a lot of things that are legally allowed but still immoral.) Look at the "merge aggregation" language in the GPLv2. This whole attempt to control other works is hidden in Section 1 of the second draft of the GPLv3, by the inclusion of "keys" into the Source Code definition: The Corresponding Source also includes any encryption or authorization keys necessary to install and/or execute modified versions from source code in the recommended or principal context of use, such that they can implement all the same functionality in the same range of circumstances. This definition brings keys, which are otherwise part of another work (the hardware) into the scope of our "source code", and hence forces their release. What will we put into the definition of "Source Code" in GPLv4? Perhaps "all design documents of the hardware and 10 free samples of the hardware, so that the documentation can be used in a meaningful way to modify the software in its principal context of use"? Please answer me a simple question: what moral rights do we have to control works independent of ours, and where does the GPLv2 do the same thing, if your argument is that it already did that? The Tivo hardware is not a modification and not derived from any GPL-ed code. In simple terms: the GPLv3 goes from the previous "Quid Pro Quo" to "eye for eye", and it is utilizing tools that limit fundamental freedoms (such as unlimited end-use and the independence of works independent from our works) that the GPLv2 explicitly granted in an unlimited way. Do you now understand why the GPLv3 is not similar in spirit to the GPLv2?
Licence text and fabs Posted Oct 3, 2006 15:23 UTC (Tue) by stijn (subscriber, #570) [Link] I do not think the GPL mentions 'quid pro quo' or 'tit for tat' anywhere.It may very well be what *you* like about the GPL, but the GPL is concerned with the four freedoms. In this respect you seem to be trying to make the GPL be something it never was.
In earlier threads it has been stated that the FSF is now trying to impose its moral viewpoint on users, developers and the world. The GPL has *always* been about ethical issues and the four freedoms. This has been raised elsethread and has not been satisfactorily answered.
Look at freedom 1: The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this.
Do you see 'tit for tat' anywhere? Access to the source code is (just) a "precondition". Now the FSF and many other developers have judged that the preconditions have changed (DRM enters the fray), and they have judged this in the context of the four freedoms. They have always understood 'adapt' to exclude the meaning "having to buy or assemble new hardware". The tit for tat aspect of the GPL is a means to an end and a piece of a bigger puzzle.
There is only ONE material difference between the kernel devs position and the FSF position, and it is about where to draw to the line.
Then there are a lot of entirely immaterial differences (patents and supposed license hijacking), and there is obviously a whole cesspool of bad blood. Then people have different crystal balls. Some think powerful forces are at work to force DRM down our throat everywhere. Opinions differ on this as well as on the best course of licensing even if it were true.
I find the accusations of the FSF acting in bad faith incomprehensible. It is probably due to the persona of rms and the history of what's gone before. I had hoped that people would be able to communicate with Eben Moglen, but statements from Linus Torvalds imply bad blood even there.
You cannot reduce GPL v2 to 'quid pro quo' and I see no grounds for your characterization 'eye for eye'.
Licence text and fabs Posted Oct 3, 2006 21:17 UTC (Tue) by sepreece (subscriber, #19270) [Link] While I generally agree that you can't reduce the GPLv2 to "tit for tat", it was largely compatible with the viewpoint that tit-for-tat fairness was what mattered. That is, it could be used happily by authors who cared most about fairness and by authors who cared most about freedom. Some of us think that inclusiveness was an advantage.
I don't question that GPLv3 moves in the direction of the FSF's philosophical center and the aims of many of its supporters. However, it's still important to consider whether it may be going too far. The GPL has always had to balance its ultimate goal of complete freedom against more practical constraints. Some of us believe that GPLv3 has pushed too far.
The GPLv3 violates the 4 GNU freedoms ... Posted Oct 3, 2006 22:46 UTC (Tue) by mingo (subscriber, #31122) [Link] The GPL has *always* been about ethical issues and the four freedoms. I actually believe the 4 freedoms almost directly derive from the thousands of years old "tit-for-tat" concept on source code, and thus if the GPLv3 violates the "tit-for-tat", it inevitably violates the 4 freedoms too. Please let me prove this to you. For example, the proposed GPLv3 violates freedom 2, which is described by RMS as: The freedom to redistribute copies so you can help your neighbor (freedom 2). (link) Example: take the full Tivo userspace binaries (unmodified), and put it on a stock PC. (That is the only GNU piece of software on that PC, all the rest and the hardware was created independently of any GNU software.) You can freely redistribute that copy to your neighbor, as per freedom 2. Take the very same binaries and move the harddisk to the Tivo. (All the other stuff on the Tivo (including the hardware) is independent of any GNU software, it's not a derivative nor a modification of any GPL-ed code.) But under the proposed version of the GPLv3 now you can not redistribute that same copy to your neighbor! Just because it has been put into a Tivo - which Tivo has no GNU code in it except this harddisk which the user has put there. How is this possible? The GPLv3 uses one of the legal powers of the copyright holder, which allows the control of how "redistribution to neighbors" happens, in a new way: to control the handling of a piece of information that was created independently of any GNU software. That piece of information is Tivo's private key, which is only in the hardware. The GPLv3 tries to control hardware that was not copied, modified or from any GPL codebase, and prevents the redistribution of that copy of GPL-ed code, and thus GPLv3 violates freedom 2. GPLv3 proponents might argue that this violation of freedom 2 is done to strengthen another, more important freedom, but this brings in two new problems. Firstly, it is not acceptable to violate any of the 4 freedoms, especially not for a proposed new GNU Public License. If a measure in the GPLv3 violates one of the freedoms, even if it is done to strengthen another freedom, that measure still violates a freedom and should not be used at all. Another measure is needed. Secondly, in reality the "freedom to tinker" [the right to modify freely] never existed in a pure form because this world is based on matter and on physics, which does bring some hard constraints of modifiability with it. "Freedom to tinker" has been invented well after the GNU Manifesto, well after Linus released Linux under the GPL, well after i started contributing to the Linux kernel and well after even the 4 freedoms were invented. So how was Linus or i supposed to consider it when accepting the GPLv2? Furthermore, this physical world has hard constraints which are inevitably assymetric between "would be modifiers" and "producers of the hardware". For example, to modify a ROM that a hardware maker produced is fundamentally harder for someone who is not intimately familiar with that process of hardware creation - whether there's crypto in the picture or not. (But i am not blaming RMS for not realizing this, he's a mathematician after all and thus probably not infallible in matters of physics ;-) I do blame him for not listening (yet) though, and i do blame him for a license modification process that does not self-correct such errors.) I believe your point is also missing a fundamental moral question: does RMS have the moral right to unilaterally and retrospectively change the contribution dynamics of a codebase that is roughly 1 billion lines of code written by hundreds of thousands of contributors, via a 340 lines license RMS wrote 15 years ago, without considering the motivations and moral background of the many contributors that wrote that codebase? I know he did not want this whole "Open Source" stuff to happen, he fought against it tooth and nail, but it happened, and he has ended up with a unique legal position to affect it significantly, and he has to weigh the moral implications of that responsibility. Even if he does not feel to be part of that "Open Source" stuff. The baby has been put on his doorstep (which door has "Orphanage" written on it in large letters ;-), and he has to take care of it, whether its his or not. Or as Lawrence Lessig has recently pointed it out in his blog : The real challenge here will be Richard Stallmans. [...] So his challenge is whether he evolves these licenses in ways that fit his own views alone, recognizing those views deviate from many important parts of the movement he started. Or whether he evolves these licenses to support the communities they have enabled. (Lawrence Lessig)
The GPLv3 violates the 4 GNU freedoms ... Posted Oct 4, 2006 2:23 UTC (Wed) by sanjoy (subscriber, #5026) [Link] The GPLv3 tries to control hardware that was not copied, modified or from any GPL codebase, and prevents the redistribution of that copy of GPL-ed code, and thus GPLv3 violates freedom 2. and (from an earlier message) trying to control what hardware does is immoral It does not control the hardware, even if people claim many times that it does. It says only that if you distribute the code in such hardware, you need to provide another piece of information (a small piece of software, you could say): the authorization key. Tivo (if they used GPLv3 software) would be free to make whatever broken DRM hardware they like, and you would be free to fix it. How is that control over hardware? A similar clause in the GPLv2 says that you need to include Makefiles or other compilation scripts, if you used them. Which makes sense. The Linux kernel would be a right pain to build without its Makefiles. This provision about compilation scripts is a condition on distribution: "You may distribute provided that you do the following..." Just as, under the GPLv3 draft, you may distribute Tivoized software provided that you give users the authorization key. The GPLv3 [tries]...to control the handling of a piece of information that was created independently of any GNU software. That piece of information is Tivo's private key, which is only in the hardware. It is not only in the hardware. It is also, like a compilation script, in Tivo's software somewhere so that they can install new kernels. The GPLv3 merely says that they must include that information, that software, as part of the source code, just as they must include the Makefiles. GPLv3 proponents might argue that this violation of freedom 2 is done to strengthen another, more important freedom, but this brings in two new problems. It brings in new problems only if it is a violation of freedom 2. But people are still free to redistribute copies. They need only to satisfy a few conditions and none of those conditions says anything about how Tivo manufactures hardware. With those conditions satisfied, other people can distribute improved, useful versions of Tivo software and help their neighbors, the purpose of freedom 2. So conditions on distribution are not offensive intrinsically; their moral weight depends what they are. As an example of a good restriction, the GPLv2 requires distributers to provide source code. The GPLv3 is being consistent: It guarantees user freedom. Suppose, under the GPLv2, you take the Linux kernel, make a version that will not boot without first getting an authorization key from Ovit Inc. You distribute that version in your hardware. Fine! Since recipients can get the source code, thanks to the GPLv2, they can undo the damage and install a less ridiculous kernel. Freedom prevails. Now suppose Ovit Inc says: "By signing this contract, you agree not to install such a changed kernel. We will sell you an Ovit device once you sign on the dotted line." That trick too is foreclosed by the GPLv2, which says (in section 6): You may not impose any further restrictions on the recipients' exercise of the rights granted herein. Ovit could claim that it never agreed to the GPL and is therefore free to impose any contractual obligation on you (that is not against the law). However, that choice would make Ovit a copyright infringer, a ruinous proposition thanks to how draconian copyright law has become. So Ovit Inc tries a third approach. It builds hardware with an embedded private key, and only if the keys check out with Central Command will the kernel boot. Here probably the GPLv2 has no solution (although the "compilation scripts" provision may help, but only a judge would know, or more precisely, could create an answer by making a ruling). The GPLv3 says: "No. Just as you cannot lock the code down with boot keys or with legal provisions, you also cannot lock it down with hardware. Make whatever hardware you like, we have no opinion on that. But if you can modify the free software you are distributing, so can the people who receive it: You must give them the magic keys." Too bad the kernel won't switch to GPLv3, due to logistical difficulties (pain in the neck to contact all copyright holders) and to ideological objections. But that doesn't mean the GPLv3 isn't a reasonable, consistent solution to a real problem.
The GPLv3 violates the 4 GNU freedoms ... Posted Oct 4, 2006 13:37 UTC (Wed) by sepreece (subscriber, #19270) [Link] I'm sorry. I can't read this argument as anything but sophistry. Yes, the literal restriction may be the requirement to include needed keys, but the practical issue is the right to install on the device in such a way that the software continues to work, on that device, and maintain its authentication status with other services.
Even in literal terms, since the keys you mention typically involve the identity of the device as well as the software, the domain of control is clearly being extended to include the hardware. You're no longer asking for the things you need to install the software, you're asking for the things you need to install the software on a particular device, in a particular way (so that it can lie to other components or services about which version it is).
Don't bother. The FSF position is clear without the contorted rationale. Some of us disagree with it, but at least it's a straightforward position based on a philosophical position.
The GPLv3 violates the 4 GNU freedoms ... Posted Oct 4, 2006 12:29 UTC (Wed) by stijn (subscriber, #570) [Link] I actually have problems just understanding your Tivo example (also used elsethread) and I would like to grok it - this kind of scenario is what is needed most in this type of discussion. It is likely due to the fact that I do not have a full grasp of the licensese in GPL v2 and draft v3 and its implications in the scenario. More specifically, you seem to focus on userspace (significance?), binaries (source?), and redistribution (arrival in the first place?). This pertains to your point of freedom 2) being violated.
Freedom to tinker is an essential part of the famous printer driver story. I am not sure I follow.
About the fundamental moral question now. I wanted to establish that the FSF and Richard Stallman and Eben Moglen are acting in good faith and according to a consistent view of the world. The divide now is whether v3 is 'similar in spirit' or not. I tentatively think it is although I am not sure the DRM clause can be formulated in a sufficiently clear way (or, whether it can find an unambiguous border line). I am dead certain however that the FSF *intent* is to be 'similar in spirit'. I think there has been a lack of acknowledgement regarding this.
The moral question then pertains to all the people who licensed with the famous 'or (at your option) any later version', and it pertains to whether they judge the DRM clause to be similar in spirit. I am one of them, albeit with some very small impopular user-space projects. The kernel developers are not as far as the kernel is concerned. The busybox case is not so clear cut.
Linus Torvalds has done well to do without the 'later' clause, given his liking and interpretation of 'tit for tat'. The concerns raised by the kernel developers and the rationale are genuine and your many contributions in the various LWN threads are highly valued. The general stance has been rather unforgiving, emotionally charged, and one of abandonment. In this last sentence I was going to denounce that, but who knows, sometimes conflict is necessary.
"moral right"? um...whyever not? Posted Oct 4, 2006 21:49 UTC (Wed) by roelofs (guest, #2599) [Link] I believe your point is also missing a fundamental moral question: does RMS have the moral right to unilaterally and retrospectively change the contribution dynamics of a codebase that is roughly 1 billion lines of code written by hundreds of thousands of contributors, via a 340 lines license RMS wrote 15 years ago, without considering the motivations and moral background of the many contributors that wrote that codebase?Insofar as those contributors granted him/FSF that right, whether explicitly or implicitly, why wouldn't he have it? How naive do you have to be to grant the "or any later version" power to a third party and not expect that it might result in license changes not entirely to your liking? If you truly want to preclude such changes affecting your code, then you don't use the "or any later version" language--just as, in fact, Linus and you and the other kernel developers did. But for everyone else--everyone in that 1-billion-LoC, 100,000-plus-contributors category, the numbers of which I'll take your word for--they ceded both legal and moral authority to the FSF when they chose that wording on their license grants. The only vaguely comparable examples I can think of--but where the "legal" and "moral" rights arguably did diverge significantly--are the Unisys/GIF/LZW promise of a patent exception for free (not Free) software, and the amazingly similar Mozilla/Firefox promise of a trademark exception for Debian. In neither case was the promise ever a legal agreement, at least under US law, and in both cases it was later revoked unilaterally. To put it another way, "moral" rights were (temporarily) granted, but legal rights never were. However, I see no similarity to the current GPL v2/v3 issue beyond the most basic level of all three examples having to do with legal rights and additionally having a "moral" or ethical dimension. The GPL case, unlike the others, seems legally, morally, and ethically self-consistent to me. Greg
Licence text and fabs Posted Oct 4, 2006 9:27 UTC (Wed) by nim-nim (subscriber, #34454) [Link] The GPL even in it's v2 form controls more than the code itself. For example you can not claim you can only provide source on gold plated media available at extorsionate price (that is unless you can prove you have to use gold-plated media yourself).
Some people are currently trying to reintroduce the artificial cost asymetry the GPLv2 forbids for source at the binary level (using DRM). The GPLv3 logically forbids it too.
And BTW it's false to say the GPLv3 affects hardware, since the hardware itself is unaffected by who holds the distribution keys. What it affects is the combined harware+software behaviour.
It's not terribly immoral or astonishing that when you combine software distribution with hardware, the software distribution rules have a say on the result. Linking works both ways.
Licence text and fabs Posted Oct 4, 2006 14:16 UTC (Wed) by mingo (subscriber, #31122) [Link] The GPL even in it's v2 form controls more than the code itself. For example you can not claim you can only provide source on gold plated media available at extorsionate price (that is unless you can prove you have to use gold-plated media yourself). that is different. I'm not talking about common-sense definitions about how the "payment" for our creative works (which payment is mostly in the form of providing source code) happens. The thing i'm talking about here is that the GPLv3 includes another work (the key) which is independent of our GPL-ed works, in the definition of Source Code, which source code we purport to license! (and then later on the GPLv3 uses this "defining of other people's creative works into our license's Source Code" act as a tool to prevent the hardware from being redistributed, unless the newly-defined "source code" (which now includes another person's independent creative work!) is provided too.)
Licence text and fabs Posted Oct 4, 2006 20:51 UTC (Wed) by nim-nim (subscriber, #34454) [Link] > The thing i'm talking about here is that the GPLv3 includes another work> (the key) which is independent of our GPL-ed works, in the definition of > Source Code, which source code we purport to license!
I can't imagine how anyone could construct the key as a "work", it costs nothing to create or duplicate.
Take the same hardware with and without DRM. It should be painfully obvious the only "value" "created" by adding DRM and making it apply on GPLed software is the possibility to stop the accesses the GPLv2 used to imply reneging on part of the "payment" for GPLed code use.
Someone has been breaking a bargain. Someone has been extending itself unilaterally without counterpart. Is this someone the FSF? I don't think so
Licence text and fabs Posted Oct 4, 2006 21:55 UTC (Wed) by mingo (subscriber, #31122) [Link] I can't imagine how anyone could construct the key as a "work", it costs nothing to create or duplicate. Let me give you an example of a 1024-bit key: mQGiBDlqJigRBADpPRhgY7lPy42Hy1gk6YKT81QOGkptbUuSkKZ4lSvGT5DEsmwG q6/l+/WdeE9401Njs55bnztcetCzcadyBIxPJz+JpzbaOjwdxTZuLHstQ5+ddK54 fdDBw76W0N/DZTV/rypPvl0p9NtnmT+Q5tWF1j/s7bLxyNBBNxRpiBm+xwCg/zEy 2YVUb9hnsna1Lknp4sxGBN8D/RvG4wXHLzFIsEjY4qlY+W0hN3dNW0mBuqLEZ3gD E1rZyI9/6 wHQeGIB m5euYv1YJ This chunk of metal, like it or not, 1ASDFlk WIAfA/4kS Is our love and hate, my bright spot. xAIQusQ cfSBBwn68 Treat it with respect, dear Alice, AOX9D/v VKb/Ia5Wb To protect its keys, we promise. y1IYXNz byBTdGFtZ WomKAQL AwIBAAoJE Copyright, 2006, Ingo Molnar. 8WD8g0T mo9TCht0r 2AmDLM9 j2R35j0DF9sxrMLwz2JhAJ9eUCud0CxsVANJg3BsTvftvbgVIIhGBBARAgAGBQI7 Wm7tAAoJEMGC+zEYbLxm1OMAnjlzJ2MZJ2yoBzagnLesayo1qHhxAKC32HkRdxt2 bZSCQrDA7CftJLYBjLkEDQQ5aiYpEBAA+RigfloGYXpDkJXcBWyHhuxh7M1FHw7Y 4KN5xsncegus5D/jRpS2MEpT13wCFkiAtRXlKZmpnwd00//jocWWIE6YZbjYDe4Q tu+Pp0NGCMbMHXdXJDhK4sTw6I4TZ5dOkhNh9tvrJQ4X/faY98h8ebByHTh1+/bBThis work, besides still being a pretty strong cryptographic key, is also a literary work, a creative original expression, and is copyrightable. (The fact that it's easily copied - like any piece of digital information - has no bearing on the strength of copyright protection.)
Licence text and fabs Posted Oct 5, 2006 6:34 UTC (Thu) by nim-nim (subscriber, #34454) [Link] Bzzt. Thank you for making my point
Copyright "works" are only protected if they are the produce of human creative expression (could not have been created by a stupid computer alone)
99,99999% of DRM keys obviously aren't.
Now you artificial unrepresentative example isn't, but IIRC in a similar case when Sega tried to lock its console by checking for the Sega word/logo at the beginning of ROMs, a judge ruled since the Sega word/logo use was 100% technical and the check could have been implemented by Sega the same way with a non trademarked/copyrighted/protected string/bitbucket, using Sega instead didn't win them any special additional protection.
Which again is academic because actual DRM keys do not look like yours.
Licence text and fabs Posted Oct 5, 2006 7:30 UTC (Thu) by mingo (subscriber, #31122) [Link] Now you artificial unrepresentative example isn't, but IIRC in a similar case when Sega tried to lock its console by checking for the Sega word/logo at the beginning of ROMs, a judge ruled since the Sega word/logo use was 100% technical and the check could have been implemented by Sega the same way with a non trademarked/copyrighted/protected string/bitbucket, using Sega instead didn't win them any special additional protection. well, what i wrote into the key wasnt a simple word/logo. And yes, it can be used as a totally valid cryptographic key - it has enough random content to be cryptographically strong, and it has enough expressive content to be copyrightable. And if it's kept secret by the hardware, it can very much be a trade secret as well. The Sega logo is hardly a trade secret. Do you have any case law that says that trade secret works that are /independent/ of the copyright holder's work are trumped by copyright law? In my reading it would be contrary to the letter and the spirit of both the law and the Constitution. This was a relatively small key i constructed, but what if that key includes actual, functional code as well, which would have to be executed by the CPU for the hardware to work correctly. What if that key is your family inheritance that your ancestors signed their legal documents with for decades, and which includes expressive content that has sentimental value to me as well. Your assumption that just because it's used as a key it cannot have expressive properties was false when you first said it, and it is still false now. And you are still missing the larger point as well. This portion of the GPLv3 is a seemingly small but dramatic departure from the spirit of the GPLv2, which explicitly said that it does not attempt to control other works (unless those works being based on GPL-ed code), be that source code, keys or anything else. GPLv2 Section 2 says:
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. this language is gone from the GPLv3, and the DRM language does a first step towards using distribution rights to control other works. Today it is only used to control certain keys. So far I have not seen anyone even try to limit the scope of this new step, it seems the party line of the FSF is that "everything that /we/ think or ever thought would be needed for the 4 freedoms is a fair game". Would you ever sign a contract with that kind of open-ended language in it? And in what way will you change the bargain next time around? Until today it was in essence source code for source code, and it took 10 years to explain even this simple concept to developers. Tomorrow it's the hardware's keys too in some cases, the day after tomorrow it will be what? Will the GPLv4 say:
You must ship 10 free samples of hardware and design specifications to the FSF headquarters and offer free on-site training and free tools for tweakers to be able to make use of their right to tweak. Will the GPLv4 perhaps include:
You may only distribute copies of works that are GPL-compatible in their totality. Aggregation with any non-GPL work is prohibited. is that the plan? Future contributors will be asking me that, and I have no answer for them, do you have any? We are going to lose alot more contributors this way than due to this uncertainty of the deal than whatever freeloading might become possible via DRM. Freeloading was always possible - heck, a simple end-user of GPL-ed code who never contributes back and never distributes GPL-ed works is a "freeloader" almost by definition. I'm not worried about freeloaders as long as it's economically unfeasible for them, both the GPLv2 and the GPLv3 has loopholes that enable freeloading and leaching. I'm alot more worried about having a fair and clear deal towards developers, because they wrote this 1 billion lines of GPL-ed code, not the FSF. Or was this section of the GPLv2 just a false promise to lure developers into writing 1 billion lines of code?
Licence text and fabs Posted Oct 5, 2006 8:45 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > I'm not worried about freeloaders as long as it's economically unfeasible> for them, both the GPLv2 and the GPLv3 has loopholes that enable freeloading > and leaching. I'm alot more worried about having a fair and clear deal > towards developers, because they wrote this 1 billion lines of GPL-ed code, > not the FSF.
Of course, that's assuming no developper shares the FSF concerns, which is patently false. You can no more claim the developers support as the whole that the FSF can
Licence text and fabs Posted Oct 5, 2006 9:18 UTC (Thu) by mingo (subscriber, #31122) [Link] Is there any reason why you have not replied to my points below, i think they are important:And you are still missing the larger point as well. This portion of the GPLv3 is a seemingly small but dramatic departure from the spirit of the GPLv2, which explicitly said that it does not attempt to control other works (unless those works being based on GPL-ed code), be that source code, keys or anything else. GPLv2 Section 2 says:
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. this language is gone from the GPLv3, and the DRM language does a first step towards using distribution rights to control other works. Today it is only used to control certain keys. So far I have not seen anyone even try to limit the scope of this new step, it seems the party line of the FSF is that "everything that /we/ think or ever thought would be needed for the 4 freedoms is a fair game". Would you ever sign a contract with that kind of open-ended language in it? And in what way will you change the bargain next time around? Until today it was in essence source code for source code, and it took 10 years to explain even this simple concept to developers. Tomorrow it's the hardware's keys too in some cases, the day after tomorrow it will be what? Will the GPLv4 say:
You must ship 10 free samples of hardware and design specifications to the FSF headquarters and offer free on-site training and free tools for tweakers to be able to make use of their right to tweak. Will the GPLv4 perhaps include:
You may only distribute copies of works that are GPL-compatible in their totality. Aggregation with any non-GPL work is prohibited. is that the plan? Future contributors will be asking me that, and I have no answer for them, do you have any?
Licence text and fabs Posted Oct 5, 2006 11:19 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > And you are still missing the larger point as well. This portion of the> GPLv3 is a seemingly small but dramatic departure from the spirit of the > GPLv2,
To be honest, I didn't feel I needed this portion of your argument needed to be rebuted, as better people than me (Alan Cox for example) already stated they didn't feel it was the case.
I happen to agree with them.
Licence text and fabs Posted Oct 5, 2006 7:31 UTC (Thu) by mingo (subscriber, #31122) [Link] And no-one has explained it to me yet how it would reduce the amount of DRM in hardware if the GPL adopted anti-DRM language. All the indicators are that such a step /increases/ the amount of DRM done, because a fair portion of current embedded Linux would switch to other OSs. (partly because they are forced by other content makers to use DRM, partly because they'd sense a fundamental uncertainty in the licensing foundations of Linux.) Also, the FSF should be well aware of the fact that it's always the first layer of software that matters for DRM, most of the time. So it's the kernel that has to deal with hardware and DRM issues. It's the kernel's contribution rules that you are playing with here. In fact without the kernel moving to GPLv3 the whole DRM section is almost totally pointless. (unless you count Hurd, which would have to remove tons of Linux code to begin with, if it wants to switch to the GPLv3) The remaining free software projects are mostly just curious bystanders. Yeah, i oppose DRM just as much as you do, but do /you/ have to deal with the fallout of this happy activism?
Licence text and fabs Posted Oct 5, 2006 8:50 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > And no-one has explained it to me yet how it would reduce the amount of DRM> in hardware if the GPL adopted anti-DRM language
Read the transcripts of MP discussions when local EUCD/DMCA law are passed. One question they ask is "it will help Hollywood, but will blanket legal DRM protection/mandate hurt any other economic actor ?". Of course the major representatives try to convince them the answer is no.
The GPLv3 is a very clear way to show MPs blanket legal DRM protection/mandate hurts someone.
Licence text and fabs Posted Oct 5, 2006 9:37 UTC (Thu) by mingo (subscriber, #31122) [Link] The GPLv3 is a very clear way to show MPs blanket legal DRM protection/mandate hurts someone. How would that happen in practice? Lets take Tivo, an FSF-selected example (presumably because it's the best example of harmful DRM they could find), ok? How does the GPLv3 show that blanket legal DRM protection hurts someone, in the Tivo example? Lets assume the kernel goes GPLv3. Please outline the scenario of likely action that would/could happen in your opinion. The only way i could theoretically imagine would be for a large non-DRM hardware base with GPLv3 kernel+userspace to be built up right now, which industry would complain loudly if a change in laws would made their product illegal to distribute under the GPLv3. Given that essentially every medial player and every mobile phone on the market includes some form of DRM currently, as per the wishes of the content industry (whose content consumers actually want to enjoy), how do you see the likelyhood of that happening in practice, /without/ a huge body of free content that consumers would be equally crazy about? Please outline the scenario that you think would/could happen.
Licence text and fabs Posted Oct 5, 2006 10:51 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > How would that happen in practice?
Very easily.
Mr V. goes to his local MP to make DRM mandatory and protected by law on all media processing boxes. The MP asks if it will hurt someone. Mr V says "of course not, it will only catch evil pirates".
Mr F can then come saying "But this will ban use of FLOSSTV, which is licensed under the GPLvx which is uncompatible with the proposal" competition and free market is good, you can't do that. This is a strong argument.
Right now M F can only say "But this will harm FLOSSTV, which is licensed under the GPLvx which intent/spirit is uncompatible with the proposal" competition and free market is good, you can't do that. This is a weak argument, spirit and intent count for zip.
In case you think I'm making all this up, I'm only repeating from memory some of the arguments used in the French Parliament when the EUCD directive was translated in local law this year.
Some of the articles proposed by the majors were clearly uncompatible with existing Free Software license terms and could be amended. For others the uncompatibility was not so clear cut and unfortunately opposing them proved impossible.
The harm BTW was not only FLOSS-side. The law hurt numerous actors, but they all found out nothing but the most blatant problems (such as law/license uncompatibilities) had any weight against the majors' money.
Licence text and fabs Posted Oct 5, 2006 7:36 UTC (Thu) by mingo (subscriber, #31122) [Link] Which again is academic because actual DRM keys do not look like yours. [sarcasm] Oh, thank goodness no-one else will think of this and they will not produce DRM keys that are copyrightable. Phew, that was close, i was almost getting worried! [/sarcasm]
Licence text and fabs Posted Oct 5, 2006 8:42 UTC (Thu) by nim-nim (subscriber, #34454) [Link] Oh, some people will think of it.
But you know what? I don't care. They'll be laughted out of court since judges have a very low tolerance for this kind of legal trick.
The judge's test will be the following: are the copyrighted/trademark/whatever parts functionnaly necessary? If the answer is no and they've been knowingly inserted only to make copyright/trademark/whatever law conflict with another legal requirement, game over. You're trying to game the law and wasting the judge's times. Too bad for you if you loose some IP property in the process, no one forced you to expose it.
Even if someone managed to construct some functionnal reason for the use of these parts, copyright/trademark/whatever law wouldn't win automatically -- the judge would balance one requirement against another, and the more artificial convoluted one would lose.
Licence text and fabs Posted Oct 5, 2006 9:12 UTC (Thu) by mingo (subscriber, #31122) [Link] Sensing some fundamental disagreement that causes us to argue circularly i have read back some of your other replies in other threads and I think your core argument in favor of DRM is in one of your sentences:
GPLv2+DRM happens to enable corporations to do the BSD on GPL code they wanted all along. Does that fairly summarize your points around DRM up in essence? If yes then i contest your suggestion above. (i thought i did that before, but hey) GPLv2+DRM still gives us the source code. BSD doesnt. Tivo gives us their source code for the DRM-ed kernel they utilize. So where does the GPLv2+DRM combination create the "BSD on GPL code" situation in the Tivo case? I'd really like to understand your logic here. I'd agree with you that if GPLv2+DRM would be equivalent to the BSD then that would not be acceptable to me and i'd find little joy in hacking the kernel. (when i started developing Linux years ago i made a conscious choice against BSD, mostly due to their license)
Licence text and fabs Posted Oct 5, 2006 11:16 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > So where does the GPLv2+DRM combination create the "BSD on GPL code"> situation in the Tivo case
Very easily, you only need to make DRMed PCs the cheap norm and open PCs the expensive exception.
for every-market-without-GPLv3-software ; do
// Making exceptions costs money and the majors don't like hairies
// Need some GPLv2 devs with access to DRMed hardware
// This only takes a few years with modern lifecycles
// This takes a tad longuer, as hairies will hoard previous gen hardware
// Without hobbyists there are less floss devs on the job market
note (floss-in-market-nonexistent);
This is the usual BSD pattern of hire key community people, stop contributing downstream, redeploy once the community is anemic
Licence text and fabs Posted Oct 5, 2006 10:15 UTC (Thu) by mingo (subscriber, #31122) [Link] The judge's test will be the following: are the copyrighted/trademark/whatever parts functionnaly necessary? If the answer is no and they've been knowingly inserted only to make copyright/trademark/whatever law conflict with another legal requirement, game over. But this is not "another legal requirement". This is the GPLv3's attempt to extend its scope to works created independently of that work. How do you know that it's "defendant laughed out of court" instead of "GPLv3 plaintiff's copyrights being judged unenforceable, due to misuse of copyright"?
Licence text and fabs Posted Oct 5, 2006 11:33 UTC (Thu) by nim-nim (subscriber, #34454) [Link] > How do you know that it's "defendant laughed out of court" instead of "GPLv3> plaintiff's copyrights being judged unenforceable, due to misuse of > copyright"?
As the GPLv2 enforcements efforts have shown, a judge will tend to consider someone availing himself of some provisions of a licence (free code access) has no legs to stand on contesting the obligations part later (as long as the obligations are clearly expressed).
Nobody forces anyone to use copyrighted/trade secrets/trademarks as DRM keys.
Licence text and fabs Posted Oct 5, 2006 14:25 UTC (Thu) by mingo (subscriber, #31122) [Link] As the GPLv2 enforcements efforts have shown, a judge will tend to consider someone availing himself of some provisions of a licence (free code access) has no legs to stand on contesting the obligations part later (as long as the obligations are clearly expressed). Oh, the GPLv2 enforcements so far were mostly about clear-cut violations like "not giving out the source code", or trying to hide the origin of the code and copyright ownership by modifying binaries. I believe you are over-simplifying the picture. A more realistic case would be like this: - hardware maker fully living up to all provisions of the GPL. Source code made available on their website, etc. - separate content provider (provider of expensive GPS maps, movies, pay-per-view events, etc.) insists on copy protection of their content. - hardware maker use of DRM to restrict the extraction of that content from the hardware, by only allowing trusted installs approved by the hardware maker. GPLv3 copyright owner sues. The judge will weigh: on the one side, the legitimate interests of the content owner, and the trade secret of the hardware maker, and the contractual obligation of the hardware maker to not make the content copiable, against the interest of the GPL owner, who gets his modified source code. The hardware maker even contributed back to the copyright owner's project. But besides the source code (which was the main object of trade in a previous version of the same license, which was "similar in spirit"), the GPL work owner now also insists on a new-found and pretty far-fetched "right to tweak the hardware". The hardware does not look all that tweakable to the judge, it's a sealed pink plastic cube. The copyright holder insists on the defendant either ceasing distribution (which likely bankrups the defendant) or requires the giveout of the trade-secret crypto key (which likely bankrupts the defendant too, because he was contractually obligated to the content owner to protect stuff and to not give out the key). Furthermore, the judge will look who the people with this "right to tweak the hardware" are. They describe themselves as certain "hackers", and they want to "hack on the hardware". To do good stuff, amongst them, as the defendant will point out, "to enable pay-per-view piracy". On the other hand, the judge will weigh the "harm" that the denial of this request for keys causes the copyright owner, but that harm seems rather remote: the copyright owner has only a personal interest in modifying the hardware. Out of curiosity. No matter how difficult technically. And he could run the manufacturer's code on his home PC. No, of course he does not want to watch pirated content. Do you think the decision is so clear-cut against the defendant, especially if the defendant insists on a jury trial?
Licence text and fabs Posted Oct 5, 2006 15:22 UTC (Thu) by nim-nim (subscriber, #34454) [Link] The answer is simple :
1. hardware maker uses GPLvx code -> he's now bound by the license requirement
2. here comes content provider, asking something incompatible with the hardware maker licensing obligations :
No judge will defend someone promising to do foo to A and not-foo to B.
Licence text and fabs Posted Oct 5, 2006 18:44 UTC (Thu) by espeer (subscriber, #39062) [Link] stevenj wrote:
> The only problem comes if the manufacturer wants the ability to modify
No, by not providing keys, hashes or whatever, the manufacturer is not
The question here is, should we be dictating requirements on the openness
the beef Posted Oct 2, 2006 22:34 UTC (Mon) by coriordan (guest, #7544) [Link] 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.
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?
|
|||||||||||||