| |||||||||||||
FSF is creating a problem that never existed!FSF is creating a problem that never existed!Posted Oct 2, 2006 8:06 UTC (Mon) by mingo (subscriber, #31122)In reply to: FSF is creating a problem that never existed! by mingo Parent article: Busy busy busybox
This unprecedented legal power of the FSF derives from their legal ability to unilaterally change the license after 15 years, by using the wildcard "or any later" language, without any legal obligation for consent from the community! I also think that many people (like myself) have put efforts into GPL-ed projects without fully realizing this legal power and the legal effects of the "or any later version" and the "similar in spirit" clauses. We are all just coders after all, with little care for the legal smallprint. The FSF is now trying to pretend that the changes in the GPLv3 were "always intended to be there" and that this somehow resulted in every contributor having accepted that intent being codified into the license. The FSF apparently does not realize its deep moral obligations that comes with its legal power over this huge codebase. (of which codebase the FSF wrote only a very small portion) What worries me most about the GPLv3 process arent even the technical flaws of the GPLv3 draft (because flaws can be fixed), but the apparent and fundamental lack of acceptance of the moral obligations that the FSF owes to the more than one hundred thousand contributors of this hugebase. The FSF, having started this project still believes they have a moral right to unilaterally control its future, and are trying to enforce their moral vision, apparently just because they legally can. Without realizing this enormous moral obligation, and without codifying that obligation into the license and into the license update process i feel there is no possibility for the GPLv3 process to be open in the sense of free software: we should not only have the ability to see the process, but also the ability to modify it. (And if that cannot be done legally: dont do it then. Remove the "or any later" language and go the normal way of acquiring the hearts and minds of contributors: by convincing them to use a new license, once it has been released, for newly written code or for old code they wrote and are willing to relicense, one by one.) This unilateral "Richard Stallman is the judge and jury" process is a parody of free software and is humiliating to me personally.
(Log in to post comments)
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 2, 2006 8:55 UTC (Mon) by khim (subscriber, #9252) [Link] The FSF is now trying to pretend that the changes in the GPLv3 were "always intended to be there" Sorry, but this document was written before GPLv1, GPLv2 or GPLv3. To make it possible for "a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him" in the world where DRM is common GPLv2 is not enough. Thus GPLv3 was born. Where is "pretense" ? The FSF apparently does not realize its deep moral obligations that comes with its legal power over this huge codebase On the contrary - FSF understands it so very well. That's why GPLv2 has recommendation to allow for GPLv3. MPL and CC license just blingly give the right to switch to new version - no questions asked. Is it better ? We should not only have the ability to see the process, but also the ability to modify it. Huh ? Can you do it with Linux ? If Linus does not like your approach - he'll write thing himself and your contributions will be thrown away. Linux will include the things Linus likes and only things Linus likes. You can always argue on the LKML. GPLv3 will include the things RMS likes and only things RMS likes. You can argue you case on the site or you can participate in different form. You want the right to veto changes in GPLv3, right ? Do you have the right to veto changes in Linux ? Remove the "or any later" language and go the normal way of acquiring the hearts and minds of contributors: by convincing them to use a new license, once it has been released, for newly written code or for old code they wrote and are willing to relicense, one by one.) Does not work this way: any project of more-then-trivial size includes contributions from people why left, don't care about the project anymore, etc. The people who do care can always remove "or later" clause FSF already did the most of the work: "or later" clause is not part of license, but only part of the grant text. GPLv2 was created this way unlike MPL or CC.
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 2, 2006 9:57 UTC (Mon) by mingo (subscriber, #31122) [Link] The FSF is now trying to pretend that the changes in the GPLv3 were "always intended to be there" and that this somehow resulted in every contributor having accepted that intent being codified into the license. To make it possible for "a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him" in the world where DRM is common GPLv2 is not enough. Thus GPLv3 was born. Where is "pretense" ? Firstly, the "pretense" is in the sentence above that you only quoted partially in your reply. (You snipped away the crutial "having accepted that intent being codified into the license".) Secondly, i contributed to GPL-ed projects, and i never accepted the GNU Manifesto's full range of 20 years old considerations being integrated into the GPL. I trusted the FSF to update the license to be "similar in spirit" so that it does minimal adoptations to new times, but now i see that trust being abused for political means, such as for the crusade against Tivo. So at least as far I am concerned, there is real pretense in the FSF's position. Linus did not trust the FSF's "similar in spirit" promise and codified all contributions to Linux being under the GPLv2, and i see his distrust being largely justified today. I never accepted every raving email or other writings of RMS being incorporated into the license by reference. I now see that the "or later" and "similar in spirit" clauses might legally enable RMS to achieve that, but i am outraged by his attempt to use that loophole. Thirdly, even considering the words of the GNU Manifesto, it misses the point by a wide margin: "a user who needs changes in the system will always be free to make them himself, or hire any available programmer or company to make them for him" So tell me, if I etch a GPL-ed CPU design into silicon, for example via this GPL-ed CPU design, what programmer on this planet could possibly modify that chip, if that chip is put into a system? Are you trying to argue that "modifiability" is an unqualified property of all systems that run GPL-ed code? Are you trying to argue that any CPU maker who uses GPL-ed designs is obligated to open up their fab process and let random users from the world produce their modified cores? Fact is: no system exists today that is fully modifiable. Fact is: the FSF and you are trying to single out certain types of tools and techniques that can restrict hardware, after the fact (DRM has been around for 10 years or more), just because they and you dont like the restrictions on Tivo. Fact is: i never authorized the FSF with codifying technically inconsistent and vague statements of the GNU Manifesto and various other writings of RMS into the GPL license. They might be able to pull it off legally, but it is arbitrary and deeply political in my opinion, and against the trust i have put into the FSF when i made my contributions.
Licence text and fabs Posted Oct 2, 2006 14:59 UTC (Mon) by coriordan (guest, #7544) [Link] 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.
The closing fact about no fully-modifiable system existing is a "Can't be perfect therefore all effort is in vain" argument. It's not true. 100% effectiveness isn't required, and isn't possible through licences alone. GPLv3 is making small changes which can close some real world loopholes - ones that exist and are used, not theoretical ones or ones that are impractical.
But the most important thing is that there is nothing in the text about signing up to the GNU Manifesto, or opening the factory doors of every fab that burns GPL'd software onto a chip. Lets discuss what's in the text - that's the route to solving the problem (if there is a solution).
Licence text and fabs Posted Oct 2, 2006 20:23 UTC (Mon) by mingo (subscriber, #31122) [Link] 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.
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 (subscriber, #28458) [Link] If you pass ownership on to someone else but then attempt to prevent them from modifying it, I wouldn't just call that a violation of the intent of the GPL... I'd call that fraud.By your reasoning, credit card companies are comitting fraud by not letting you easily change the identification on credit cards to match those of Bill Gates.
Re: the beef Posted Oct 3, 2006 14:47 UTC (Tue) by mingo (subscriber, #31122) [Link] This is absurd. yes, it is. In my opinion, that is the quickest way to kill commercial embedded Linux development. If the kernel moved to the GPLv3, it would be, yes. Given that the kernel is the closest to the hardware, we kernel developers will be the first ones to see the bad effects of any bad construct within the GPLv3 affecting hardware. That is i think partly the reason why the growing resistance against the GPLv3 comes from the kernel community. And even if the GPLv3 does not yet limit wide aspects of the hardware (only certain types of keys are included for the moment), a dangerous precedent is set and the possibilities for excuses to widen the definition of "Source Code" are unlimited. The GPLv3 in this point significantly departs from the spirit of the GPLv2, which explicitly grants the freedom of unlimited end-use and the freedom of not having GPL-ed code control works (such as hardware) independent of that GPL-ed code. Even if that end-use or hardware is highly inconvenient (and thus makes the modification of software harder) for certain classes of developers: it is an atomic bomb, a landmine or a Tivo.
Re: the beef Posted Oct 4, 2006 9:42 UTC (Wed) by nim-nim (subscriber, #34454) [Link] > This is absurd. One is now restricting use of hardware if I don't allow> someone to hack the GPLv3 software on the device
In case you didn't notice the GPL was always about passing "permission to hack" downstream (unless hacking was materially impossible, such as a ROM but DRM is not a ROM - if it were you couldn't hack the device either).
What's absurd is people having chosen to forgot this basic, if inconvenient fact.
The DRM=ROM argument is stupid - if DRM=ROM just use ROM and be done with it. Neither the GPLv2 nor the GPLv3 forbids it. That people beg for being allowed to use DRM instead of ROM clearly shows they are different.
Re: the beef Posted Oct 4, 2006 13:59 UTC (Wed) by sepreece (subscriber, #19270) [Link] Of course ROM and DRM are different. The question is whether they are difference is qualitative or quantitative. The intended end result, from the device distributor's point of view, is the same: the end user can't change the software in the device so that it does things other than what it is supposed to do.
The FSF is arguing that the difference is qualitative, and has created the "you must pass along the same rights you have"[*] argument to support that point. Nothing in the four freedoms provides a base for such an argument, but, hey, they're reasonably inventive people.
The device distributors would argue that the difference is quantitative; that preserving the ability to repair devices lowers the lifecycle cost of the device. If they had to budget for recalls to replace devices when software defects were discovered in the field, they would have to charge more for the devices to get the same profit margin.
Yes, the device distributors want to have a right on the device that the end user does not have, as a condition of using the device with their service. Some of us honestly don't have any problems with that; the FSF obviously does. That's fine - I just wish they would assert their conviction that an additional freedom is required, rather than rationalizing.
--
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?
FSF is creating a problem that never existed! Posted Oct 2, 2006 11:25 UTC (Mon) by mingo (subscriber, #31122) [Link] We should not only have the ability to see the process, but also the ability to modify it. Huh ? Can you do it with Linux ? yes, i can do it with Linux, and more than that, i have already done it with Linux. You can fork Linux anytime, and people do, routinely. If Linus messes up then people just take over. It's very easy to do. If Linus does not like your approach - he'll write thing himself and your contributions will be thrown away. Linux will include the things Linus likes and only things Linus likes. Please let me just prove how wrong you are, with real events. Linus wrote this about "Priority Inheritance": So by your logic, Linux would have no Priority Inheritance until Linus maintained it, because he monopolizes the decision process and goes against patches that he feels strongly about? How come then that just 9 months after Linus wrote that, the v2.6.18 Linux kernel added support for priority inheritance? And i could list dozens of examples. So far I have yet to see any technical issue over which Linus isnt keeping an open mind. Even if the end-result is embarrasing to the position he took earlier. Even hugely embarrasing sometimes. (Those are the dangers of an open decision process.) And why is it so? Because Linus has no control over forks, and he has no unfair advantage. (He does actually know quite a few things about Linux and he is also a very good maintainer, so that is a real advantage he has over forks - but anyone with better abilities can replace him and the barriers to that are low.)
FSF is creating a problem that did not exist before! Posted Oct 2, 2006 14:19 UTC (Mon) by mingo (subscriber, #31122) [Link] The people who do care can always remove "or later" clause FSF already did the most of the work: "or later" clause is not part of license, but only part of the grant text. This still misses the point. Nothing that i do in the future can affect the rules of the contributions i did in the past. Still there's a single person on this planet who can do it: RMS has the legal power to retroactively change the meaning of my contributions, by releasing a new version of the GPL. (Yes, i trusted and empowered him to be able to do it by contributing "or later" licensed code, and i might regret it if he releases a new version of the license that is contrary to what i thought the GPL was about and people would be able to co-opt my code under a later version of the GPL without me being able to merge back their modifications into my codebase.) Or is your point that RMS does not have this legal power vested in him and only him? Or if you agree with me that this power does exist, dont you think this power has more moral obligations attached to it than trying to advance his own moral rules?
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 2, 2006 18:33 UTC (Mon) by landley (guest, #6789) [Link] The bogeyman the FSF has been waving for years is "we may have to ammendGPL if a court case proves it unenforceable". This didn't happen, instead a bunch of case law has piled up around the world showing that GPLv2 is very enforceable.
The FSF isn't doing GPLv3 because GPLv2 is no longer useable. The FSF is
As Darth Vader said: "I am altering the bargain. Pray I don't alter it
Rob
FSF is creating a problem that did not exist before! Posted Oct 2, 2006 20:08 UTC (Mon) by mingo (subscriber, #31122) [Link] As Darth Vader said: "I am altering the bargain. Pray I don't alter it any further." Hehe ;-)
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 2, 2006 21:56 UTC (Mon) by stevenj (guest, #421) [Link] People were burning code into ROM 20 years ago, but now the FSF wants to dictate how the hardware is made If you're going to criticise GPLv3, try to do so without distorting the facts. The DRM provisions don't prevent ROMs. They only affect the situation where the hardware manufacturer can upgrade the software but the user can't, which is relatively new. The FSF has explained this repeatedly: But if there really are regulations which forbid software on certain devices from being modified once it's installed, it's still possible to use software licensed under the GPL — simply burn the software into a ROM.
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 3, 2006 0:12 UTC (Tue) by mingo (subscriber, #31122) [Link] but now the FSF wants to dictate how the hardware is made If you're going to criticise GPLv3, try to do so without distorting the facts. Your (rather impolite) statement is directly contradicted by pro-GPLv3 people in this very thread acknowledging that indeed the FSF wants to dictate certain aspects of how the hardware is made. (by forbidding GPLv3 on such hardware) Of course what this will result in is the non-use of GPLv3 software, not the change of hardware - so what will be achieved is only harmful to Linux and free software in general. The only entities that will win from the DRM language are Hollywood and Microsoft.
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 3, 2006 2:15 UTC (Tue) by stevenj (guest, #421) [Link] Your (rather impolite) statement is directly contradicted by pro-GPLv3 people in this very thread acknowledging that indeed the FSF wants to dictate certain aspects of how the hardware is made. (by forbidding GPLv3 on such hardware) My statement was directly referenced to the authors of GPLv3, not to your paraphrasing of "pro-GPLv3 people". Moreover, I never suggested that the FSF didn't want to restrict certain aspects of the hardware design. All I said was that the FSF has clearly stated it has neither the intention nor the desire to restrict the use of ROMs, which had been falsely implied above. (This is also backed up by a direct quote from Eben Moglen in another post of mine above.) If you find it impolite to point out that the facts are being distorted by certain posters, I find the distortion itself even more impolite.
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 4, 2006 6:42 UTC (Wed) by svkelley (guest, #37299) [Link] So, letś say you have some GPLv3 code you wrote that say deals with rotating images. Caterpillar has a new vehicle that runs embedded Linux for its driver's display. The software is used for the backup camera. if Caterpillar doesn't allow you access to their firmware with an unsigned loader, you have the right to revoke use of the code?
This is bull. The original intent of the code had nothing to do with tractors or what ever. Again, I feel this whole motivation is without merit, spiteful, and dictatorial.
Why would they care if you change the code? Posted Oct 4, 2006 9:41 UTC (Wed) by kleptog (subscriber, #1183) [Link] Where does this "right to revoke" come from? You don't have the right to do anything, the Caterpiller violated your licence. If you don't like that effect, don't use that licence. Duh.
My real questions are:
1. Why would the people who made the tractor not want to give you the code? It doesn't matter to them at all, does it?
2. Why would they care if you changed the installed code? In your example I can't even see why they'd want to stop you making your own changes. Changes would void the warrenty obviously, but that's about it... What is this "signed bootloader" acheiving in the Caterpillar?
Similarly, I can't imagine why a TiVo-like device would want to stop you changing the userland GPL code. They control the kernel, so letting people do whatever they like in userspace seems like the obvious thing to do.
Why would they care if you change the code? Posted Oct 4, 2006 14:17 UTC (Wed) by sepreece (subscriber, #19270) [Link] Caterpillar would not want you to be able to modify the code in their device because if you did, and ran over somebody because the device failed in use, the victim and the driver might both choose to sue the manufacturer for liability in the accident. And they might very well win.
For Tivo there are two issues: (1) their contract with the content owners almost certainly requires them to make a good-faith effort to assure that there is no point where a user can get access to unencoded content and (2) if someone installed software that allowed them to copy content out and subsequently posted such content for sharing, Tivo might well be sued for liability for the claimed losses of the content owner(s).
Companies have to factor their potential liability into the cost of using components. If they believe the financial risk of using the components is unacceptable, they'll go elsewhere.
Why would they care if you change the code? Posted Oct 5, 2006 23:11 UTC (Thu) by svkelley (guest, #37299) [Link] Well said. And when companies go elsewhere, Linux loses.
Why would they care if you change the code? Posted Oct 7, 2006 14:35 UTC (Sat) by nim-nim (subscriber, #34454) [Link] Think it will fare any better if DRM is generalized?
Hint:
Why would they care if you change the code? Posted Oct 9, 2006 14:18 UTC (Mon) by malor (subscriber, #2973) [Link] I'm not sure whether or not this was sarcastic, but if a company doesn't choose Linux in its DRM-locked product, what does Linux lose, exactly?
You are willing to sacrifice your freedom for a few points of *market share*? WTF are you thinking? The whole point of an open source operating system is to be free, except when freedom would result in a few less locked-down systems running it?
Yes, requiring DRM keys will reduce Linux's market share. But the whole point of a free-software operating system is that market share doesn't matter. It's irrelevant. You're giving away the one thing in the whole deal that really matters for a shiny but meaningless bauble.
I'll give you three beads and a blanket for Manhattan. Deal?
Why would they care if you change the code? Posted Oct 6, 2006 17:37 UTC (Fri) by spitzak (guest, #4593) [Link] That's nonsense. Caterpillar would win the case, as you modified their device without their authorization!
Why would they care if you change the code? Posted Oct 6, 2006 19:01 UTC (Fri) by sepreece (subscriber, #19270) [Link] Most companies are willing to go to significant lengths to lower the probabilities. Juries do sometimes do things you would not expect. The cost of going to law are substantial, even if you win.
I can say that I know of design decisions taken specifically to avoid liability potential, over things with much less potential impact that replacing major parts of the operating software.
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 4, 2006 9:58 UTC (Wed) by nim-nim (subscriber, #34454) [Link] > Your (rather impolite) statement is directly contradicted by pro-GPLv3> people in this very thread acknowledging that indeed the FSF wants to > dictate certain aspects of how the hardware is made. (by forbidding GPLv3 on > such hardware)
1. Who holds the DRM keys do not change how the harware is made.
What it stops has nothing to do with hardware and everything to do with software distribution, which was the GPL function all along
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 4, 2006 14:27 UTC (Wed) by sepreece (subscriber, #19270) [Link] While the specific restrictions are written in terms of software distribution, the result is the same, a requirement for the right to update a particular device, if that device is updatable. There's no way to look at that without seeing it as extending some degree of control over the particular device. It's not enough that the user be able to run the software on some hardware device, she has to be able to run it on the particular device in question.
FSF is SOLVING a problem that did not exist 10 years ago Posted Oct 5, 2006 2:40 UTC (Thu) by jmorris42 (subscriber, #2203) [Link] > GPLv3 does not forbid GPLv3 code use on DRM hardware, provided you give the users the keys
Everyone seems to be forgetting there is another option here. Tivo doesn't need to hand out their signing key to be GPLv3 compliant. Instead they could add one jumper to the board. Put a cap on it, apply power and it does three things: 1) erase the keyring and 2) permit loading unsigned binaries and 3) voids the warranty and makes the machine unable to obtain services from Tivo.
I think they could make a strong argument that this complies because a Tivo is both a hardware sale and a subscription service. It is somewhat reasonable for a service to be restricted to controlled hardware/software platforms. Installing the jumper would allow installing MythTV on the hardware but it wouldn't be a Tivo anymore.
Of course this is a bad example since Linux is going to remain GPLv2.
FSF is creating a problem that never existed! Posted Oct 2, 2006 9:01 UTC (Mon) by atai (subscriber, #10977) [Link] The fact that someone named Linus Torvalds can manipulate people against an open discussion process with his own "karma" (in his own words) is a parody of free software, or open source, if you will.
FSF is creating a problem that never existed! Posted Oct 2, 2006 9:31 UTC (Mon) by mingo (subscriber, #31122) [Link] The fact that someone named Linus Torvalds can manipulate people against an open discussion process [...] You are attacking Linus (unfairly) instead of replying to the issues i raised. One of those issues is right in your attack: "open discussion process". Why is the GPLv3 process only an open discussion process (like most of Microsoft's Shared Source is), why not an open decision process (like GPL-ed code and Linux itself is)?
Linux follows a closed decision process Posted Oct 2, 2006 10:11 UTC (Mon) by man_ls (subscriber, #15091) [Link] So now "Linux is an open decision process"? Excuse me, but I don't find the "join" or "vote" buttons on kernel.org. Whatever happened to benevolent dictators? Furthermore, how come "GPL'd code is an open decision process"? Excuse me again, but if I write some piece of code I get to decide the license, not some "open decision process". If I modify GPL'd code and distribute it, I can hardly choose the license.What did you exactly mean? It is hard to follow a logical discussion if factoids like these are thrown around at every turn without explanation.
Linux follows an open decision process, and you can fork it if you dont like it Posted Oct 2, 2006 10:59 UTC (Mon) by mingo (subscriber, #31122) [Link] So now "Linux is an open decision process"? Excuse me, but I don't find the "join" or "vote" buttons on kernel.org. It's called the /bin/cp command and it's very easy to do. You do: cp linux-2.6.18.tar.bz2 my-forked-linux.tar.bz2 or if you have Git installed, do: git clone git://kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ my-forked-linux/ Linus has no monopoly on Linux. You are free to fork Linux anytime. In fact _I myself_ have a fork of the Linux kernel currently, and if Linus doesnt take that code for abitrary reasons then i will keep that fork and it might grow into something larger. (this has not happened so far, so i'm using my fork not as a maintainance fork but as a technical fork, to keep my latest stuff available to testers) Yes, ask Linus and he'll readily call himself a dictator because: he does not want people to trust him, he wants people to trust the result of his work - and people can walk away and continue the work if Linus messes up. Linus will also readily call himself a stupid moron, so what? And yes, this basic, symmetric competitive pressure of a fork has forced Linus to stay sharp and honest during all these years. This is not just a theoretical possibility, there were specific instances in the past where Linus messed up and kernel developers showed discontent - but Linus adopted to those concerns and kept a hostile fork from happening. This same competitive pressure forced RMS off the maintainership of some GNU projects when others just forked his code and did a better job. Now where can i fork the GPL 'next version' decision process and create the next version of the GPL myself, without the huge barrier of having to write 350 million lines of code from scratch or having to convince all the authors that they accept my license and relicense to it? (where the former is probably easier than the latter) That basic lack of competitive pressure on RMS has allowed him to stay unchanged during all these years. He is now using the "or later version" and "similar in spirit" legal wildcards (that RMS has put there himself and which clauses contributors left in the COPYING file due to trust or due to laziness), to do something that no person on this planet can do: change the licensing dynamics of 350+ million lines of code. Without any competitive pressure whatsoever. The "openness" of this process would make Microsoft proud i think ;-)
Linux follows an open decision process, and you can fork it if you dont like it Posted Oct 2, 2006 12:18 UTC (Mon) by dmantione (guest, #4640) [Link] Let me show how to make your own GPL:wget http://www.gnu.org/licenses/gpl.txt mcedit gpl.txt ... and modify to taste. However, we're of course talking about Stalman's GPL, and Linus' kernel. Linus is the primary kernel maintainer and, to say it blunt, does so in a dictatorial manner. Of course Linus listens, but ultimately nothing gets in the kernel (Linus' kernel) that Linus doesn't like. It is exactly the same with the GPL. The FSF listens, but ultimately nothing gets in that the FSF doesn't like.
Linux follows an open decision process, and you can fork it if you dont like it Posted Oct 2, 2006 13:15 UTC (Mon) by mingo (subscriber, #31122) [Link] Let me show how to make your own GPL: your example is inapposite, it does not reply to the issue that i raised. See the highlighted portion of my sentence you replied to (and which you did not quote in your reply): Now where can i fork the GPL 'next version' decision process and create the next version of the GPL myself, without the huge barrier of having to write 350 million lines of code from scratch or having to convince all the authors that they accept my license and relicense to it? (where the former is probably easier than the latter) your suggestion to 'fork' the GPL will only fork the 340 lines of the license text itself! It does not 'fork' the 350+ million lines of codebase that is tied to the current GPL version. (That bond is either via trust or via laziness - both of which brings with itself moral responsibilities.) my suggested solution to fork Linux will fork the whole thing, all ~7 million lines of it. All currently active developers could go over to the fork in a matter of a single day, if they wanted to. There are no barriers whatsoever to do this - and it's being done quite frequently, sometimes to prove Linus wrong. Of course i never suggested it should be possible for a single person to fork the GPL license, together with the whole codebase. That would be insane. In fact, what i suggest is that it is so insane that no-one, not even RMS himself should have the legal power to unilaterally and in essence retroactively change the practical meaning of hundreds of thousands of contributions! It is a very simple point that no-one from the FSF side was willing to confront heads-on so far. Perhaps because the thought is uncomfortable to them and the moral implications are so clear? Perhaps because giving up power and "letting the community go" its own way is so hard to do?
GPLv2 or, at your option, any later version Posted Oct 2, 2006 13:28 UTC (Mon) by man_ls (subscriber, #15091) [Link] Again, since the option of choosing GPLv2 or any later version lies on you, the recipient of my gracefully licensed code, it is you who makes the decision, not Stallman.I don't think it is such a big deal. Don't like v3, then stay with v2.
GPLv2 or, at your option, any later version Posted Oct 2, 2006 14:04 UTC (Mon) by mingo (subscriber, #31122) [Link] Again, since the option of choosing GPLv2 or any later version lies on you, the recipient of my gracefully licensed code, it is you who makes the decision, not Stallman. I think you are again skipping the fundamental moral question. (I dont think you are doing that intentionally, so please dont take this as an attack of any sort.) Yes, of course the contributor decided under which license the code was released. He might even have left the "or later version" and the "similar in spirit" language in the COPYING file for one of the following factors: - fully intentionally, understanding all the legal and moral implications of that decision and leaving the power to change the license with the president of the FSF, or - due to misunderstanding the goals of the GPL and the legal implications of the license, not being a lawyer himself, or - due to laziness, because legaleese is boring stuff when we can do some real coding. So my question is: does your position reduce to: "You made your decision when you released the code, now deal with the consequences. The president of the FSF has the legal power to do things with your contributions you possibly never thought of before - it's really your fault you did not read the legal fineprint and let it happen!"? Or do you agree with me that the president of the FSF is in a unique legal position (and has the unprecedented legal power) to change the license affecting the contribution dynamics of 350 million lines of code instantly? Do you agree with me that such huge power brings with itself a minimal moral obligation to at least /understand/ and adopt to the position of the community that created that codebase, instead of trying to advance his own moral position? Or if that adoption is not possible, to voluntarily give up his unique legal powers (which powers are contrary to the philosophy of free software itself) and remove the "or later version" language from the license and let people only pick a specific version of the GPL, hoping that people would consciously pick up his new version of the license for new contributions?
GPLv2 or, at your option, any later version Posted Oct 2, 2006 15:48 UTC (Mon) by madscientist (subscriber, #16861) [Link] I understand your point, and agree with it to a certain extent. But let us turn this around: is it your contention, then, that because some developers did not fully grok the intent and ideals of RMS and the FSF when they licensed their code, that now RMS and the FSF should be permanently enjoined from pursuing their goals as they see them? That they should just pack it in and go home because their hard work and unwavering belief and advocacy (for little reward and often in the face of ridicule) for over twenty years has been misunderstood by a vocal subset of the community?
The idea that RMS and the FSF should subordinate themselves to the "will of the community" is such an obvious non-starter that I can't believe it's being seriously discussed. They are where they are today, and the GPL is where it is today, precisely BECAUSE they had a moral vision to which they steadfastly held, and they did not allow that vision to be diluted by people arguing for practicality or appeasement. You may not agree with them: many don't. But to the extent that ANYONE is surprised or dismayed by the fact that they are not allowing some kind of ultra-democratic "vote for your favourite clause" in the GPLv3, they are being naive IMO. Although the FSF wants to make the best license they can, and so they are soliciting input from every side, there was never any possibility that the GPLv3 would contain any language which did not align precisely with the vision of the FSF... how could it be otherwise?
The fact that some didn't understand that vision or where it might lead in the future is quite understandable. But saying that because of this, the FSF has some sort of obligation to abandon its principles and vision seems unfair... and, frankly, given what I know of the people involved, it will never, ever happen.
GPLv2 or, at your option, any later version Posted Oct 2, 2006 19:40 UTC (Mon) by cventers (subscriber, #31465) [Link] Ingo,
I'll start off as some others have and say that I have a lot of respect
There are those of us that identify with "Free Software" over "Open
As awesome as the Linux kernel is - fantastically portable, capable and
When Linus announced that Linux would not convert to GPLv3, there was
I hear you that you are concerned about the power that the FSF wields
The trouble with many of the attacks I've seen on RMS and the FSF is that
And the really big, important point here is that RMS can't force anyone
Although I respect your concern about the moral question I don't share
I agree with you that the concern of some GPL users should be addressed.
So why does the "or any later version" thing really worry you?
1. Joe can take my code and distribute it under the GPLv3, and I don't
- Why does this matter? This doesn't stop you from (a) changing your
2. Joe can take my code, modify it, release the mods only under GPLv3,
- Joe is voting with his code!
Is there really any serious contention over this license other than that
I share your concerns that we're going to suffer some pain over this
But you know, I wouldn't be surprised if I saw one or more code forks
And if some projects fork, tough! People who fork are voting with their
GPLv2 or, at your option, any later version Posted Oct 3, 2006 7:23 UTC (Tue) by jimi (guest, #6655) [Link] This is exactly how I feel. If anything, the FSF is giving both the developers and the end users more choices and doing their absolute best to protect freedom - freedom for both the developers, hardware manufacturers, and users. If some copyright holder feels that the GPLv3 is wrong, then simply remove the language permitting any later version. This is not hard or even reproachable. My little GPLed project will be licensed under the new version.
GPLv2 or, at your option, any later version Posted Oct 3, 2006 16:02 UTC (Tue) by mingo (subscriber, #31122) [Link] you need to remember that you guys aren't the only software project out there. Oh absolutely! Two quick points: Firstly, we "kernel guys" (which includes some exceptions, the kernel developer community is not homogenous regarding this topic - as it is rarely homogenous on any other topic to begin with ;-) are the nearest to the hardware (almost by definition), so we will be amongst the first ones who will feel the bad effects of the GPLv3 limiting hardware design. The FSF justification for the DRM language sounds nice and fine, i'd like the DVD monopoly to go away just as any other free software developer, but i also realize that: - embedded manufacturers are /forced/ to use DRM most of the time by external factors (such as licensors of DVDs, licensors of pay-per-view content that people want, or licensors of GPS maps), so when they are faced the choice of removing DRM or removing Linux, they'll remove Linux. There's just no way we can win in this scenario, and the result is less freedom. Needless to say, i'm not happy about that angle. - even accepting that we need to do something about DRM (and i dont think we /can/ do anything meaningful about DRM - hence we shouldnt even try, due to the clear danger of collateral damage) the FSF chose an awful solution to solve the DRM problem: they now propose to control works created independently of GPL-ed code (such as hardware), by creatively including portions of those works (certain "keys") in the definition of "Source Code", and thus forcing the release of such keys (or the ceasing of the use of such keys) when GPL-ed code is distributed together with that independent creative work (the hardware). This sets a bad precedent because the GPLv2 never did this - the GPLv2 was very clear that our work is ours and your work is yours (as long as it's not based on our work). Trying to use distribution related legal powers to affect independent works is worthy of SCO and the MPAA, not of the free software community. It is also a material deviation from the spirit of the GPLv2. I find such a deviation from spirit and morals far more dangerous than any damage DRM could do to us. Secondly, i believe most of the non-kernel free software projects are watching this from an armchair so to speak, without being directly involved in the issues around hardware. While the current GPLv3 changes are mostly directed at the kernel (for example the Tivo bootloader checks the signature of the kernel it loads - not of userspace programs), but non-kernel projects could be affected by future versions of the GPL, come GPLv4 - and the precedent of compromising on the spirits of the GPLv2 and removing freedoms has already been done in the GPLv3, so it might be too late for you to object at the time of the GPLv4. For example, would you be content with the GPLv4 requiring that only GPL-licensed code be distributed on a piece of hardware? As per the logic articulated in connection to the proposed GPLv3 changes, such extra restrictions of distribution freedoms are possible. So if you see anyone suggest that we kernel developers are out there to compromise on freedoms it's the opposite: we are objecting against the GPLv3 restricting certain freedoms, and we are also objecting against certain measures on the grounds that the damage caused by those measures will be far larger than the supposed benefits they bring. Remember: if unfixed, the GPLv3 does not remove or impact DRM in any way, but it very much removes some of our freedoms! Plus, i personally like some parts of the GPLv3: for example the patent language (but i also like the more robust formulation in other areas). So it's not all bad, but right now it's more bad than good in our opinion. That was expressed in the vote of the top kernel contributors too.
Please participate, for real! Posted Oct 3, 2006 18:12 UTC (Tue) by cventers (subscriber, #31465) [Link] Ingo,
I'm not sure I agree with you about what power we actually have over DRM.
The anti-DRM provision has really two aims. One is to keep free software
To explain then why I think differently, I think that when Eben Moglen
Proprietary forms of production are beaten. And I know this is probably a
1. We don't want to see our code abused and artificially locked up
I say these things in the midst of developing a project (trying to get a
And you know, I'm not even sure that manufacturers in 2006 want to lock
So I suspect that you disagree with me, perhaps on some factual grounds
The reason I replied to you is over the same reason that I got pretty
So we're talking about GPLv3 in context of the Busybox maintainer
> Please stop this licensing madness before it's not too late! We have
If you don't like GPLv3, please say so. But please do so in a way that is
I'll say one more thing. Eben has re-invited the participation of kernel
Please participate, for real! Posted Oct 3, 2006 21:40 UTC (Tue) by sepreece (subscriber, #19270) [Link] I completely agree that the kernel developers should post their thoughts on the comments site. However, I'm not sure I see a fundamental difference between lobbing press releases and lobbing comments. If there were a discussion in the comments process, I might feel differently, but since the most we can do is post comments that go into a back-room drafting committee, I'm not sure what the real difference is.
Please participate, for real! Posted Oct 3, 2006 21:59 UTC (Tue) by cventers (subscriber, #31465) [Link] I can't speak for Eben but it sounds to me like what the FSF was hopingfor (and what I and others hope happens too) is that concerned kernel developers will contact them directly so as to open a line of communication on the kernel developer's terms. The comment website is designed to allow anyone off the street to walk up and provide useful input; this was done to lower the barrier to entry and because it would probably be prohibitively difficult to involve _everyone_ on a deeper level.
Obviously, the kernel developers represent a body of very important GPL
So what do you say Ingo? Might we be able to con you and some of your
Keys and hardware Posted Oct 3, 2006 18:39 UTC (Tue) by man_ls (subscriber, #15091) [Link] Ingo, just a(nother) fine point.[...] they now propose to control works created independently of GPL-ed code (such as hardware), by creatively including portions of those works (certain "keys") in the definition of "Source Code".How come the cryptographic keys are now part of the hardware? Is your key part of your house? Part of your door, or even part of your lock? A crypto key is just a number; it is a necessary piece of the algorithm to install the software onto the hardware, true, but the same is true of any ./configure scripts. Are they part of the hardware too?
GPLv2 or, at your option, any later version Posted Oct 2, 2006 21:02 UTC (Mon) by alonso (subscriber, #2828) [Link] Hi Ingo, I agree with you on the moral obligation of FSF. I think that in the end GPLv3 will be irrelevant, in fact it can be relevant only if linux will be licenced under it... of course in my opinion. But that said, I really don't see the reason to allow DRM infected device to use Linux. I see no difference from source+DRM from binary only. Ok you have the source you can modify it, but you never have the ability to use the modified kernel on you device. But of course THEY have it. Why are kernel developer supporting this kind of use of their work?If in the end all device will be equipped with DRM you will have a lot of source to use like toilet paper :)
Thank you for you hard work!
GPLv2 or, at your option, any later version Posted Oct 2, 2006 21:26 UTC (Mon) by mingo (subscriber, #31122) [Link] Hi Ingo, I agree with you on the moral obligation of FSF. I think that in the end GPLv3 will be irrelevant, in fact it can be relevant only if linux will be licenced under it... of course in my opinion. I'm a bit more pessimistic, but hey. My worry is that the pure "inertia of laziness" that infests all of us developers will just cause the blind copying of "GPLv3 or later" COPYING files and will gradually increase the pressure on "GPLv2 or later" projects to go "GPLv3 or later" too. And i fear we might lose many good contributors along the way, once they feel their moral trust has been abused. They'll just be disgusted by the constant flaming and bickering and will leave. Just count the number of times GPLv3 proponents called Linus' arguments "FUD" (without bothering to actually argue point by point), to get a feel of the times to come. I see no difference from source+DRM from binary only. Ok you have the source you can modify it, but you never have the ability to use the modified kernel on your device. Here i'm a bit more optimistic than you :-) Just watch current market trends, where is DRM used or where will it be used? Only in limited spaces where there's content that people are crazy about and that the content owners want to protect: DVDs, HD-DVDs, Xbox, PS3. (It shows up on desktop CPUs too, but in its little isolated corner, not affecting the generic programmability of the hardware. Good enough to play HD-DVD, but not annoying enough to disable Linux.) Note what they are not trying to do: they are not trying to do DRM-ed Linux hardware designs where people are interested in Linux content. And the reason is simple: DRM is expensive and cumbersome, for everyone involved, hardware maker, software developer and user alike. And that wont change, no matter how much legislative power Hollywood has. Hardware makers are very much aware of this and they are resisting DRM in every place where Hollywood's content does not matter. (and they are able to do this because where Hollywood's content does not matter there Hollywood has no licensing power. Hollywood has yet to amend the Constitution.) Furthermore, there is not much we can do, because Tivo exiting the PVR market is precisely in the line of Microsoft's and Hollywood's intent! They want small players like Tivo to exit the market, very much. So by disabling Tivo we /help/ Microsoft and Hollywood. (again, the reason of that situation is that people dont want the Linux in Tivo, but Hollywood's content) So the solution: stop worrying about the Tivo and about the Xbox. You might see DRM in desktop hardware too, but it will be in its own corner and wont really affect Linux. Rather work on making more people want Linux. Work on replacing Hollywood's content by contributing to the Creative Commons project. And the path to the hearts of minds of people isnt via adding stupid key restrictions to the license that does nothing but annoys hardware makers who are trying to adapt Linux, but by building technology and content that people want.
GPLv2 or, at your option, any later version Posted Oct 2, 2006 22:41 UTC (Mon) by nim-nim (subscriber, #34454) [Link] > And the reason is simple: DRM is expensive and cumbersome, for everyone> involved, hardware maker, software developer and user alike. And that > wont change, no matter how much legislative power Hollywood has.
Unfortunately as soon as Hollywood legislative power makes DRM mandatory for classes of devices manufacturer opposition will vanish. Because this will promote DRM from "cumbersone feature" the no-name chinese competitor does not bother with to "expensive feature" the customer is forced to buy.
The legislator does have the power to remove competition, and competition is the only reason companies can not thrive on ill-advised features and products. You don't hear hardware companies complaining in countries which tax DVDs or hard drives. They don't care as long as their competitors are treated the same way. Because if it's the case they can safely pass the costs on customers.
Actually Hardware/software companies would love a DRMed world - it would offer all sorts of forced obsolescence "opportunities".
GPLv2 or, at your option, any later version Posted Oct 3, 2006 0:03 UTC (Tue) by mingo (subscriber, #31122) [Link] Unfortunately as soon as Hollywood legislative power makes DRM mandatory for classes of devices manufacturer opposition will vanish. So your solution: exclude all of Linux from those markets? Now how will that solve the problem?? The real solution is this: allow people to actually use DRM where mandated by either the industry, by laws or by convenience, because allowing Linux in such scenarios fights the content monopolies by giving people a bridge into free content. Also work on free content and eventually enable a new class of devices that need no DRM, because they only play free content! If we are any good, those devices will emerge, and Hollywood has yet to amend the Constitution to forbid such devices. (DMCA-alike laws only operate on hardware devices because the content industry's content is used on those devices.) If we are not good enough to create free content, then nothing we put into the license will prevent Linux from failing in those markets. The DRM provisions will just accelerate that failure. But if we are good at creating free content then allowing people to bridge from the closed world into the free world helps us and them. The DRM provisions of the GPLv3 will only make it harder. If we are unlucky they might even tip the balance from "slow success" into "slow failure".
GPLv2 or, at your option, any later version Posted Oct 3, 2006 6:42 UTC (Tue) by nim-nim (subscriber, #34454) [Link] Clear legal opposition to DRMs by a large GPLv3 codebase is actually a pretty good way to stop or limit the scope of DRM laws (go read the transcripts of pre DMCA/EUCD discussions they're enlightening)
Once DRM laws are enacted worldwide and win some years of legitimacy expecting to create free devices is illusory. Hollywood knows pretty well their laws will only stand if no open devices can compete with DRMed ones. They are doing all they can (and mostly succeeding BTW since people like you let them lobby alone) so DRMed is made mandatory not on hardware that manipulates their content but on hardware that *may* manipulate their content. Which happens to cover all content devices (and more), since they can always argue there is no technical difference between free content and pirated drmed content.
I don't see any manufacturer doing anything but blanket DRM once DRM is mandatory, since DRM smart enough to distinguish between closed and open content would be
You can make great code by pooling the free time efforts of many individuals worldwide, you can not make great hardware without someone owning an expensive factory somewhere.
Expensive factories are a lawsuit target.
GPLv2 or, at your option, any later version Posted Oct 9, 2006 14:48 UTC (Mon) by malor (subscriber, #2973) [Link] If they don't use Linux, so what? Does Tivo give you anything?
Some customers are bad. Some market share is share you don't want. What benefit is there for you in having DRM-locked Linux kernels on the market? From this perspective, it looks like they just stole your code and locked everyone out of their device. They're bad customers, market share that costs more than it's worth. For a few more share points, you trade away your freedom to fully use any device that uses your code.
The GPL code base gets bigger every year, and harder to compete with. Success is absolutely inevitable, if you are willing to be patient enough. At some point, the base of GPL code will be so enormous and so *good* that it will be economic suicide to try to compete with it. That may take another generation, maybe two. But eventually, there will simply not be room for closed licenses on mainstream products anymore.
The problem is that you're not thinking big enough. If you think in a multigenerational timeframe, the Linux kernel is not *that* critical. Code can be replaced, but lost freedoms are damnably hard to get back. Changing the GPL to suit any one project, even one as large and important in the present day as Linux, will have unpleasant ripple effects for decades.
It appears that you want the project you've put your whole life into to be wildly successful. And maybe you were never one who particularly cared about this particular issue... maybe it's okay, from your perspective, for someone to sell you a device running your own code that you're not allowed to change. Or maybe you're willing to overlook that if it means your project becomes dominant in the marketplace.
But for the FSF, whose goal is software freedom, not the success of any particular project, it would be very foolish to do what what you want. Their goal is freedom for generations; yours appears to be success over the next few years.
I wish you both well, but IMO, the FSF's goal is important to the entire world, where yours is important primarily only to Linux kernel devs.
GPLv2 or, at your option, any later version Posted Oct 12, 2006 3:26 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link] tivo gave us their code (it turns out that not much of it is wanted, but that's not a requirement)
as a result tivo boxes are extremely hackable, once you jump through the initial hoops to defeat the encryption
GPLv2 or, at your option, any later version Posted Oct 12, 2006 8:04 UTC (Thu) by malor (subscriber, #2973) [Link] Right, but with Trusted Computing, you will not be able to do that anymore. If the kernel isn't signed with Tivo's private key, it won't run on that hardware, period.
Is it okay if they put chains on stuff if you know how to break them? What happens when you don't know how to break them anymore? You can go from A to B almost overnight, and if you don't have any legal protections in place, don't you think they've stolen your code?
It strikes me that just the ATTEMPT to steal your code, even though they may not succeed, is highly noxious, and something to be prevented.
Think of the DRM provisions in GPL3 as a life preserver. The real things are a little awkward to wear on a boat, and make your day a little less fun. But if you need one, you REALLY need one, and you'd better have put it on ahead of time.
GPLv2 or, at your option, any later version Posted Oct 13, 2006 2:13 UTC (Fri) by sepreece (subscriber, #19270) [Link] You describe it as "stealing" when a manufacturer uses your code in a device, but doesn't give you the right to modify it in the device. How is that any more "stealing" than, for instance, using it inside a company, embedding it in a device you can't afford or just don't want, or putting it in a device in ROM so that it can't be modified?
If you choose to consider it unfair, that's a choice that I think you should be free to make, but it's no more "stealing" than unauthorized copying of content is "stealing" or "piracy".
GPLv2 or, at your option, any later version Posted Oct 13, 2006 19:21 UTC (Fri) by malor (subscriber, #2973) [Link] Of course I describe it as stealing. The whole point of copyleft/GPLv2 is that the original author of the code maintains full rights, but gives up some of those rights voluntarily. In exchange, all other users of the code cannot reserve more rights for themselves than people they give it to.
That's really it. That's the contract. If you write Neato Program A, and kindly give it away under the GPL, I can build on that and make it into Neato Program B. But I can't distribute it in such a way that my downstream users can't add on to make it Neato Program C. And none of us can distribute it in such a way that YOU can't take our changes, incorporate all of them into Super Neato Program D, and then freely distribute that as well.
If I, as a device manufacturer, want to make a non-modifiable device that I can't change, I can use GPL code to do that. But I can't reserve rights for myself that my end-users don't have. If I can modify the device, they must be able to also.
Tivo, in other words, is stealing code. They are taking the kernel code and releasing a locked device with it; they are using GPLed code with a hardware addition to reserve rights for themselves that their end users don't have. If they want to release a locked device, that's fine, but then they can't piggyback on the work of thousands of volunteers. They have to create the device themselves, with their own code, or buy it from someone that has the right to release it under a non-GPL license.
If you argue to the contrary, you're in favor of giving hardware manufacturers special powers to enslave those who write software. You're relegating the software guys to second-class citizenship.
GPLv2 or, at your option, any later version Posted Oct 14, 2006 20:22 UTC (Sat) by sepreece (subscriber, #19270) [Link] As you must know, if you've been paying any attention to this issue, many key kernel developers, among others, disagree with you that this is even unfair, let alone illegal. Note also that the manufacturers, in your example, are NOT witholding the code, only the right to modify the device by installing new software. Note also that they generally do NOT retain the right to modify the software in the device, since they generally no longer have access to the device. The only way they can install modified software is if you let them, either by asking them to ("run iPod updater") or by subscribing to a service that may load new firmware (like Tivo service). Since they are then acting as the owner's agent, I'm not sure there's really an issue here at all...
Referring to it as "stealing", in any case, is just wrong. Copyright infringement is not theft, regardless of what the RIAA and MPAA would have you believe.
GPLv2 or, at your option, any later version Posted Oct 14, 2006 22:51 UTC (Sat) by malor (subscriber, #2973) [Link] Yes, I realize that key kernel developers don't like this. However, in watching their verbal gyrations on the issue, I have come to the belief that this is not because of any particular ideal of free software. Rather, it appears to be because the GPLv3 will slow the adoption of their pet project and, thus, the spreading of their fame and future employability.
The whole point of the GPL is that I can't use your code, distribute it to others, and keep rights to myself that I don't give to my end users. If I load it onto a device, but retain the right to modify software in the device, they must also have that right. And your assertion that I can only install modified software with their permission is incorrect. The fact that most manufacturers have been polite and done so, does not mean that they are required to. If I'm the manufacturer of a Tivo-esque device, I do not have to ask for any permission from anyone to update 'my' device.
And no, calling it stealing isn't wrong. Copyright infringement is not theft, because the producer of music/movies/whatever isn't deprived of anything, except possibly a potential sale. But in the case of software, part of the original agreement is to allow end users (including the original author of the code) full rights to any distribution of that code.
Distributing it in a locked hardware device does indeed deprive the original developer of something, the ability to use the device in the way he or she wants. 'Stealing' is perfectly appropriate; they have taken something from you and not fulfilled their primary responsiblity, which is to give end users the exact rights that they have. You have a clear and demonstrable loss.
If the FSF bends to the pressure of the loud kernel devs, they are trading away the future of their entire movement for a little near-term success for one project. They permanently relegate software developers to second-class citizenship behind hardware manufacturers.
I think they know that, and I hope they will refuse to bend on this issue.
GPLv2 or, at your option, any later version Posted Oct 3, 2006 6:46 UTC (Tue) by JoeF (subscriber, #4486) [Link] Unfortunately as soon as Hollywood legislative power makes DRM mandatory for classes of devices manufacturer opposition will vanish.
And the result will be that the manufacturers will use Windows or other non-free software. The FSF will have reached their goal, no GPL software on such devices. Unfortunately, it will be a hollow "victory", as there will be no free software on these devices.
GPLv2 or, at your option, any later version Posted Oct 3, 2006 7:07 UTC (Tue) by nim-nim (subscriber, #34454) [Link] And there will be a clear victim of DRM laws which will cause legislators to think, instead of GPL software being progressively and quietly killed on those devices, because no one but the manufacturers can deploy code on them and no third parties are interested by GPL code if there's no harware to run it on.
And you can go complain at the legislator then, you won't have any bargaining power left.
HDCP cards are making their way on computers. So we're losing displays. If you believe the open computer will resist long if no one opposes Hollywood you are a fool. GPLv2+DRM happens to enable corporations to do the BSD on GPL code they wanted all along
GPLv2 or, at your option, any later version Posted Oct 5, 2006 20:24 UTC (Thu) by AJWM (guest, #15888) [Link] > which will cause legislators to think,
What planet are you on? Sounds nice, legislators that might actually think, even if it does take some force.
If (hypothetically) Tivo were to die because a GPLv3 Linux was no longer allowed on it, that would NOT be seen as "a clear victim of DRM laws", but as "a victim of the capriciousness of those leftist hippies in the free software community", and held up as a cautionary tale against using GPL'd software.
GPLv2 or, at your option, any later version Posted Oct 6, 2006 7:32 UTC (Fri) by nim-nim (subscriber, #34454) [Link] > > which will cause legislators to think,
> What planet are you on?
A planet were I do actually read reports of the parliament debates on subjects I'm interested in.
The GPLv3 may seems strange and surprising to some. For people who followed the DADVSI/EUCD debate in France (of which the FSF was one actor BTW) it's a very logical development.
GPLv2 or, at your option, any later version Posted Oct 2, 2006 21:21 UTC (Mon) by man_ls (subscriber, #15091) [Link] Or do you agree with me that the president of the FSF is in a unique legal position (and has the unprecedented legal power) to change the license affecting the contribution dynamics of 350 million lines of code instantly?Agreed, but I would say that the process instituted to update the GPL is also unprecedented. In 1991 Stallman sat down and wrote the GPLv2 on his own. 15 years later he is runnning an unprecedented consultation process: constant legal counselling by Moglen, FSF support, world-wide consultations, 4 conferences, industry-wide committees, and even a web-wide legal hunt for side effects. Even the opposition (as in Linus Torvalds) has admired how it was set up. Do you agree with me that such huge power brings with itself a minimal moral obligation to at least /understand/ and adopt to the position of the community that created that codebase, instead of trying to advance his own moral position?I would say Stallman has understood you quite well, and then consciously rejected your position. It is evident in the "most people don't appreciate freedom" quote that you dislike so much; or in his endless rants about "free software vs open source". If Stallman placed convenience or development process over freedom, then we (as in those who like GPLv3) would be disappointed.
GPLv2 or, at your option, any later version Posted Oct 2, 2006 23:46 UTC (Mon) by mingo (subscriber, #31122) [Link] I would say Stallman has understood you quite well, and then consciously rejected your position. And you think that's fair and morally justified? Do you now see why such an arbitrary "rejection of a position" combined with "unparalleled legal power" scares most of the kernel developers? If Linus did that, and if it mattered to enough people, they'd walk away and start another kernel tree. But there is no real remedy for RMS's behavior, and he acts accordingly.
GPLv2 or, at your option, any later version Posted Oct 3, 2006 6:43 UTC (Tue) by gmaxwell (subscriber, #30048) [Link] If he accepted your position he would reject mine. Is that morally justified?
Inaction has no special virtue... a failure to act can be just as unethical as an action.
Reasonable people can believe an argument that the FSF is not even acting in this case... but rather clarifying an intended part of the licenses which was always there.
Or, to put a systems analogy on it: You've used a module as a black box without reading the comments and documentation, and now you are aggregated because the new version of the module has had code changes so that it continues provide the intended behavior (as documented) in an environment which has changed.
GPLv2 or, at your option, any later version Posted Oct 3, 2006 8:34 UTC (Tue) by man_ls (subscriber, #15091) [Link] Do you now see why such an arbitrary "rejection of a position" combined with "unparalleled legal power" scares most of the kernel developers?I would not say the rejection was arbitrary. It has been justified repeatedly and since a long time ago by Stallman. You said above you did not agree with the GNU manifesto but found GPLv2 reasonable; that anti-DRM clauses were out of scope. I think that is just because you have seen one in action (GPLv2) but not the other (GPLv3). Your distrust is justified but, as gmaxwell said above, inaction against a visible threat would not be welcome by most people. Leaving these issues to "markets" would be like trusting Microsoft to open up their protocols. If Linus did that, and if it mattered to enough people, they'd walk away and start another kernel tree.I gather from LWN (not an expert by any means) that many people keep parallel trees; e.g. micro-kernel advocates, alternate security framework proponents, and lately yourself. Has it changed Linus' attitude towards these issues? On the other hand, many people have proposed alternative licenses, even copyleft licenses. You are free to relicense all of your extant code if you want; not in the kernel, but the kernel is not an option for GPLv3 either.
Linux follows an open decision process, and you can fork it if you dont like it Posted Oct 2, 2006 14:54 UTC (Mon) by sepreece (subscriber, #19270) [Link] Actually, you're not allowed to modify the text of the GPL. You would have to write your own similar license. Though the FSF has said they would not pursue copyright infringement against alternative licenses that copied text from the GPL, so long as they did not represent themselves as the GPL, they hold the copyright on the license text and have not formally granted a license to modify it, so you would need to start from scratch if you wanted to be legally clear.
Yes, you can modify the GPL terms Posted Oct 2, 2006 16:54 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] While you can't modify the GPL text itself, you can still use the GPL as a basis to form a license with slightly different terms. The only restriction is that you have to do it in two parts.
Forks are not part of the decision process. Posted Oct 2, 2006 12:29 UTC (Mon) by man_ls (subscriber, #15091) [Link] It's called the /bin/cp command and it's very easy to do.Do not confuse "forking" with "deciding". The decision process of Linux is closed and ruled by the benevolent dictator Linus Torvalds; you may like him, his decisions or his kernel a lot, and I will agree with you; but that doesn't make the process any more open. Forking is not part of the decision process. Of course you can fork the code, find a new name (Linux is a trademark you know), a domain and start hacking. We are not discussing that: this is a consequence of Linux being free software, which nobody discusses here. The result of a fork would not be Linux anymore. He is now using the "or later version" and "similar in spirit" legal wildcards (that RMS has put there himself and which clauses contributors left in the COPYING file due to trust or due to laziness)There is a reason this clause is there: the option of using GPLv2 or GPLv3 is not made by the original developers, but by the recipients of the code. If you want the received code to stay GPLv2, it stays v2. If you prefer to switch it to v3, you can do so. Of course there are practical problems in maintaining either version of the license, but projects can choose or just let the decision to their users. Without any competitive pressure whatsoever.Since the option of choosing either v2 or v3 (or eventually v4) is left to you, the recipient of the code, I'd say there is a lot of competitive pressure. Not to speak about the tens of equivalent licenses that have sprouted all around; for the vast majority of projects, which have a few contributors, relicensing is just a few clicks away.
Forks /are/ part of the decision process. Posted Oct 2, 2006 12:58 UTC (Mon) by mingo (subscriber, #31122) [Link] The decision process of Linux is closed and ruled by the benevolent dictator Linus Torvalds Wrong, as explained in my detailed reply further above. So per your logic the 2.6.18 kernel would not have something like priority inheritance today? (and if you reply then please reply to my post above, which gives the full context. Thanks.)
Forks /are/ part of the decision process. Posted Oct 2, 2006 13:13 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link] >Linus has no monopoly on Linux. You are free to fork Linux anytime.But he does hold a copyright to the symbol "Linux", so you can't fork and call your shiny new kernel Linux. He also is the sole, final committer to his/The Mainline Tree. It's a "de facto monopoly", for all he manages it admirably.
Forks /are/ part of the decision process. Posted Oct 2, 2006 13:26 UTC (Mon) by mingo (subscriber, #31122) [Link] Linus has no monopoly on Linux. You are free to fork Linux anytime. But he does hold a copyright to the symbol "Linux" Wrong. Symbols like "Linux" cannot be copyrighted. And as i said, i am maintaining my own fork of the Linux kernel. (The word "Linux" can be trademarked and is trademarked in some countries, and Linus so far has never used any trademark power against a fork of the kernel. But it's not even an issue, you can run a simple script over the whole codebase and replace every occurance of "Linux" with "Lanux" or whatever. In fact the Hurd project uses quite a bit of Linux kernel code and so does Xen. It's perfectly legitimate.) But you cannot do the same with the GPL, and you cannot fork the license together with the codebase attached to it. Only RMS has the huge, unprecedented legal power to do that. (as explained in detail in the posts above.)
Forks /are/ part of the decision process. Posted Oct 2, 2006 15:20 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link] Yes, I meant trademark, sorry.
Forks /are/ part of the decision process. Posted Oct 2, 2006 18:24 UTC (Mon) by Ross (subscriber, #4065) [Link] You are talking about convincing Linus to add a feature. The equivalent would be convincing the FSF to change the terms in v3. They do have a process for that, but there is no guarantee you will change their mind. I don't see the distinction at all.
Forks /are/ part of the decision process. Posted Oct 2, 2006 18:55 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link] >change the terms in v3. They do have a process for that
One of the contentions is that the process is superficial.
Again, forking is not deciding Posted Oct 2, 2006 13:19 UTC (Mon) by man_ls (subscriber, #15091) [Link] Ok, I will reply here then. So you think the decision process is open because fear of forking keeps Torvalds honest. Or even because people can keep separate branches; somehow separate branches (or even forks) make the decision process open. Even though only Linus Torvalds gets to decide what goes into the official kernel.To me that is like saying that "this basketball game is open because I get to decide who plays here; and if you don't like it there are plenty of basketball courts. It is open because if you didn't like my decisions, you might go and play somewhere else." I disagree. Keeping Torvalds honest and sharp is a consequence of Linux being free software; you made an accurate description not of an open decision process, but of an open development process. One person gets to make the decisions nevertheless, like it or not. Might be a fine point, but it is the one discussed here.
forking code /is/ deciding - except for the GPL itself Posted Oct 2, 2006 13:44 UTC (Mon) by mingo (subscriber, #31122) [Link] Ok, I will reply here then. thanks! So you think the decision process is open because fear of forking keeps Torvalds honest. Or even because people can keep separate branches; somehow separate branches (or even forks) make the decision process open. Even though only Linus Torvalds gets to decide what goes into the official kernel. Actually, Linus delegates much of that "decision power" to others. Why does he do it? Because he has no real decision power! He is only the maintainer of Linux because his decisions make sense. Linus has no legal power to keep Linux from forking - and he knows it and acts according to that fact! As a result a large number of Linux kernel forks emerged (and eclipsed) over the years, and the only reason why a fork did not take over his maintainership was that Linus was able to renew and he was able to stay ahead of the pack. Will that continue to be the case in the future? Certainly not, Linus will eventually get old and senile, like most of us. Or if he messes up earlier then he could be succeeded by whoever does it better: be that Alan Cox or Andrew Morton or someone else who is still in primary school today. And that's perfectly fine and well understood by everyone involved. (Also, you did not reply to my fundamental question: you claimed that it would be just as easy to fork the GPL as it would be to fork the Linux kernel. I pointed out the it's just not true and that RMS has unprecedented legal power that Linus does not have - but you left those points unreplied. Should i take them as conceded?) I disagree. Keeping Torvalds honest and sharp is a consequence of Linux being free software; you made an accurate description not of an open decision process, but of an open development process. One person gets to make the decisions nevertheless, like it or not. Might be a fine point, but it is the one discussed here. No, what keeps Linus sharp and honest is the fact that he has no legal power to keep forks from happening. The GPLv2 license itself is an expression of that fact. The president of the FSF on the other hand has no such "danger of competition" hanging over his head. He can put into the GPL what he thinks is right and release it, and it instantly and retroactively affects the contribution dynamics of 350+ million lines of code. No other person on this planet has this power. On the other hand anyone can fork Linux (and many try and do) and continue from that base and leave Linus behind. Linus has no legal power to keep that from happening, and that is very much by design.
Let's all develop just by forking Posted Oct 2, 2006 17:09 UTC (Mon) by man_ls (subscriber, #15091) [Link] thanks!You are welcome :D Also, you did not reply to my fundamental question: you claimed that it would be just as easy to fork the GPL as it would be to fork the Linux kernel. I pointed out the it's just not true and that RMS has unprecedented legal power that Linus does not have - but you left those points unreplied. Should i take them as conceded?I did not claim that you could fork the GPL, it was somebody else. In fact I don't think that the GPL can be forked at all; the FSF keeps copyright on it, so you cannot change it. You can create a similar license with equivalent terms. As to the unprecedented legal power: that power is voided if nobody will ever take advantage of the "at your option" clause and choose the GPLv3. In fact, almost every recipient of v2 code will have that option. Linux kernel developers and users will not. Now, as it happens the Linux kernel developers (who are not affected by it) are the ones most vocally arguing against the GPLv3. Odd. No, what keeps Linus sharp and honest is the fact that he has no legal power to keep forks from happening.Whatever. No way to verify that statement to good effect. The president of the FSF on the other hand has no such "danger of competition" hanging over his head. He can put into the GPL what he thinks is right and release it, and it instantly and retroactively affects the contribution dynamics of 350+ million lines of code.That is his prerrogative. After you create a license which is used by hundreds of thousands of developers, you have to concede that many of them trust the man to create a good successor to v2. Those who don't trust him should remove the "at your option" clause anyway. Those in between should confort in the fact that they can stick to v2 and remove the clause, if they don't like v3.
Let's all develop just by forking Posted Oct 2, 2006 20:45 UTC (Mon) by mingo (subscriber, #31122) [Link] As to the unprecedented legal power: that power is voided if nobody will ever take advantage of the "at your option" clause and choose the GPLv3.It is not voided because once it has been used, and if the resulting GPLv3 license is backwards-incompatible with the GPLv2, any GPLv3 project can take any GPLv2-or-later code and incorporate it - but changes might not be backmergable into the original GPLv2 codebase! Please think about it. It is a huge factor. It changes the whole ballgame. It is also very unfair to those who created the "GPLv2 or later" code to begin with, and who wanted the basic Quid Pro Quo (which is also one of the 4 freedoms): I give you my source, you give back yours. Now the GPLv3 might change that to: "I take your source code, but you can only take it back if you change your project to GPLv3." Is it your position that it's "that developer's fault, for having released it under 'GPLv2 or a later version' license"? Is it your position that because RMS has the legal power to create such a situation, that it is automatically fine, no matter what RMS's decision ends up to be? That is why i call it unprecedented legal power, and only a single person on this planet has this legal power: Richard Stallman. There is no equivalent power Linus has in the Linux kernel space. He does not even come close. All the "power" he has is his technical experience and maintainance skills. So your previous points of trying to claim that Linus has a similar legal position in the Linux kernel space as RMS has in the GPL license space is materially false. (Which i kind of see conceded by you implicitly, because you did not advance that point any further.)
Let's all develop just by forking Posted Oct 2, 2006 21:30 UTC (Mon) by man_ls (subscriber, #15091) [Link] Is it your position that because RMS has the legal power to create such a situation, that it is automatically fine, no matter what RMS's decision ends up to be?No, of course not. If the license was unfair or inconsistent I would complain loudly. I just don't see how banning DRM (which is a bad thing, as I tried to explain on other pages) can be that bad -- especially for a group of people which aren't threatened by the GPLv3 update. So your previous points of trying to claim that Linus has a similar legal position in the Linux kernel space as RMS has in the GPL license space is materially false.I assure you I'm not trying to win my arguments blindly. The previous point was that GPLv3 drafting was as closed a process as Linux development. Linus has the same "benevolent dictator" status for Linux as Stallman for GPL. Their legal positions are as you say very different, since one is developing software and the other one updating a license.
Let's all develop just by forking Posted Oct 2, 2006 21:56 UTC (Mon) by mingo (subscriber, #31122) [Link] I assure you I'm not trying to win my arguments blindly. The previous point was that GPLv3 drafting was as closed a process as Linux development. Linus has the same "benevolent dictator" status for Linux as Stallman for GPL. Their legal positions are as you say very different, since one is developing software and the other one updating a license. I tried to answer this before, but lets try another approach to get my point across: Linux decision process: anyone can replace Linus, Linus has no legal power to decide what goes into Linux. Hence he has no choice but to be open about every decision. He delegates "merging decisions" to subsystem maintainers and generally keeps an open mind about stuff. (i have proven this with an actual incident of Linus strongly opposing something and then merging it anyway. I could show many other similar incidents too.) If the Linux decision process were dictatorial then you'd sure be able to cite me at least one example of Linus arbitrarily rejecting a change? GPL decision process: no-one can replace RMS, and RMS has the sole legal power to unilaterally decide what goes into the GPL. There's little outside pressure on RMS to change or adapt. How you can claim that the Linux decision process is "closed as the FSF decision process" and in fact how you can claim that the two decision processes are similar in any way, is beyond my cognitive capabilities :-)
Control over the kernel Posted Oct 3, 2006 9:33 UTC (Tue) by man_ls (subscriber, #15091) [Link] Linus has no legal power to decide what goes into Linux.In fact he does: below this same page you can read: Linux is a registered trademark of Linus TorvaldsIt is not a fine legal point; he may not use that power, but that is his prerrogative. He has de iure control on Linux. Besides he publishes the kernel.org main kernels, so he also has de facto control. He delegates "merging decisions" to subsystem maintainers and generally keeps an open mind about stuff.He chooses to do so, sometimes. There are counter-examples like micro-kernel design and alternative security frameworks, as I gather from LWN. If the Linux decision process were dictatorial then you'd sure be able to cite me at least one example of Linus arbitrarily rejecting a change?Those mentioned above, or his unillateral decision of using a proprietary tool (BitKeeper) despite lots of people advising against it (including many kernel submaintainers like Morton). People proposed free alternatives or even developing a new one but they were all rejected. Remember that the arguments in favour of BitKeeper were that it enabled Linus' workflow, there were no free alternatives and developing one would take years. After withdrawal of the free client, in 15 days Linus had a working replacement. Allowing binary modules is another area where Linus' opinion is final. Discussing these issues with a kernel developer is funny. I'm sure domain experts can suggest many more dictatorial changes in areas where there is no consensus. GPL decision process: no-one can replace RMS, and RMS has the sole legal power to unilaterally decide what goes into the GPL. There's little outside pressure on RMS to change or adapt.Little pressure? I don't think so. 22 years ago he had the whole industry against him; 8 years ago he confronted a pro-industry lobby (OSI) on his own. Free software (and "open source") licenses sprout every month. And still the GPL is used in 85% of free software projects. I would say that is enough pressure. RMS plus Moglen plus the FSF decide what goes into the GPL, just as Linus decides what goes into Linux. If you don't like it you can discuss it on the GPLv3 page (or on lkml), otherwise just choose another license (or another kernel). You can fork the kernel, and you can impose additional restrictions or permissions on top of the GPL (or rewrite it and change some aspects). Both are top-down processes; the fact that the dictators disagree on certain respects and you are friends with one of them does not change anything, Ingo. Linus listens to you, but that is because you think like he does; if you proposed a change to a micro-kernel architecture would he listen to you? If suddenly most kernel submaintainers proposed it? Would they be submaintainers for long?
Let's all develop just by forking Posted Oct 3, 2006 15:01 UTC (Tue) by southey (subscriber, #9466) [Link] It is not voided because once it has been used, and if the resulting GPLv3 license is backwards-incompatible with the GPLv2, any GPLv3 project can take any GPLv2-or-later code and incorporate it - but changes might not be backmergable into the original GPLv2 codebase!It is a given that GPLv3 will be backwards-incompatible as the DRM story shows. But also there will be GPLv2-or-later code that will be incompatible with GPLv3. This is simple logic as the GPLv3 has more restrictions than the GPLv2 like potentially requiring all code free or not (especially code linking to less-free or closed libraries) and items covered by a patent (does not have to be software patents). In part, I think the aspect of spirit is part of your core argument in this whole discussion. It is very clear to me that the written spirit of the GPL license has changed from GPLv2 to the draft of GPLv3. Just because Richard Stallman has decided that GPLv2 does not reflect his view of code 'freedom', it does not permit the him to change the written spirit of GPLv2 and force everyone with GPLv1 or GPLv2 licensed code to support his new revised view. (Yes, it is new and revised if for no other reason than changes in technology.) So, if the code owner considers that the spirit has changed, is the or a later version aspect still binding (if it was in the first place)?
Normative reference for 350+ MLOCS? Posted Oct 2, 2006 18:34 UTC (Mon) by piggy (subscriber, #18693) [Link] ... 350+ million lines of code ...
Does anyone have a normative reference for this 350+ million LOC available under the GPL? Translating that to total developers over 15 years gives me something between 2000 and 10,000 developers working on GPL'd code. That is about the range I estimate for developers CURRENTLY working on the Linux kernel alone.
Normative reference for 350+ MLOCS? Posted Oct 2, 2006 19:41 UTC (Mon) by mingo (subscriber, #31122) [Link] Does anyone have a normative reference for this 350+ million LOC available under the GPL? Translating that to total developers over 15 years gives me something between 2000 and 10,000 developers working on GPL'd code. That is about the range I estimate for developers CURRENTLY working on the Linux kernel alone. I did some pretty precise measurements ~2 years ago on the total sourcecode of FC3, and i extrapolated from that to FC6 and got 370 million lines of code. (and that takes code duplication into account already) Note that FC6 has ~2200 packages right now, while Debian has well over 15000. The gzip compressed source code size of FC6 is 2.6 GB, the compressed source code size of Debian is 8.8 GB. So Debian's size is somewhere around 1.2 billion lines of free code. So i think it's probably fair to say that free software has recently hit (or will soon hit) the 1 billion lines of code landmark. I said the 350+ mloc metric in the discussion because i'm reasonably certain about that metric. (i did it myself) The kernel, when it was 4.2 million lines of code, was estimated to be equivalent to the value of commercial code developed from scratch for 175 million US dollars, under a hand-tuned COCOMO model with a multiplicator of 2.40. 370 million lines of code, even assuming a default 1.0 COCOMO complexity multiplicator and developed from scratch, is worth 6.2 billion US dollars. Under the same metric, Debian's 1.2 billion lines of code is worth 21.2 billion US dollars. Of course the freedom offered by free software cannot be measured in US dollars, but still it's good to know the rough value of the economic foundation this community has built for itself.
Normative reference for 350+ MLOCS? Posted Oct 2, 2006 22:15 UTC (Mon) by cventers (subscriber, #31465) [Link] > Of course the freedom offered by free software cannot be measured in US> dollars, but still it's good to know the rough value of the economic > foundation this community has built for itself.
This is why I think it is very important that the FSF has been doing the
I don't think Linus's implication that the FSF didn't care what he
Normative reference for 350+ MLOCS? Posted Oct 3, 2006 0:06 UTC (Tue) by mingo (subscriber, #31122) [Link] You don't have to answer to anybody - you can walk right into the discussion process as Ingo Molnar with whatever opinions and concerns you have. What makes you assume that i have not done so already?
Normative reference for 350+ MLOCS? Posted Oct 3, 2006 2:27 UTC (Tue) by cventers (subscriber, #31465) [Link] Well, when I refer to the discussion process in this way, I'm refering toformal participation. And laf0rge posted elsewhere in this commentary on LWN that he was the only kernel developer he saw at 3 conferences. And it seems like from some of the statements of the other developers that no one really got directly involved for various reasons.
But you are right. I made an assumption, and for that I must apologize.
FSF is creating a problem that never existed! Posted Oct 2, 2006 12:03 UTC (Mon) by laf0rge (subscriber, #6469) [Link] Ingo, I don't really understand your hatred against the GPLv3 and the process. I've personally witnessed (and contributed some minor issues to) the GPLv3 process, and I can absolutely not support the statement of it not being open.
In fact, very early on, I feared that the process wouldn't be open. But especially looking at the changes between the first and second draft, you can't really claim that the feedback from the community has no influence on the license drafts, can you?
Isn't it just that you happened not to care about the GPLv3 process until it was already going on for more than six months? Why was I the only kernel developer present at those three GPLv3 conferences that I've been to?
If you feel like basing your criticism on a solid basis, I suggest you outline which comments you made at which state of the process, how those comments were submitted to the FSF, and which response you got or didn't get.
btw: Almost all my old code is GPLv2 only. Because I never know in advance how any later version might look like. Now that v3 starts to materialize, I'm sure I'll switch to "v2 or v3" wording. The openness of the FSF license drafting process might even make me dare to use "or any later version" in new code that I write from now on.
FSF is creating a problem that never existed! Posted Oct 2, 2006 15:00 UTC (Mon) by sepreece (subscriber, #19270) [Link] In practical terms the GPLv3 process has been very open to input, but there is no evidence that it is open to change of substance. Since the actual decision process is out-of-sight, and since RMS gets the final say, it's hard to describe this as a fully open process.
Note, however, that I have no reason to believe that the issues of substance (like anti-DRM) are things on which a more open decision process would make any changes. I'm prepared to believe that the FSF core membership shares RMS's position on the necessity of those changes.
FSF is creating a problem that never existed! Posted Oct 2, 2006 18:05 UTC (Mon) by tzafrir (subscriber, #11501) [Link] There is one ample difference between the GPLv3 process and free software development:
If Linus gets a major thing wrong, he puts on his brown paper bag, fixes the problem, and releases a new version. If a tiny-little bug was found, it would probably wait for the next release.
In this case there is no "next release". All bugs need to be found in the current release (GPLv3). Or they'll remain for practically forever.
FSF is creating a problem that never existed! Posted Oct 2, 2006 15:23 UTC (Mon) by mingo (subscriber, #31122) [Link] Ingo, I don't really understand your hatred against the GPLv3 and the process.If you read my replies, they outline all the worries that i have. There is no "hatred" (for every issue i raised i have written down the basis of that worry - which i believe is not irrational), just a deep disapproval/frustration of monopolistic/dictatorial practices, and a worry that a previously unified community would be split by using legal powers - a disapproval shared by many others on this and on other forums. While i can see little in the GPLv3 that will solve practical license related problems we have in free software today (i see a few things that could solve future problems), i already see real collateral damage caused by it: we wasted way too much time on this unsolvable problem already, we just lost the busybox maintainer, and i'm afraid more pain is to follow. I'm also worried that RMS justifies the closed decision-making process of the GPLv3 because: "Most of our community does not appreciate freedom" . To answer your points, the fact that /you/ like the end result might have something to do with the fact that you are content with the process, dont you think? Do you agree with me in theory that if i dont like the end result (so far), and i see that it is in large part due to the fact that RMS keeps full legal control over the next version of the GPL (which only he can do - no other person on the planet), that i have the right to at least be worried about the concentration of so much power in a single hand? Or should i queue up with you just because you like the end-result? Even if i were happy with the GPLv3 i'd still accept the right of others to be upset about it, if they are ready to articulate their points.
FSF is creating a problem that never existed! Posted Oct 2, 2006 18:22 UTC (Mon) by man_ls (subscriber, #15091) [Link] I'm also worried that RMS justifies the closed decision-making process of the GPLv3 because: "Most of our community does not appreciate freedom".To put it in context, Stallman says just above that: These are the kind of people that assume that you should choose between Free Software and proprietary software based on practical convenience, which is another way of saying that they value freedom at zero.Why is that worrying? I thought most kernel developers were all for practical convenience, and freedom was just a secondary concern. (Maybe not valued at zero, but very little.) Linus Torvalds himself chose to use a proprietary program for source code management because it was more convenient than the competition in the free software camp. If you appreciate convenience features more than your freedom, then you will agree that you don't appreciate freedom too much. Most people are like that. That is not bad, just a fact of life.
FSF is creating a problem that never existed! Posted Oct 2, 2006 18:58 UTC (Mon) by smitty_one_each (subscriber, #28989) [Link] >>These are the kind of people that assume that you should choose between Free Software and proprietary software based on practical convenience, which is another way of saying that they value freedom at zero.>Why is that worrying?
It is a sad day when one voice levels the accusation "unethical" at someone else's behavior, while falling short of defining what "ethics" is.
FSF is creating a problem that never existed! Posted Oct 3, 2006 9:40 UTC (Tue) by cate (subscriber, #1359) [Link] Freedom is very subjective. Anarchy is the most individual freedom, but do this means that you have more freedom possible? If we don't want anarchy, it means that we don't consider freedom, right?Your (and RMS) arguments are far to extreme.
Anyway, are you saying? The GPLv2 was not about freedom and only the GPLv3 give us freedoms?
Freedom over convenience Posted Oct 3, 2006 9:55 UTC (Tue) by man_ls (subscriber, #15091) [Link] You don't have to interpret Stallman's sayings; you have a lot of his own exegesis online. He just asks you to value convenience over freedom, and freedom is a well defined set of conditions. The guy is not asking you to give your life for the revolution, just to give up OpenGL with certain cards, or wait a little. I don't think those conditions are too extreme. I live according to his precepts and have been happy ever after! (Just joking :)Both GPLv2 and v3 are about freedom; times change and licenses must be updated to reflect the new conditions and close any loopholes.
Freedom over convenience Posted Oct 3, 2006 21:58 UTC (Tue) by sepreece (subscriber, #19270) [Link] I suspect that was supposed to be "to not value convenience over freedom".
I would note, though, that "content vs freedom" is a different equation than "convenience vs freedom". A lot of content is simply not available (legally) without DRM. And that's because the content owners are exercising their right to control the circumstances under which they release their content, just as GPL authors control the circumstance under which they release theirs.
Stallman, of course, says "movies are generally no good - you're better off without them" and "if you really want movies, go find copies that people are sharing in violation of their licenses." [those are paraphrases, but definitely in the spirit of the actual quotes]
Freedom over convenience Posted Oct 4, 2006 10:10 UTC (Wed) by stijn (subscriber, #570) [Link] When exercising their rights the content owners are using a big club and overwielding it to the extent that 1) you loose the rights or the power to exercise rights you had before (think fair use, time/space shifting). 2) the means they use encroach in other technological areas as well.
Increasingly ridiculous EULAs will be substituted by and implemented with DRM. Information or content if you will will be licensed under EULA type restrictions.
I am not sure I disagree with anything you say, but somehow I have trouble grasping the symmetry between DRM-licensed content and GPL-licensed code, looking at it from the perspective of nourishing creativity and progress - rip and mix.
Freedom over convenience Posted Oct 4, 2006 14:49 UTC (Wed) by sepreece (subscriber, #19270) [Link] The symmetry is pretty straightforward. The GPL says "you may redistribute so long as you meet these conditions." Movie and music producers say to their distributors "you may redistribute our content so long as you meet these conditions".
I'm certainly not saying that the content owners are nourishing creativity and progress by restricting their content, just that what they are doing appears to be within the rights granted them by copyright. For that matter, I have reservations about the GPL on the same point.
As to fair use, it's a very slippery concept. There's never been a hard definition that allows you to know exactly what use is fair use. In any case, fair use limits the owner's ability to sue you for certain uses of hte material, it doesn't require that the content owner make it easy to make fair use of the material.
For instance, a reporter clearly has a right to quote from a public speech, but there is no requirement that the speaker provide even a written transcript, let alone an electronic transcript or recording. Similarly, the fair-use right to quote from a movie for a review doesn't require that the owners provide clips, either on request or by capture from a playback device; it just means you're not infringing if you use clips in a review [note,however, that if you got those clips by circumventing DRM, as opposed to by videotaping a playback, you may still be violating the DMCA].
FSF is creating a problem that never existed! Posted Oct 2, 2006 19:26 UTC (Mon) by landley (guest, #6789) [Link] > I'm also worried that RMS justifies the closed decision-making process> of the GPLv3 because: "Most of our community does not appreciate > freedom" .
While I remain as amused as ever by those who would impose democracy at
Some people consider a BSD license to be "good enough". I disagree
With GPLv3 the FSF is off on an ideological kick trying to open up the
GPLv2 has an excellent pragmatic effect, good for the project's
But fundamentally, the central issue for me is that GPLv2 is good enough,
FSF is trying to solve our coming problems Posted Oct 2, 2006 20:28 UTC (Mon) by man_ls (subscriber, #15091) [Link] And people still wonder why Stallman tells the printer driver story all the time.GPLv2 was not about forking, gainful employment or development at all; it was about replacing the darn printer driver in the 90's. GPLv3 is about replacing it in the 21st century. Once the printer server runs a TPM chip it's back to square one. With the GPLv3 Stallman is just saying: "you can do it, but not with my code". It's simple, really.
FSF is making the Tivo situation worse Posted Oct 2, 2006 21:05 UTC (Mon) by mingo (subscriber, #31122) [Link] GPLv2 was not about forking, gainful employment or development at all; it was about replacing the darn printer driver in the 90's. The printer driver situation was materially different from the Tivo situation. The printer driver was closed-source and he could not get the source code to fix obvious bugs in it. Today most of the printers have free drivers. Why? Not because the printing industry symphatises with RMS's desire to hack his printer driver, but because they saw an economic necessity to serve a growing market. (Linux servers and Linux desktops) In other words: the printing industry reacted to people's desire to run Linux, and to use their printers under Linux. Please remember: the key to having open printer drivers was people wanting Linux. But the Tivo situation is completely different. The Tivo was DRM-ed because it plays content from an industry that required its copyrighted works to be protected. There were people (besides honest tweakers) who were "hacking" not to fix bugs in the Tivo but to avoid having to pay for "pay per view" content. So replying to content industry pressure Tivo closed it down more than they have originally done (being an appliance, they never anticipated it being modifiable), and added this crypto based virtual-ROM technology that restricts the hardware to run only certain kernels that match a given hash. As far as the user is concerned it behaves like old-fashioned ROM, in practice it is not modifiable. (but the manufacturer can come and can flip in an upgraded ROM - just like with old-fashioned ROMs) If Tivo couldnt use Linux they'd be using LynxWorks or some other embedded OS, because people are not interested in the Linux in the Tivo, people are interested in Tivo's userspace app and in the content the Tivo is offering. Please think about it. By trying to go "eye for eye" with Tivo we only hurt Linux and help Hollywood's monopolization efforts, because one more small player would exit their market - and that small player does it all voluntarily, via a licensing change. We'd also further isolate Linux from a market that people are interested in. Whoah, Microsoft's dreams come true! So what we are doing via the anti-Tivo language is that we hurt Linux and help Hollywood. It will not result in free Tivos. It results in no DVD playing hardware or software being associated with Linux at all! The reason again: people are not interested in the Linux aspect of these players. And if the Tivo case is completely inapposite, if it achieves precisely the opposite effect, then why is the GPL trying to "address" it? Why are we doing all that anti-DRM stuff in the license to begin with, if it only hurts the little guy and helps big corp, even for the case that was singled out by RMS himself: Tivo?
Tivo sucks Posted Oct 2, 2006 21:41 UTC (Mon) by man_ls (subscriber, #15091) [Link] Ingo, do not let those Hollywood arguments drive you. Just imagine that the Tivo player, apart from recording movies and replaying them, has an attached printer and you want to print a screen capture. Or a program listing, whatever. Then you discover that the printer is not working for you, since the driver is broken. Then you, who are an excellent kernel programmer and knows that the thing runs Linux, want to repair the driver. Then you find out about the TPM and how it won't let you upgrade the device you legally bought, because the guys who took your money are treating you like a thief. Then... déja vu.And if the Tivo case is completely inapposite [...]My goodness, inapposite is a word! Anyway, I would gladly leave that bastard market to Microsoft. It would save Linux from the creepy associations that DRM brings, and would be one more reason to see DRM crumble. But then it's not my code in there.
Tivo sucks Posted Oct 3, 2006 15:46 UTC (Tue) by southey (subscriber, #9466) [Link] I don't see your point. What I understand, as I don't have Tivo, is that they provide the source code so you can fix your issues. So it is incorrect to say that it won't let you upgrade the device you legally bought.The real issue for you is that you still want to run Tivo when you have modifed your Tivo system. However, Tivo is the combined package of hardware, software and content, so you can not have one without the others. Also, you are not clear on what you actually brought and under what terms when getting a Tivo system. By modifying your software and/or hardware you have appeared to violated the terms of sale and/or contract with Tivo in that you can use the hardware and software just not with Tivo. If MythTV and other similar software got easy to install and competitive then current Tivo situation probably would become disappear. In your argument you seem to be forgetting the rights of the people that are involved. If Tivo did not use TPM it would have to find some other method of control to protect the rights of itself and the content providers. The real answer is not DRM or GPLv3 but working with the likes of Tivo and other content providers to protect everyone's rights.
Tivo sucks Posted Oct 3, 2006 23:27 UTC (Tue) by man_ls (subscriber, #15091) [Link] What I understand, as I don't have Tivo, is that they provide the source code so you can fix your issues.Except that you can't. You can't run modified software so source code is useless. In your argument you seem to be forgetting the rights of the people that are involved.I forget them for a reason. Imagine that I tell you that the U.S. Constitution must "balance" the rights of the people and those of the Government: you would probably laugh at me. The government doesn't need rights, since it has the power. Or suppose we are talking about slavery and I tell you that we need to "balance" the rights of the slave with those of the master. The imbalance is so strong to begin with that it is ludicrous. The right to copy (or copyright) was called that way because it expressed the rights of the author to be paid by a publisher. Here the powerful party was the publisher; no rights of his were "balanced" against those of the author. Now the "author" has become so powerful that you, the reader, have nothing to bargain with -- except your money, and money can hardly be called "a right". There is no way I can balance e.g. my rights of fair use with anything else; the publisher just locks the work of art and I'm screwed. Yes, Tivo can "balance" their contract with content providers, but I'm left out of the loop: I lose every time. The "rights" in "Digital Rights Management" are farcical. So I prefer to forget them to avoid cronic depression.
Tivo sucks Posted Oct 20, 2006 10:52 UTC (Fri) by blujay (guest, #39961) [Link] I know this is an old thread, but...
The answer is: Don't buy the Tivo! You keep using an argument
Imagine a situation where Linux went GPLv3. Can you force Tivo to start
I read a comment earlier that basically said, "I think we're important
Linux and Free Software are getting some pull in enterprise systems, it
FSF is creating a problem that never existed! Posted Oct 2, 2006 16:37 UTC (Mon) by mrfredsmoothie (subscriber, #3100) [Link] Without realizing this enormous moral obligation, and without codifying that obligation into the license and into the license update process i feel there is no possibility for the GPLv3 process to be open in the sense of free software: we should not only have the ability to see the process, but also the ability to modify it.Why is it only contributors that deserve this freedom-to-modify? What about users? Remove the "or any later" language and go the normal way of acquiring the hearts and minds of contributors: by convincing them to use a new license, once it has been released, for newly written code or for old code they wrote and are willing to relicense, one by one.)This is by far the more valid concern, IMO. I don't think contributors who wouldn't have agreed to new terms should be bound to them after-the-fact, and I don't know how well the whole "spirit of the license thing" would hold up in court WRT the "or any later version" thing (I doubt any court is going to enjoy sorting out what each developer "meant" when they licensed under the GPL).
FSF is creating a problem that never existed! Posted Oct 7, 2006 2:53 UTC (Sat) by mikov (subscriber, #33179) [Link] I have to say that while until now I was hesitant on the GPLv3 issue, after reading your excellent posts on LWN, you have managed to convince at least one person -> me.
It is obvious to me now that even if hypothetically the world would be a better placee with GPLv3's additional restrictions, the FSF has no right to introduce them, because those restrictions are not what many developers agreed to when they were accepting the GPLv2 license. Even if those developers were foolish for not considering and fully understanding what they were accepting, the FSF has no moral right to take advantage of that.
Practically speaking, even if the GPLv3 really IS universally better (obviously many people think that it is), it should not automatically apply to GPLv2-licensed projects who happen to have the "or any later version" text.
All problems will be solved by renaming the GPLv3 to "NGPLv1" so that it isn't covered by the "later version" text. Projects are completely free to adopt it deliberately and knowingly.
|
|||||||||||||