| |||||||||||||
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ..."Ours is Ours, Yours is Yours" is gone from the GPLv3 ...Posted Oct 5, 2006 13:17 UTC (Thu) by mingo (subscriber, #31122)Parent article: Similar in spirit?
Another area in the GPLv3 where i see significant departure from the spirit of the GPLv2 is the issue of whether the GPL controls "other, independent works" not based on any GPL-ed code. The GPLv2 speaks very clearly about this in Section 2: 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 not present in the GPLv3, and indeed the GPLv3 tries to extend its reach to certain works not created by us and not based on any GPL-ed code: parts of the hardware (certain keys). For now. While this might sound like a technicality, it corrupts a core principle of the GPLv2 and opens up the floodgates: it fundamentally changes the simple, powerful and fair "we give you source code if you give back all source code based on this code" rule to something that is open-ended. We needed 10 years to convince developers that the GPLv2 rule is fair and square, we lived for 15 years with this property of the GPLv2 and participated in the writing of a huge, more than 1 billion lines of code GPL ecosystem, so the bargain should not be changed now, without our consent. No-one on the FSF side so far was willing to limit the scope of this change. For example will future versions of the GPL attempt to prohibit non-GPL-licensed works to be distributed together with GPL-ed works? This open-ended isolation of the GPL ecosystem, at the behest of the FSF, is just as dangerous (if not more dangerous) than the whole DRM language. Or as Linus has said it on lkml, more than 6 years ago: There's been some discussions of a GPL v3 which would limit licensing to certain "well-behaved" parties, and I'm not sure I'd agree with such restrictions [...] Linus has been consistent on that ever since, and that fundamental objection of him still stands. No amount of participation in the GPLv3 process seems to have removed this fundamental flaw from the GPLv3, in 6 years of "consultation".
(Log in to post comments)
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 14:20 UTC (Thu) by cventers (subscriber, #31465) [Link] Ingo, (once again, I've got nothing but respect for you, but I don't agree with your take on this at all...) I don't think the reach is extending beyond even what the GPLv2 says. 'Intent' is a word about why something was done a certain way. And I think that there are still plenty of us who believe that the Intent of GPLv2 was very clearly to preserve Freedoms 0-3, especially given that the entire opening section of the license persists of talking about these freedoms: When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. Some people seem to assume that the Free Software Foundation is trying only to make political moves or statements. But unfortunately in our current world it is becoming clear that some kind of anti-DRM language is needed to preserve Freedoms 0-3. Freedoms 0-3 is what the license is really about. It's not tit-for-tat, as Linus calls it. It may have the tit-for-tat property, or the fair and square property, but it is a free software license and it's frankly delusional to try and call it anything else. What Linus says about "well-behaved parties", at least as much as you have quoted, has implication but no substance. In a sense, GPL has always limited licensing to well-behaved parties - the parties that don't seek to undermine free software! That's why we have a GPL in the first place. If the license didn't aim to stop people from undermining free software, it would have no reason to exist -- everyone could just use BSD. DRM vendors, whether incidentally or intentionally, are moving on a path that can undermine what we've all worked so hard for. If the Linux developers or any other community don't want to stand in their way, that's totally okay. But please recognize that as one other astute LWN reader said in another comment on another thread, we won't help them build the jail with our own code! It's a free software license from the free software foundation. But even so, they want your participation. I never really got a reply from you earlier, but I'm pleading with you to take this LWN comments discussion straight to the FSF and to bring some of the other kernel developers with you. The FSF wants your participation, even if that means disagreeing with them. Even if they don't strike down everything you disagree with, you are passing up an opportunity to get involved in the official drafting process which is definitely open. If you don't take the opportunity, you're (no offense) no better than people who moan loudly about how bad the politicians suck and then sit on the couch on voting day. For crying out loud, Sun Microsystems says the process is open, and they say they like this new license! And we just learned yesterday that Nokia also seems to be happy, and says that the DRM provisions in GPLv3 were 'clarified' for them, leaving the impression the license is well on the way to being agreeable by nearly all parties. ...except the kernel developers, the one community that pointed out it can't use GPLv3 even if it wanted to. What kind of bizarro world is this? Why won't you get officially involved?
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 15:02 UTC (Thu) by mingo (subscriber, #31122) [Link] Thanks for your comment. (Please read my reply in its entirety, even if you dont agree with sections of it, it's a complete whole and any counter-arguments should consider the totality of my opinion. Thanks!) that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. The contention that this somehow turns into a "right to tweak the hardware" is false. The term "right to tweak" has been invented well after the GPLv2 was released, well after Linus released Linux under the GPLv2, and well after i chose to contribute under the GPLv2. I reject such a retroactive interpretation of a pretty clear license. If you look at the plain language of the GPL sentence you cite above, it is a recitation of the exclusive rights authors have under the Copyright Act: the right to create and distribute copies, the right to modify and derive code. See USC 17 / 106. The "receive" stands for distribution, "change the software or use pieces of it in new free programs" means the exclusive right for modification and derivation. No-one in their right mind, neither i nor Linus ever understood that plain langugage to mean: "you have to allow to make binaries in ROM's modifiable". IMO that interpretation is often just wishful, revisionist thinking, possibly created by "oh what should we do about this DRM thing" thoughts. But note that the section you cited talks about source code (i highlighted that in the quote above). Tivo gives out their modified kernel source code (a derivation of the kernel), and gives you the rights to use, modify and derive Tivo's added work freely. Tivo also gives you the right to distribute copies. Tivo completely lives up both to the moral and to the legal deal. What it does not give you is a totally separate piece of work: the hardware's keys. (That is, by the way, also a conflict in the position of the FSF: for decades they insisted that the GPL is a license, not a contract. But only a contract can affect works that are not covered by copyright law! So what is the GPLv3 now, a license or a contract?) The contention that DRM and using crypto keys to protect hardware integrity is somehow new is false too. Intel has been using DRM since ~1996, ever since they made their microcode uploadable. RMS has been using it probably every day in the past 10 years or so, and he probably didnt even realize it. Would you want to run CPU microcode "modified" by a friendly virus writer? What if the CPU is based on a GPL-ed work, such as: this GPL-ed CPU design? IMO this whole thing that to me appears to be a vendetta against DRM is largely misplaced and wastes our resources. And i'm asking, if it is this hard to make such a relatively simple issue understood by the FSF, if it's so easy to turn it into a nasty emotional and political issue, how will we be able to deal with more complex issues? I believe that in the light of this debacle the only sane and morally correct solution would be for the FSF to voluntarily give up power (which power is quite similar to unilateral relicensing power over a huge codebase), and to remove the "or later" language from the default COPYING file. Leave it up for authors to explicitly chose this if they trust them on it. In fact: the FSF, just like Linus, should reject blanket authorizations of trust, like an open-ended "or later version" language. Dont let inertia and laziness drive an important decision like that. That way authors of new code can judge the licenses on their merits once they are released, and the FSF can release new licenses at a much faster pace. "Release early, release often" applies here too.
4 points Posted Oct 5, 2006 15:17 UTC (Thu) by coriordan (guest, #7544) [Link]
Tivo and point 4 Posted Oct 5, 2006 22:15 UTC (Thu) by zlynx (subscriber, #2285) [Link] Quick note on your point 4:The keys are not required for the work to run. Take Tivo for example: a Tivo binary should execute just fine on some other non-Tivo PowerPC based system.
So what the keys do is prevent executing a binary on a particular piece of hardware, not prevent executing it at all. At least, in the Tivo case. An encrypted binary, rather than a signed one, would be a different situation.
So it seems the key is a part of the hardware, not the software, and thus a separate work.
It's just like having a Linux or HURD (since Linux is staying GPLv2) kernel executing from a virtual machine. If I restrict the execute permissions of the kernel's VM image to a single user, is that user's login password suddenly a "part of the work" required to run the kernel? Ridiculous.
A better example yet, say I build a HURD kernel just the way I like it and take it's SHA1 key. I customize a copy of QEMU to only run if the boot image matches that SHA1 key. Your copy of my image isn't affected. You just can't run a modified version on my QEMU.
Tivo and point 4 Posted Oct 6, 2006 10:57 UTC (Fri) by nim-nim (subscriber, #34454) [Link] > So what the keys do is prevent executing a binary on a particular piece of> hardware, not prevent executing it at all.
That's assuming availability of non-DRMed hardware. This is not a safe bet, especially if the existing software pool can be DRMed at will.
Tivo and point 4 Posted Oct 6, 2006 16:10 UTC (Fri) by man_ls (subscriber, #15091) [Link] Take Tivo for example: a Tivo binary should execute just fine on some other non-Tivo PowerPC based system.If I had purchased a Tivo and it had some serious flaw which the company did not want to fix, it would not help much to know that I could execute it on some other piece of hardware. The keys are part of the particular software distribution, which is contained in the Tivo. You could have another type of hardware, another distribution So it seems the key is a part of the hardware, not the software, and thus a separate work.Hardly. I could make the same argument about a particular driver: my Linux kernel might run just fine without the driver, on a different hardware configuration. Therefore the driver is part of the hardware. The key is just a magic number. It is required to install and run the software on a particular piece of hardware. Providing source code but not the magic number is cheating IMHO.
4 points Posted Oct 6, 2006 9:26 UTC (Fri) by mingo (subscriber, #31122) [Link] There is nothing in GPLv3 to "make binaries in ROM's modifiable", I don't know where you're getting that from.You are misrepresenting what i said. If you read my comment, i was talking about the language in the GPLv2, which language someone else suggested means that "the right to tweak" was somehow embedded in it. When Linus and i adopted the GPLv2, the GPLv3 draft and the term "right to tweak" did not exist yet, and i resist revisionist interpretation of the GPLv2 license. Please re-read my ROM point with that in mind, and consider that i'm interpreting the GPLv2 license: The "receive" stands for distribution, "change the software or use pieces of it in new free programs" means the exclusive right for modification and derivation. No-one in their right mind, neither i nor Linus ever understood that plain langugage to mean: "you have to allow to make binaries in ROM's modifiable". IMO that interpretation is often just wishful, revisionist thinking, possibly created by "oh what should we do about this DRM thing" thoughts. Thanks.
4 points Posted Oct 6, 2006 9:51 UTC (Fri) by mingo (subscriber, #31122) [Link] "DRM is not new" - GPLv3 doesn't prohibit DRM, it prohibits tivoisation (one particular use of DRM). Firstly, did you read the article you are replying to? In particular the bit where Richard Stallman is quoted as saying: I'm less concerned with what happens with embedded systems than I am with real computers. The real reason for this is the moral issues about software freedom are much more significant for computers that users see as a computer. And so I'm not really concerned with what's running inside my microwave oven.The Tivo is not a general purpose computer pretending to be freely modifiable. The Tivo is a PVR (Personal Video Recorder), a special-purpose specialized appliance, not much different from a microwave oven. Secondly, i never claimed the GPLv3 prohibits "all" forms of DRM - not even the FSF is /that/ out of touch with reality. But if for example Intel based any parts of its microcode on GPL-ed code, and even if they released the source code and met the GPLv2 bargin in every way, the GPLv3 would require them to either stop using the GPL-ed microcode, or to share the DRM key with the public at large (which includes our friendly virus writers). What you and the FSF is missing is that there are lots of legitimate cases where the "desire to trust a piece of hardware" overrides the "desire to modify hardware". A blanket "freedom must always override physical trust" characterisation can only be true in a society where laws are /always/ fair and are always enforced and acted upon. Such a society does not exist.
4 points Posted Oct 6, 2006 12:16 UTC (Fri) by alexbk (guest, #37839) [Link] Much better case than a Tivo would be latest Nokia phones, which *are* general purpose computers that happen to have smaller than normal screens and keyboards. These phones also have a sophisticated mechanism for verification of installed applications called Symbian Signed. That mechanism ensures that only Nokia and vendors approved by them can write software that does interesting things such as getting coordinates from built-in GPS receiver or working with the phone's microphone and speaker. They can legally use GPLv2 software to do that, and keep the keys to themsevles. Saying "don't buy the phones if you don't like that" is not really an option - there are no other devices that offer similar functionality.
Also, when you say "desire to trust a piece of hardware" you should be more specific - who has that desire, and who owns the hardware?
4 points Posted Oct 6, 2006 14:15 UTC (Fri) by sepreece (subscriber, #19270) [Link] "Saying "don't buy the phones if you don't like that" is not really an option - there are no other devices that offer similar functionality."
I would argue both with the statement (there are devices with similar functionality from other manufacturers) and the apparent conclusion that the uniqueness of a particular device would somehow create a special obligation to allow you to modify it. If you don't like what the device allows, don't buy it. It's not life-critical that you own one.
Note that there is no real asymmetry here, either. Only you (or someone you have authorized, like your service provider) has access to the device to load software into it. Nokia can't, because it has no access (unless you take the phone in and ask them to). You can choose to load various software into it, but that software comes from a constrained set. That's different from "you can modify the software but I can't".
4 points Posted Oct 6, 2006 15:30 UTC (Fri) by alexbk (guest, #37839) [Link] Uhm, you seem to have misunderstood me. My point was that if Ingo thinks Tivo is a bad example because it's only a narrow-purpose appliance, I can give a different and hopefully better example of an increasingly popular (24 million units shipped H1 2006 vs 14 million in H1 2005) general purpose programmable computer running Symbian OS, where access to some (but not all!) important APIs and hardware peripherals is restricted.
The manufacturers don't have an obligation to give me that access of course, but then I don't want them to use and modify my code for their benefit *and* disallow everyone else including me to do the same thing. Once again: they're not producing a Tivoesque appliance but a real computer. Nothing to do with demanding freedom to tinker, everything to do with being fair.
If you know similar devices that are less restricted, please name them, I always want to know about new gadgets :)
Stallman's quote in real context Posted Oct 6, 2006 14:27 UTC (Fri) by cventers (subscriber, #31465) [Link] Ingo,
I hesitate to reply to you here because you still haven't addressed any
It's interesting that you quote Stallman here, and so has Jonathan. I
To quote Stallman further:
> But I don't think that's where the social and political issues arise.
The Tivo is a good deal different from a microwave oven because its
is one of countless sites on the subject that Google presents when
I don't think a microwave oven would be likely to ever fall into this
But it's not just Tivo we should be worried about. Think about another
This project is a GPL-licensed firmware replacement for MP3 players from
I hope I'm not the first free software developer to ask this question,
How long before the manufacturers of MP3 players realize they can take
I know you're not a Rockbox developer. Neither am I. But since you argue
Despite Stallman's great crystal ball, it seems the world still changes
And I further hope that you won't drop the other thread of discussion we
Stallman's quote in real context Posted Oct 6, 2006 14:32 UTC (Fri) by cventers (subscriber, #31465) [Link] Ah, I made a goof. When I said:
> How long before the manufacturers of MP3 players realize they can take
I should have said 'changing the software.'
But the goof may raise an interesting counter-argument, 'the GPLv3 cannot
Stallman's quote in real context Posted Oct 7, 2006 3:01 UTC (Sat) by sbergman27 (guest, #10767) [Link] Just to give you some credibility, could you please post a link to some code which you have released under GPLv2 which will be automatically colicensed under GPLv3 when it is released?
Or are you simply in this to push your politics?
Could you pass the red herring please? Posted Oct 7, 2006 7:10 UTC (Sat) by cventers (subscriber, #31465) [Link] I will not participate in any attempts to turn what is hopefully aninsightful discussion into a pissing match. And I almost did. I was in the process of tarballing up some unreleased (as in prealpha) stuff I've been hacking on for months, but I realized that it would be a poor waste of my time to divert in order to satisfy this red herring you are now attempting to serve. Incidentally it appears that the GPLv3 will be ready by the time I issue an alpha release of my server software and its supporting 'C' library. And I fully intend to skip the relicensing step and move straight to version 3, especially because I think the new anti-DRM provisions might be specifically relevant to some things I'm currently doing. I promise of course that I would have fully appreciated the opportunity to automatically relicense had that been a necessity. I argue now because Ingo proposes to deny me the chance to vote with this new code of mine at all. He seems to want this license development stopped. I don't think Ingo would succeed in stopping the process, but I speak as someone who cares deeply about that process and as someone who will absolutely engage in code release under GPLv3, and who would rather do that release under GPLv3 than the less good (but still quite good) GPLv2. Notice that I'm specifically avoiding telling him what I think he ought to do with his stuff, or you with yours, because I have no stake in that. I have no doubt in my mind that your next reply will criticize me on the grounds of not having published code about to undergo relicensing. Since that is surely your intent, fire away and enjoy. Credibility is a funny thing - it is the first and last thing people like to attack when they can find absolutely no other argumentative point of substance. You accuse me of politics when attacks on credibility rather than reasoned analysis are most often performed by the dirtiest of politicians. So I'll ask you to pardon me if I roll my eyes while you are busy adding your two cents to this conversation. But I promise that I won't do that if you instead decide to say something of substance.
Stallman's quote in real context Posted Oct 7, 2006 8:23 UTC (Sat) by stijn (subscriber, #570) [Link] That is a very poor diversion. Ad hominem. Now for your arguments please.
4 points Posted Oct 6, 2006 10:10 UTC (Fri) by mingo (subscriber, #31122) [Link] Removing "or later versions" would lead to many new free software projects later arriving in the same mess the Linux copyrights are in. If an absurd interpretation of GPLv2 was ruled valid by a court tomorrow, what would Linux do? It would have to relicence and it would be a mess. FSF foresaw this mess decades ago and put two infrastructures in place. One is the "or later versions" language, another is the copyright assignment for GNU projects. two quick points. Firstly, i have heard this "what if the GPLv2 is ruled unenforceable" boogeyman a number of times. It is just not happening. What is happening is that the GPLv2 is alive and kicking and enforced (and even litigated) in lots of important jurisdictions. A healthy number of precedents have built up in Europe for example, and in the US 99%+ of the defendants rushed into settlements without even thinking about a trial. Judges in Germany, the US and elsewhere are showing a clear and deep understanding the GPL and the obligations attached to it. Please think about it, and dont just accept the FSF's position at face value. Please show some critical thinking. On one side of the equation are more than 1 billion lines of code, worth tens of billions of US dollars, given away for free, with a few common-sense conditions attached to it, described in very clear words (in the GPLv2) that is easily translated to many languages, and which has been enforced to the true letter and intent of that license in important jurisdictions. On the other hand we have the theoretical worst-case possibility of some other jurisdiction suddenly growing an "absurd" interpretation of the GPLv2, which, i assume, would mean the forfeiture of the whole codebase and its putting into the public domain. What is better protection against absurdity than the plain and clear language of the GPLv2. Secondly, what kind of judge do you think would do that to a body of work that has such a huge value, which wouldnt immediately be overturned on appeal? Judges are often amongst the fairest and most objective people in most societies (even in dictatorships), and the law is based on thousands of years of history of fairness. I trust judges a lot more to interpret my license than i trust a mathematician that is currently presiding the FSF ... Secondly, it is a false dichotomy to suggest that the only option is a total rewrite of the GPLv2. There are lots of options. The FSF could add a limiting language like: "if any portion of the license becomes unenforceable then we reserve the option to correct that language, with the minimal amount of changes needed to make it enforceable again". Problem solved via GPLv2.01. But i get the feeling that giving up power and letting the community go is quite hard for Richard Stallman to do ...
The crux of the issue Posted Oct 6, 2006 14:52 UTC (Fri) by cventers (subscriber, #31465) [Link] Ingo,
(I shall include by reference my request made elsewhere that you return
> Firstly, i have heard this "what if the GPLv2 is ruled unenforceable"
You're right. GPLv2 is a strong license. And I think no one does a better
> Please think about it, and dont just accept the FSF's position at face
You know Ingo, it is perfectly valid for you to hold an opinion on this
Attorneys don't sit around passively and react to situations; part of
No matter how unlikely you think it is that GPLv2 could ever fail to do
Once again, it is important to realize that Linux, a largely Western
So I think it's damn essential that the GPL not only defend our software
Once again, Ingo, you have the full right of not using GPLv3, and I have
> On one side of the equation are more than 1 billion lines of code,
I find it interesting that you keep referring to the large body of GPL
But when it is the FSF proposing to defend those billions of lines of
So you don't want the FSF - the drafters of the GPL license, the
Mr. Molnar, I'm beginning to suspect the reason you haven't replied to
4 points Posted Oct 7, 2006 4:28 UTC (Sat) by bojan (subscriber, #14302) [Link] > The keys needed to run a piece of software are not a "totally seperate work". If the two were not intertwined, they would not have the relationship of one being necessary for the other to run.
Actually, the keys are most likely not a "work" in terms of copyright at all. I would say too unoriginal. I doubt one could obtain copyright on any kind of cryptographics keys.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 16:00 UTC (Thu) by cventers (subscriber, #31465) [Link] Ingo,
Thanks for the response. To continue:
> The contention that this somehow turns into a "right to tweak the
Well, let's be careful about what we're talking about here. I agree with
By contrast, the anti-DRM provisions say "don't use technological means
So it's really not about the right to tweak the hardware at all. It's
> The term "right to tweak" has been invented well after the GPLv2 was
Well, I'm not using "right to tweak" as the language and I don't think
- The freedom to run the program, for any purpose (freedom 0).
We are talking about freedom #1. The Tivo device (sort of) adheres to #0,
And if you're thinking "ROMs don't provide #1 either", you're right. But
> No-one in their right mind, neither i nor Linus ever understood that
I don't think "you have to allow to make binaries in ROM's modifiable" is
> But note that the section you cited talks about source code (i
As stated, Tivo doesn't respect freedom #1. Putting in a crypto
> (That is, by the way, also a conflict in the position of the FSF: for
It's still absolutely a license. It doesn't affect hardware where the
> The contention that DRM and using crypto keys to protect hardware
I suppose you're right about the microcode example; thanks for the
The virus writer example goes too far. My reason is an analogy on free
> IMO this whole thing that to me appears to be a vendetta against DRM is
Vendetta against DRM? That's absolutely true. But I guess what is hard
> I believe that in the light of this debacle the only sane and morally
I don't see why. I know you don't agree with them now, but you agreed to
And I also think that your "sane and morally correct solution" assumes
The FSF is not releasing a new GPLv3 that says "You may have this code to
Or are you worried that the GPLv3 is going to catch on, and you
> and to remove the "or later" language from the default
But that language is there for a reason, as a utility! It _is_ and has
I resent this notion that programmers are so lazy as to ignore the
Perhaps there are some developers, in a minority, that did so and are now
> In fact: the FSF, just like Linus, should reject blanket authorizations
Well, I trust the FSF, but that's a philosophical argument for another
> Dont let inertia and laziness drive an important decision like that.
Ingo, if people are that prone to inertia and laziness, we're all
> That way authors of new code can judge the licenses on their merits
They can do that today. They can do as Linus has done, and state "GPLv2
And that is absolutely letting the authors decide. At that point if
> and the FSF can release new licenses at a much
If the FSF releases licenses at a faster pace, that is a sign that
You might be tempted to speak as Linus has here - "The GPLv2 has no
You mention "release early, release often". One of the big reasons for
Why, Ingo, aren't you getting involved?
(sorry if that grates on your nerves, but I do think it's a fair
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 19:14 UTC (Thu) by AJWM (guest, #15888) [Link] > Why, Ingo, aren't you getting involved?
> (sorry if that grates on your nerves, but I do think it's a fair question...)
Considering the volume of messages on this subject I've seen here from Ingo, and their thoughtfulness, I'd say it was neither a fair question nor a very intelligent question.
He is involved. Just apparently not in the manner that you'd like him to be.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 19:28 UTC (Thu) by cventers (subscriber, #31465) [Link] Pardon me but I think you are missing the rest of the comments I've madealong those lines in my discussion with Ingo, and thusly I don't consider your judgement of the apparent intelligence or fairness valid.
As I've pointed out before, it's one thing to debate the license on LWN,
I very much appreciate that Ingo is taking his time to write the comments
So I believe the question still stands, and since that question was
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 20:48 UTC (Thu) by sepreece (subscriber, #19270) [Link] "So it's really not about the right to tweak the hardware at all. It'svery much about the right to tweak the _software_."
Yes, but it's about the right to tweak the software within a particular piece of hardware, so it clearly extends beyond just the software. Depending on the specific mechanism used to implement trust in a device, "keys and authorization codes" might also be required to allow changing values stored in special-purpose areas in the hardware, which also sounds like "tweaking the hardware."
"The virus writer example goes too far. My reason is an analogy on free
Note that the great mass of people have repeatedly shown themselve to be eager to trade rights that they have no desire to exercise for increased security. The vast majority of the people I know, aside from those in software jobs, would be completely happy to have hardware that ran only software signed by some trusted authority, if in return they didn't have to worry about viruses and other attacks.
"As stated, Tivo doesn't respect freedom #1."
Well, that's the crux of the issue between the sub-communities. We see freedom #1 as saying, on its face, "you are free to run this software on any device that will run it"; you see freedom #1 as saying, on its face, "you are free to run this software on this particular device". So, to us, Tivo is respecting freedom #1 and to you it isn't.
The other thing that concerns me about the anti-Tivoization language in the current draft is that it seems to claim some right to impose restrictions on the non-GPL software in the device. Maybe. The language is unfortunately ambiguous [this is a problem in the most of the controversial areas of the license, as might be expected, given that they're where the most change occurred].
That is, in requiring that "if it's a DVD player, a modified version must still play the same disks", it seems to putting requirements on the whole body of software in the device, proprietary and non-proprietary, not just on the GPLed components. [It is also possible to read the section narrowly, in which case you would have to assume it meant that the DVD player in the example was entirely GPLed software.]
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 21:33 UTC (Thu) by cventers (subscriber, #31465) [Link] > Yes, but it's about the right to tweak the software within a particular> piece of hardware, so it clearly extends beyond just the software.
I don't see how this is true at all. It's merely making sure that you can
That says nothing about what they're allowed to do with the hardware.
> Depending on the specific mechanism used to implement trust in a
Can you give an example? I can take some guesses but I'd rather discuss
> Well, that's the crux of the issue between the sub-communities. We see
Pardon? Freedom #0 is the freedom to run it as you wish. Freedom #1 is
> Note that the great mass of people have repeatedly shown themselve to
Granted, but I'm not sure if you're invoking this to imply anything in
I can understand mere disagreement over this point but when you really
> That is, in requiring that "if it's a DVD player, a modified version
The example is expanding on the idea of including keys necessary to
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 5, 2006 23:34 UTC (Thu) by jdivine (guest, #18042) [Link] > Pardon? Freedom #0 is the freedom to run it as you wish. Freedom #1 is> the freedom to modify it as you wish. If the manufacturer slaps a lock on > the software to prevent you from modifying it, how could the manufacturer > possibly be construed as upholding the freedom that says you are free to > modify?
They aren't preventing you from _modifying_ the software. You can modify the software all you want. They are preventing you from _running_ the modified software on the particular piece of hardware they manufactured. You can adapt the code, use it in other programs and on other devices, do whatever you want with it.
You may want to run modified code on the device you bought from them (which is totally reasonable) but your freedom to modify the code has not been abridged.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 6, 2006 1:48 UTC (Fri) by sepreece (subscriber, #19270) [Link] I think we've gone around the particular tree enough times, so I'm not going to do a detailed response. Just a couple of quick answers to specific points:
I apologize for forgetting that the FSF numbers the freedoms from 0. I meant 0.
The point about the willingness of people to trade freedom for security was in response to your "The virus writer example goes too far. My reason is an analogy on free society - it would be like the police asking for us to give up our rights so that we don't get stabbed by burglars or something." The point is just that while it may be too far for you, many people would disagree.
I simply disagree with you about priorities. I think there are devices where trust is more important the user's ability to modify the software in the device, and I would not have any problem at all with my software being used in such devices. Obviously, YMMV.
And, finally, yes, I have been commenting on the GPLv3 drafts.
Cherry-picked Posted Oct 6, 2006 23:00 UTC (Fri) by man_ls (subscriber, #15091) [Link] The vast majority of the people I know, aside from those in software jobs, would be completely happy to have hardware that ran only software signed by some trusted authority, if in return they didn't have to worry about viruses and other attacks.I like this one. Let me use a counter-example: I own a PSP. The vast majority of the people I know, including those in software jobs, have chosen a PSP because it can be cracked to run software not signed from a trusted authority. They don't give a damn about viruses and other attacks; they want to run:
Cherry-picked Posted Oct 8, 2006 1:34 UTC (Sun) by sepreece (subscriber, #19270) [Link] Perhaps we travel in different circles. I do know a few young people who do use PSPs, as you describe, for things the manufacturer did not authorize. However, they are a small minority of the people I know. The ones who are older than, say, 35, would mostly REALLY like to not have to worry about malware coming with their e-mail or from visiting poorly chosen websites. And they're mostly Windows users, because it's the path of least resistance.
I'm not saying that's good, nor am I saying I disapprove of the kids using cracks on their PSPs. My statement was just about the general public.
Cherry-picked Posted Oct 8, 2006 2:46 UTC (Sun) by man_ls (subscriber, #15091) [Link] Maybe we could temporarily conclude that people over 35 choose security over freedom. And that people over 35 are the majority of people in occidental societies (so that "the general public" is mostly composed of people over 35). A tentative reason could be that people over 35 have more money than desire of freedom, at least those in your circle.Certainly people in my circle prefer to crack their PSP's than pay 60 per game; and prefer to play DivX movies of random sizes than convert everything to MPEG4 320x240 -- or pay for Sony's absurd multimedia kit. Even people over 35. So yes, we must travel in different circles. If you don't live around the metropolitan area of Madrid, Spain, Europe, then we indeed travel in different circles. So your original statement: Note that the great mass of people have repeatedly shown themselve to be eager to trade rights that they have no desire to exercise for increased security.is void, at least in the great picture. Luckily, I would add. We might change it to read "most US people over 35", but it would lose some weight. We could also conclude that those "rights that they have no desire to exercise" change depending on your age and country of origin, with the same overall effect. Your statement doesn't add much to the discussion apart from giving weight to the quote attributed to Benjamin Franklin: Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety.
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 6, 2006 15:00 UTC (Fri) by mingo (subscriber, #31122) [Link] > The contention that this somehow turns into a "right to tweak the > hardware" is false. Well, let's be careful about what we're talking about here. I agree with you and others when you mention that some devices already put software into ROM. If the FSF were trying to ensure a right to tweak hardware, there would probably be language prohibiting putting GPL code into ROM. By contrast, the anti-DRM provisions say "don't use technological means to circumvent the license".Why are you changing the topic and continuing to discuss that new topic without addressing the question I raised? What i talked about in the post you replied to was the interpretation of the GPLv2 that does not show any "right to tweak". It was /your/ contention in the original post that the GPLv2 talks about something that results in the "right to tweak", and that this somehow justifies the GPLv3's attempts to control hardware. It was /you/ who quoted the GPLv2's opening section to underscore it. I repeat: how could Linus have considered this new-found, retroactive, absurd and illogical interpretation of the GPLv2 in 1991? How could i have considered it when i started contributing to Linux in 1995?
Staying on track Posted Oct 6, 2006 15:17 UTC (Fri) by cventers (subscriber, #31465) [Link] Ingo,
I regret to see that you have not extended me the same favor of replying
There is a very distinct difference between the right to tweak hardware
The operative difference -- the very reason for an anti-DRM provision in
I think Linus, and now you, are doing people a disservice when drawing a
But the simple fact of the matter is that the hardware and software is
Why don't you respond to the real issue instead of covering it in this
"Ours is Ours, Yours is Yours" is gone from the GPLv3 ... Posted Oct 7, 2006 5:17 UTC (Sat) by bojan (subscriber, #14302) [Link] > #3. You can't adapt the program to your needs or the device will refuse to start!
I think that's the point that kernel deveoplers have been trying to make - *that* device won't start.
However, by purchasing a different device, they say, Freedom #1 is restored.
Now, if *all* devices on the market were DRM devices, of course, Freedom #1 could not be regained but by a few that hold the keys.
I would think that hardware manufacturers will go all-DRM if that's what the market forces start demanding (i.e. Hollywood says so :-). GPLv3 or not.
> And if you're thinking "ROMs don't provide #1 either", you're right. But the FSF doesn't want to make hardware design decisions for manufacturers.
Hmm, it would seem to me (and I'm still very much undecided on the GPLv3 v. GPLv2 issue) that in fact new anti-DRM provisions do exactly that. They effectively say to hardware manufacturers: "If you build a DRM chip into the machine and want to ship GPLv3 software on it, you may as well not have the chip as it will be useless".
Again, it all depends on what the market will decide regarding DRM hardware. One thing is probably foreseeable: if Linux kernel were to go GPLv3 today, most DRM devices would most likely not ship it.
hackability by the people Posted Oct 5, 2006 16:08 UTC (Thu) by atai (subscriber, #10977) [Link] If in 1991 the PC has had something like today's DRM to limit what can be run and people need to purchase special hardware (and probably software, assuming free tools like gcc cannot run) at some high cost to do development for the PC platform, Linux could not get contributions from so many people so easily. And it is these people who gave Linux the critical mass by 1998 before major commercial interests got interested in Linux.
the reference Posted Oct 5, 2006 15:04 UTC (Thu) by coriordan (guest, #7544) [Link] Just to fill out the information. The paragraph that you mentioned as being removed was removed in draft 2 (it was still there in draft 1). The rationale for it's removal is: "We have deleted this statement of intent; we consider it unnecessary. It also had the disadvantage of using terminology specific to U.S. copyright law." From the draft 1 to draft 2 changes document (PDF).
the reference Posted Oct 6, 2006 9:08 UTC (Fri) by mingo (subscriber, #31122) [Link] The rationale for it's removal is: "We have deleted this statement of intent; we consider it unnecessary. It also had the disadvantage of using terminology specific to U.S. copyright law." So is it your position that the GPLv3 is not trying to control (and is not intending to control) any works that are independent of any GPLv3 codebase?
the reference Posted Oct 6, 2006 23:22 UTC (Fri) by man_ls (subscriber, #15091) [Link] I will be glad to hear Ciaran's answer to this point, but I will give my point of view too: yes, the GPLv3 is not trying nor intending to control any works independent of any GPLv3 codebase, as long as it is not essential to deploy and run the GPLv3 codebase. Why? Because if said work is required to deploy and run the GPLv3 codebase, it should not be said to be independent; it is either dependent or it is not a "work".I cannot rent you a house and then withdraw the keys. Similarly, if the GPLv2 explicitly states that software should include: [...] all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.You will agree that a crypto key (essentially, a big prime number) required for "installation of the executable" is not too far away from the definition. In fact it might be thought to be part of the "script used to control installation". So, is this prime number independent of the work under the GPLv3? Well, given that numbers are not copyrightable (even if they can be patented), I would say it is independent. Is it an "independent work"? I would say that a random prime number cannot be "a work", so it can hardly be "an independent work". So is it part of the hardware? Well, I don't think so because numbers do not belong in hardware. Also, the prime number seems to be definitely part of the "installation script" (as any other magic number). Just as if the script needed a password, or a magic memory address, to install the software. So, even under the GPLv2 the intent seems to be clear, even if the case is not so clear-cut and a cryptographically-challenged judge might think otherwise.
|
|||||||||||||