It couldn't have been reported that way "through the ages", because
I meant that those phrases were what we have got after the reporting through the ages. The point is not that they are (in)accurate, but that they are likely as not (without other evidence) equally so, and therefore to claim one is "gods law" and the other "mans moronic attempt..." is ridiculous. I know about the translation issues - but they aren't necessary to make the point.
There is consensus among biblical scholars that the passage was closer to "Don't murder". But that's also ambiguous in English, with many court cases depending on how the jury members interpret the word "murder" (and how they interpret the judge's instructions).
Indeed - which makes it even sillier to claim as "gods law" as it makes gods law subject to man's definition:
"thou shalt not commit murder as thou define it in thy jurisdiction"
might as well say "do what thou wilt (if you are in charge)".
That would of course make the old testament neatly consistent if you define "murder" as excluding enemies/other races/other religions/etc. - you can then both keep the commandments and kill kill kill.
That does of course bring us right into "fanatical idiots" territory...
That would be God's instruction to man as reported through the ages, by man, in the Bible and its ancestor documents.
This would be a human's moronic attempt to "spread the word":
Now go over that hill there and kill everyone you find
That would be God's instruction to man as reported through the ages, by man, in the Bible and its ancestor documents (try I Sam 15.2-3, Exodus 32:27, or many others).
Yes, it could be a false claim (of instruction by god) by fanatical idiots, but that applies to the first statement as well.
Linux would be pretty damn boring if it was just the kernel and no GNU apps
For you maybe, perhaps because you think it would be too hard to write all your own stuff and do without an MMU etc. For others, it is interesting for precisely the same reasons.
GNU does not target real time or embedded systems (eight megs and swap for a text editor, and that back in the 80s!). Linux, however, does target such systems.
It is possible to write a license that clearly differentiates these two cases... so let's do it!
Difficult, if not impossible. From the point of view of the software (which is the only thing to which the license applies) the two cases are exactly the same - the software is signed. That is all.
What is done afterwards upon verifying that signature is out of the control of the author / distributor, and of the software license. To be specific, the author/distributor does not control the "usual device".
As far as I can see there are these possibilities:
1. You don't have to release a signing key ever. 2. You don't have to _unless_, at the time, you yourself also release containing hardware/software environment (the "usual device") which requires the code to be signed with your key (ie. you have to be also responsible for the requirement) 3. You might have to release the key if third party or events outside your control make it a requirement for the code to be signed with your key 4. You always have to release a signing key.
Now, 1 & 2 are equivalent - the clause has no teeth (because 2 is trivial to avoid - see 3), and 3 & 4 are also equivalent since you are commiting to release the key if certain things (outside your control) happen. So overall, either the clause does nothing, or Linus is right.
On the other hand, if the modified software can run properly on the usual device without those private keys, then you don't have to release the keys
You think this makes things clear and distinguishes the cases, but it doesn't. The "usual device" for signed code is surely one which does not run unsigned code. That is the point of signing the code in the first place.
Saying that it is ok if the device can be modified to accept other signatures does not cut it - this is then a modified device, not the "usual device". Similarly, having a device allowed unsigned / untrusted code but with the user having to accept it (after warning or whatever) manually is not be enough. GPLv3 says it has to be so "its functioning in all circumstances is identical" [to the original] therefore the system can't treat the unsigned modified versoin differently.
If bluehat OS has an auto update system, then I think GPLv3 genuinely is saying that a user must be able to modify an update such that any instance bluehat OS (in its usual configuration) will treat the modified update in exactly the same way as the original. That means that either the system must treat all updates as equal, whether signed or not, or that the signing keys have to be provided.
You may think this is insane (as Linus said) and completely insecure etc. - but it would actually be entirely consistent with RMS's past views/actions on computer security.
Simple: you disclose the hardware's private key to the user, so that he can make the decision about what code he wants to run. It's still a secret: unless the owner of the machine tells a third party the key, that third party won't be able to circumvent the system.
Er, user or owner, or can't decide which ? It's the user's machine, after all!
Ah, you assume user == owner, rather restricts applicability of your arguments... And if the user wants to run a root kit, he should be allowed to do it! It's none of the company's damn business what the user does with his own property!!
It is if it has, for example, safety implications on the device, and the user then sues the company for not preventing him from shooting himself in the foot. Users do that.
And what if it isn't the user's property ? Suppose the user is in a nuclear power station control room - should he still be allowed to run a rootkit on the computers ? The only thing that the GPL v.3 prohibits is stuff that locks the user out of his own property.
No it doesn't. I don't think you've read it - unless you can quote from the draft where it says that things are prohibited if the device is the property of the user ? Security means that the user gets to choose what runs on his machine, not some third party which may or may not be hostile (this includes the manufacturer of the device).
Security in an flight control system means that only software tested and certified for flight is allowed. It is an independent third party (not the owner or user) that gets to choose what modifications are allowed to be made to an aircraft - for damn good reasons. Let's make an analogy: would you like to give the builder who built your house the ability to change the locks one day while you're out, and not let you back in to your own property? Of course not!
Would you like to give the manufacturer of your aircraft the ability to ground it one day ? Of course not! You want to carry on flying to make money, ADs or not.
Thankfully for your passengers and those living under your flightpath, in the real world you _don't_ get to do whatever you want just because something is "your property", and it _is_ other peoples' business what you do with it, because it may be (at the extreme) their lives at stake.
there might be a scenario where someone was more innocently left in a position of non-compliance, but I can't really think of a situation where that would be due to anything but a lack of due dilligence on their part. [...] Get legal advice from an attourney able to represent you in your jurisdiction if you actually run into this or any other legal problem.
You seem to be saying that things are sufficiently uncertain that a developer releasing signed code under GPLv3 needs to get legal advice to determine whether or not they have to ship their private key.
Many thousands of small / individual FOSS developers will not have the resource for lawyers and for them, GPLv3 effectively bans code signing (but probably doesn't for big-nasty-corp-with-lots-of-lawyers).
You only need a license to do something that would otherwise be illegal - like distributing the copyrighted linux kernel.
Yes...
Alan hasn't distributed any hardware that requires his signature to a kernel.
Which is completely irrelevant, because as you already said, you don't need to comply with the license to do that.
What Alan does do is distribute the software, signed (little reason to sign it if you aren't going to distribute it). So Alan is the one who might have to release his keys to comply with the license. On the other hand, someone who makes hardware doesn't need to distribute any software in order to make hardware that will run (only) the signed software, so they can't be held to anything.
If you read what Linus' has said on the subject he knows _exactly_ why he chose to move the kernel to GPL (it didn't start out that way). It has nothing to do with "freedom" and everything to do with "fairness" and "reciprocity" - which GPL also happens to do quite well.
It could be that half the code in the kernel is GPL3 and half of it is GPL2. In that case, you would need to abide by the restrictions on both licenses in order to distribute it.
Wrong, it can't be that way. GPL3 _adds_ restrictions (eg. the DRM stuff) over and above GPL2. GPL2 _forbids_ adding restrictions. The two are fundamentally incompatible - all the code has to be under one or the other. [ note that that doesn't preclude some code being under _either_ (eg. "GPLv2 or later"), but it does mean that you can't mix code that is _only_ GPL2 with code that is _only_ GPL3 ].
Actually English law on child porn was changed recently to 18.
Certain famous Page3 models from years gone by started at 16 or 17, so if you have an archive of the Sun newspaper you probably now have kiddie porn (yes, allegedly it is retrospective). Lock up the librarians and throw away the key.
England is also where people have famously (tv news presenter) been taken to court under kiddie porn laws for daring to take pictures of their kids in the bath.
Furthermore, the age of consent is still 16. The English teenagers who at 16 can legally have sex, get married, have kids etc., now presumably can't even possess a picture of themselves in the bath let alone their kids.
Oh, and say you're a middle aged male, then having (consensual) sex with a 16 year old girl is perfectly legal, but if she emails you a nude picture of herself you're an evil pedo child pornographer. Why is the picture of the 16yo child illegal - well, because it might lead to you wanting to have sex with the child, so it's illegal because it leads people on to "worse" things which are themselves... er... legal.
Maybe I just don't get it, but seems to me like our collective moral compass is bent so far it's disappearing up its own arse.
Er, piracy is the illegal seizure of a ship by armed force, and traditionally with rape / enslavement / execution etc. of those on board. Not only is/was piracy the moral equivalent of rape of children in many penal codes, it also frequently included the same in its commission.
Your comment shows that **AA have already convinced you (amongst many) that breaching a copyright licence is equivalent to rape and pillage on the high seas.
They have done this with very deliberate PR and with the clear intention of elevating the perceived gravity of the offence. It appears to have worked. If they think they can get file-sharing associated with child porn then they undoubtedly will, and probably terrorism etc. as well.
think about it.
Who most wants to identify P2P users ? What are the most common arguments we hear against anonymous P2P networks ?
[ A: RIAA / MPAA, and "used for child porn and terrorism" ]
Two choices: author/distributor defines it, or third party / outside events.
So, I don't really agree with this view of it.
Actually we do agree - i would say the court is a third party.
Courts don't always rule the way we think is right. Results can easily depend on who has most money, for one.
Where we seem to be is that this licence says that under some circumstances you may have to hand over your signing keys, those circumstances left deliberately vague to be decided by court.
I wouldn't want to sign up to that, and nor does Linus.
If the licence said "you are not required to release private keys you have used to sign the work for verification of origin purposes" then that might be ok.
That's one reason Tivo would be forced to give up their secret codes while Linus would not. Very simply, Linus's private keys are not "necessary to install and/or execute the source code of the work" on my PC.
On your PC. Today. Tomorrow ? Who knows.
The point is that Linus doesn't make your PC, ergo he is not in control of whether or not his private keys are necessary. Anyone with access to his _public_ key can implement the requirement that code be signed with his _private_ key. If Linus distributed a signed kernel, TIVO could require _his_ signature, then, if you want to modify the code running on your TIVO, Linus has to give up his keys.
Whether or not he would be forced to give up his keys, under gpl v3, might then depend (as you say) on "recommended context of use". So who defines that (not the FSF, since it is specific to the code in question) ?
Two choices: author/distributor defines it, or third party / outside events.
If the author controls the definition, then TIVO controls it, and it could exclude _your_ TIVO, thus still preventing you modifying code and running it on _your_ TIVO.
If the author does _not_ control the definition, then Linus does not control it and we are back with the possibility that he _could_ be forced to release his signing keys by events outside of his control.
So basically I can't see how you can throw out DRM/TCPA without also throwing out other beneficial uses of code signing.
author != distributor. Obligations are on distributor. Distribution is as "v2 or later".
Where in "how to apply these terms..." does it suggest you can say eg. "I distribute this to you under v2, you may re-distribtute under v2 or later" ? I have never seen anyone do this - this is what you would have to do, no ?
nobody can make you do anything
Recipients can make you honour your obligations (eg. source distribution) under the licence. This has already happened.
In terms of your other "only" risk - FSF could be bought out by (say) MS. No problem, they can't rescind GPLv2 and take away our freedoms. They _could_ make the GPL v4 be BSD licence. Doesn't take away your freedom. Does put your code (potentially) into Windows, and nothing you can do about it.
Nor does it matter if we create a large infrastructure where Linus signs his releases and we write software that rejects unsigned releases
The fact that you _could_ use the unsigned releases elsewhere is irrelevant [or else TIVO could say that you _could_ run their source unsigned elsewhere].
The "recommended or principal context of use" would be an environment that checks for the signature (which is the whole damn point), therefore the keys would have to be disclosed.
GPLv3 attempts to prohibit its use with any sort of trusted distribution architecture. It doesn't (and probably isn't able to) make distinction between "good" or "bad" trusted distribution.
- or at least that is the way Linus seems to read it and is one reason why he says he rejects it. I have to say I agree with his reading of it.
ONLY if the original version contained a method for obtaining the source code from the server somehow, any modified version should also implement that functionality. although this didn't make it to the first draft
Thankfully.
Being able to obtain web-app source code from the server is/was a common security hole. Your wording would force any application shipping with such a hole to never fix it. It probably wasn't your intention to omit "intentional"...
And those additional options could have effects you don't want as a distributor, potentially taking away your rights.
Example:
Under GPLv2 you have the right to charge for the act of source distribution.
GPLv3 _could_ require that you distribute for free (it doesn't in this draft, but it does change the wording on that requirement).
If you've been distributing as "GPL v2 or later" at the user's discretion, then when that hypothetical GPL v3 comes out, users can require you to ship source for no payment. Hence, your right to be paid for your source distribution costs would have been taken away.
Do you think everyone in the world could have collaborated on a big project like this without a free compiler and free libraries that everyone could use?
Nope. Of course same applies to many other components eg. windowing system, server applications etc. etc.. Everything had to come together.
Happily it did, and Linux and *BSD came out of that availability, at around the same time.
Er, sorry - that's GNU/Linux and er notGNU/BSD because GNU/Linux uses the GNU compiler and toolchain and BSD uses the.... GNU compiler and toolchain. Oh. So then it must be GNU/BSD, except it's not.
Must be the userspace, after all BSD has its own userspace...
And I don't see where all the userspace stuff was going to come from if not the FSF guys... or how the kernel would have been very useful without it.
Ok, so now BSD is not GNU/BSD, despite being dependent on the GNU compiler / toolchain, because it doesn't depend on the rest of the GNU userspace. Whilst Linux is GNU/Linux because there was nowhere else for a free userspace to come from other than the FSF.
The GPLv3 will be fundamentally incompatible with any program using the Trusted Computing, because all the necessary keys can never be revealed. I assume that is the point
Exactly.
And Linus's point is that that makes it fundamentally incompatible with other forms of code signing too. The whole "Trusted Computing" thing is just a logical extension of current code-signing practice, you can't ban one without affecting the other.
Example: You want your OS's auto-update mechanism to validate updates against your vendors' private key ? I do. That's how I trust it. Your OS is GPL v3 ? - then your vendor has to publish the keys. Bye bye trust.
Problem is, signing reqirements for _running_ a work are not something that is / can be enforced by the work, but rather by the hardware / environment in which it runs.
Probably the target is device-maker-A releases hardware running a version of Linux, hardware requires the version of Linux to be signed with their key - result: user effectively cannot modify the code for their device.
But nothing says that the device maker and the code signer are the same party, which means that as a code-signer, any third party could force you to release your signing keys (by requiring code to be signed by them in order to run). Of course this releasing the keys completely breaks the purpose of code signing which is (I guess) why Linus thinks it is silly.
If the clause _doesn't_ mean this, then I struggle to see what it is there for at all. It either forces people to disclose code signing keys or it doesn't - if there are loopholes so sometimes you do, sometimes you don't, then people will use them so they don't have to release keys at all.
With international (GSM) roaming, call receiver usually pays an additional roaming charge. Not a small charge either - in fact high enough that the EU has (or is) investigated the charges.
For people living near country borders (even commuting across them - common in some parts of europe) this can be a big deal.
Gee, ever think if MSFT just got of their high horse and listened to this guy
Then we'd be well and truly f**ked.
Since this guy stated that the hole was only for invalid record length of one, MS would just have blocked that. Meanwhile the existing exploits (with the source code - posted above - that you & Steve clearly didn't read / understand) would have carried on working despite the patch.
Happily, MS don't listen to him, and seem to be a bit better than him at analysing the exploits properly.
No problem. Now I guess you should get busy and patch your system... or maybe you run Linux;)
In which case you should still get busy and patch your system, since Linux patches for the vulnerability are available (a little later than the windows ones, but hey "win some, lose some".
Slashdot Mirror
It couldn't have been reported that way "through the ages", because
I meant that those phrases were what we have got after the reporting through the ages. The point is not that they are (in)accurate, but that they are likely as not (without other evidence) equally so, and therefore to claim one is "gods law" and the other "mans moronic attempt..." is ridiculous. I know about the translation issues - but they aren't necessary to make the point.
There is consensus among biblical scholars that the passage was closer to "Don't murder". But that's also ambiguous in English, with many court cases depending on how the jury members interpret the word "murder" (and how they interpret the judge's instructions).
Indeed - which makes it even sillier to claim as "gods law" as it makes gods law subject to man's definition:
"thou shalt not commit murder as thou define it in thy jurisdiction"
might as well say "do what thou wilt (if you are in charge)".
That would of course make the old testament neatly consistent if you define "murder" as excluding enemies/other races/other religions/etc. - you can then both keep the commandments and kill kill kill.
That does of course bring us right into "fanatical idiots" territory...
This would be God's Law:
Thou shalt not kill...
That would be God's instruction to man as reported through the ages, by man, in the Bible and its ancestor documents.
This would be a human's moronic attempt to "spread the word":
Now go over that hill there and kill everyone you find
That would be God's instruction to man as reported through the ages, by man, in the Bible and its ancestor documents (try I Sam 15.2-3,
Exodus 32:27, or many others).
Yes, it could be a false claim (of instruction by god) by fanatical idiots, but that applies to the first statement as well.
Linux would be pretty damn boring if it was just the kernel and no GNU apps
For you maybe, perhaps because you think it would be too hard to write all your own stuff and do without an MMU etc. For others, it is interesting for precisely the same reasons.
GNU does not target real time or embedded systems (eight megs and swap for a text editor, and that back in the 80s!). Linux, however, does target such systems.
It is possible to write a license that clearly differentiates these two cases... so let's do it!
Difficult, if not impossible. From the point of view of the software (which is the only thing to which the license applies) the two cases are exactly the same - the software is signed. That is all.
What is done afterwards upon verifying that signature is out of the control of the author / distributor, and of the software license. To be specific, the author/distributor does not control the "usual device".
As far as I can see there are these possibilities:
1. You don't have to release a signing key ever.
2. You don't have to _unless_, at the time, you yourself also release containing hardware/software environment (the "usual device") which requires the code to be signed with your key (ie. you have to be also responsible for the requirement)
3. You might have to release the key if third party or events outside your control make it a requirement for the code to be signed with your key
4. You always have to release a signing key.
Now, 1 & 2 are equivalent - the clause has no teeth (because 2 is trivial to avoid - see 3), and 3 & 4 are also equivalent since you are commiting to release the key if certain things (outside your control) happen. So overall, either the clause does nothing, or Linus is right.
On the other hand, if the modified software can run properly on the usual device without those private keys, then you don't have to release the keys
You think this makes things clear and distinguishes the cases, but it doesn't. The "usual device" for signed code is surely one which does not run unsigned code. That is the point of signing the code in the first place.
Saying that it is ok if the device can be modified to accept other signatures does not cut it - this is then a modified device, not the "usual device". Similarly, having a device allowed unsigned / untrusted code but with the user having to accept it (after warning or whatever) manually is not be enough. GPLv3 says it has to be so "its functioning in all circumstances is identical" [to the original] therefore the system can't treat the unsigned modified versoin differently.
If bluehat OS has an auto update system, then I think GPLv3 genuinely is saying that a user must be able to modify an update such that any instance bluehat OS (in its usual configuration) will treat the modified update in exactly the same way as the original. That means that either the system must treat all updates as equal, whether signed or not, or that the signing keys have to be provided.
You may think this is insane (as Linus said) and completely insecure etc. - but it would actually be entirely consistent with RMS's past views/actions on computer security.
Simple: you disclose the hardware's private key to the user, so that he can make the decision about what code he wants to run. It's still a secret: unless the owner of the machine tells a third party the key, that third party won't be able to circumvent the system.
Er, user or owner, or can't decide which ?
It's the user's machine, after all!
Ah, you assume user == owner, rather restricts applicability of your arguments...
And if the user wants to run a root kit, he should be allowed to do it! It's none of the company's damn business what the user does with his own property!!
It is if it has, for example, safety implications on the device, and the user then sues the company for not preventing him from shooting himself in the foot. Users do that.
And what if it isn't the user's property ? Suppose the user is in a nuclear power station control room - should he still be allowed to run a rootkit on the computers ?
The only thing that the GPL v.3 prohibits is stuff that locks the user out of his own property.
No it doesn't. I don't think you've read it - unless you can quote from the draft where it says that things are prohibited if the device is the property of the user ?
Security means that the user gets to choose what runs on his machine, not some third party which may or may not be hostile (this includes the manufacturer of the device).
Security in an flight control system means that only software tested and certified for flight is allowed. It is an independent third party (not the owner or user) that gets to choose what modifications are allowed to be made to an aircraft - for damn good reasons.
Let's make an analogy: would you like to give the builder who built your house the ability to change the locks one day while you're out, and not let you back in to your own property? Of course not!
Would you like to give the manufacturer of your aircraft the ability to ground it one day ? Of course not! You want to carry on flying to make money, ADs or not.
Thankfully for your passengers and those living under your flightpath, in the real world you _don't_ get to do whatever you want just because something is "your property", and it _is_ other peoples' business what you do with it, because it may be (at the extreme) their lives at stake.
there might be a scenario where someone was more innocently left in a position of non-compliance, but I can't really think of a situation where that would be due to anything but a lack of due dilligence on their part.
[...]
Get legal advice from an attourney able to represent you in your jurisdiction if you actually run into this or any other legal problem.
You seem to be saying that things are sufficiently uncertain that a developer releasing signed code under GPLv3 needs to get legal advice to determine whether or not they have to ship their private key.
Many thousands of small / individual FOSS developers will not have the resource for lawyers and for them, GPLv3 effectively bans code signing (but probably doesn't for big-nasty-corp-with-lots-of-lawyers).
That alone should damn this clause.
You only need a license to do something that would otherwise be illegal - like distributing the copyrighted linux kernel.
Yes...
Alan hasn't distributed any hardware that requires his signature to a kernel.
Which is completely irrelevant, because as you already said, you don't need to comply with the license to do that.
What Alan does do is distribute the software, signed (little reason to sign it if you aren't going to distribute it). So Alan is the one who might have to release his keys to comply with the license. On the other hand, someone who makes hardware doesn't need to distribute any software in order to make hardware that will run (only) the signed software, so they can't be held to anything.
If you read what Linus' has said on the subject he knows _exactly_ why he chose to move the kernel to GPL (it didn't start out that way). It has nothing to do with "freedom" and everything to do with "fairness" and "reciprocity" - which GPL also happens to do quite well.
Wrong, it can't be that way. GPL3 _adds_ restrictions (eg. the DRM stuff) over and above GPL2. GPL2 _forbids_ adding restrictions. The two are fundamentally incompatible - all the code has to be under one or the other. [ note that that doesn't preclude some code being under _either_ (eg. "GPLv2 or later"), but it does mean that you can't mix code that is _only_ GPL2 with code that is _only_ GPL3 ].
Actually English law on child porn was changed recently to 18.
Certain famous Page3 models from years gone by started at 16 or 17, so if you have an archive of the Sun newspaper you probably now have kiddie porn (yes, allegedly it is retrospective). Lock up the librarians and throw away the key.
England is also where people have famously (tv news presenter) been taken to court under kiddie porn laws for daring to take pictures of their kids in the bath.
Furthermore, the age of consent is still 16. The English teenagers who at 16 can legally have sex, get married, have kids etc., now presumably can't even possess a picture of themselves in the bath let alone their kids.
Oh, and say you're a middle aged male, then having (consensual) sex with a 16 year old girl is perfectly legal, but if she emails you a nude picture of herself you're an evil pedo child pornographer. Why is the picture of the 16yo child illegal - well, because it might lead to you wanting to have sex with the child, so it's illegal because it leads people on to "worse" things which are themselves... er... legal.
Maybe I just don't get it, but seems to me like our collective moral compass is bent so far it's disappearing up its own arse.
Actually, the word used (President) fits perfectly well in context (making it a conspiracy, rather than legal, theory).
Er, piracy is the illegal seizure of a ship by armed force, and traditionally with rape / enslavement / execution etc. of those on board. Not only is/was piracy the moral equivalent of rape of children in many penal codes, it also frequently included the same in its commission.
Your comment shows that **AA have already convinced you (amongst many) that breaching a copyright licence is equivalent to rape and pillage on the high seas.
They have done this with very deliberate PR and with the clear intention of elevating the perceived gravity of the offence. It appears to have worked. If they think they can get file-sharing associated with child porn then they undoubtedly will, and probably terrorism etc. as well.
think about it.
Who most wants to identify P2P users ?
What are the most common arguments we hear against anonymous P2P networks ?
[
A: RIAA / MPAA, and "used for child porn and terrorism"
]
The court does[...]
Two choices: author/distributor defines it, or third party / outside events.
So, I don't really agree with this view of it.
Actually we do agree - i would say the court is a third party.
Courts don't always rule the way we think is right. Results can easily depend on who has most money, for one.
Where we seem to be is that this licence says that under some circumstances you may have to hand over your signing keys, those circumstances left deliberately vague to be decided by court.
I wouldn't want to sign up to that, and nor does Linus.
If the licence said "you are not required to release private keys you have used to sign the work for verification of origin purposes" then that might be ok.
But it doesn't.
You made arguments as to why Linux (alone) ought to credit GNU by changing its name, arguments which I refuted.
Whether or not FSF ought to credit BSD is whole different and completely unrelated argument.
That's one reason Tivo would be forced to give up their secret codes while Linus would not. Very simply, Linus's private keys are not "necessary to install and/or execute the source code of the work" on my PC.
On your PC. Today. Tomorrow ? Who knows.
The point is that Linus doesn't make your PC, ergo he is not in control of whether or not his private keys are necessary. Anyone with access to his _public_ key can implement the requirement that code be signed with his _private_ key. If Linus distributed a signed kernel, TIVO could require _his_ signature, then, if you want to modify the code running on your TIVO, Linus has to give up his keys.
Whether or not he would be forced to give up his keys, under gpl v3, might then depend (as you say) on "recommended context of use". So who defines that (not the FSF, since it is specific to the code in question) ?
Two choices: author/distributor defines it, or third party / outside events.
If the author controls the definition, then TIVO controls it, and it could exclude _your_ TIVO, thus still preventing you modifying code and running it on _your_ TIVO.
If the author does _not_ control the definition, then Linus does not control it and we are back with the possibility that he _could_ be forced to release his signing keys by events outside of his control.
So basically I can't see how you can throw out DRM/TCPA without also throwing out other beneficial uses of code signing.
author != distributor. Obligations are on distributor. Distribution is as "v2 or later".
Where in "how to apply these terms..." does it suggest you can say eg. "I distribute this to you under v2, you may re-distribtute under v2 or later" ? I have never seen anyone do this - this is what you would have to do, no ?
nobody can make you do anything
Recipients can make you honour your obligations (eg. source distribution) under the licence. This has already happened.
In terms of your other "only" risk - FSF could be bought out by (say) MS. No problem, they can't rescind GPLv2 and take away our freedoms. They _could_ make the GPL v4 be BSD licence. Doesn't take away your freedom. Does put your code (potentially) into Windows, and nothing you can do about it.
My example has nothing to do with code modification.
If you distribute code as "GPLv2 or later" then "GPLv2 or later" is the license. Therefore the FSF can change the terms of your license.
They can't take the original terms away (since the v2 terms can always be used), but they can add terms that you may not like, per my example.
[...] TIVO [...]
Nor does it matter if we create a large infrastructure where Linus signs his releases and we write software that rejects unsigned releases
The fact that you _could_ use the unsigned releases elsewhere is irrelevant [or else TIVO could say that you _could_ run their source unsigned elsewhere].
The "recommended or principal context of use" would be an environment that checks for the signature (which is the whole damn point), therefore the keys would have to be disclosed.
GPLv3 attempts to prohibit its use with any sort of trusted distribution architecture. It doesn't (and probably isn't able to) make distinction between "good" or "bad" trusted distribution.
- or at least that is the way Linus seems to read it and is one reason why he says he rejects it. I have to say I agree with his reading of it.
ONLY if the original version contained a method for obtaining the source code from the server somehow, any modified version should also implement that functionality. although this didn't make it to the first draft
Thankfully.
Being able to obtain web-app source code from the server is/was a common security hole. Your wording would force any application shipping with such a hole to never fix it. It probably wasn't your intention to omit "intentional"...
And those additional options could have effects you don't want as a distributor, potentially taking away your rights.
Example:
Under GPLv2 you have the right to charge for the act of source distribution.
GPLv3 _could_ require that you distribute for free (it doesn't in this draft, but it does change the wording on that requirement).
If you've been distributing as "GPL v2 or later" at the user's discretion, then when that hypothetical GPL v3 comes out, users can require you to ship source for no payment. Hence, your right to be paid for your source distribution costs would have been taken away.
Do you think everyone in the world could have collaborated on a big project like this without a free compiler and free libraries that everyone could use?
Nope. Of course same applies to many other components eg. windowing system, server applications etc. etc.. Everything had to come together.
Happily it did, and Linux and *BSD came out of that availability, at around the same time.
Er, sorry - that's GNU/Linux and er notGNU/BSD because GNU/Linux uses the GNU compiler and toolchain and BSD uses the.... GNU compiler and toolchain. Oh. So then it must be GNU/BSD, except it's not.
Must be the userspace, after all BSD has its own userspace...
And I don't see where all the userspace stuff was going to come from if not the FSF guys... or how the kernel would have been very useful without it.
Ok, so now BSD is not GNU/BSD, despite being dependent on the GNU compiler / toolchain, because it doesn't depend on the rest of the GNU userspace. Whilst Linux is GNU/Linux because there was nowhere else for a free userspace to come from other than the FSF.
Er, nope, that clearly doesn't make sense either.
So, why is it GNU/LInux again ?
The GPLv3 will be fundamentally incompatible with any program using the Trusted Computing, because all the necessary keys can never be revealed. I assume that is the point
Exactly.
And Linus's point is that that makes it fundamentally incompatible with other forms of code signing too. The whole "Trusted Computing" thing is just a logical extension of current code-signing practice, you can't ban one without affecting the other.
Example: You want your OS's auto-update mechanism to validate updates against your vendors' private key ? I do. That's how I trust it. Your OS is GPL v3 ? - then your vendor has to publish the keys. Bye bye trust.
Problem is, signing reqirements for _running_ a work are not something that is / can be enforced by the work, but rather by the hardware / environment in which it runs.
Probably the target is device-maker-A releases hardware running a version of Linux, hardware requires the version of Linux to be signed with their key - result: user effectively cannot modify the code for their device.
But nothing says that the device maker and the code signer are the same party, which means that as a code-signer, any third party could force you to release your signing keys (by requiring code to be signed by them in order to run). Of course this releasing the keys completely breaks the purpose of code signing which is (I guess) why Linus thinks it is silly.
If the clause _doesn't_ mean this, then I struggle to see what it is there for at all. It either forces people to disclose code signing keys or it doesn't - if there are loopholes so sometimes you do, sometimes you don't, then people will use them so they don't have to release keys at all.
This is only true for own-country calls.
With international (GSM) roaming, call receiver usually pays an additional roaming charge. Not a small charge either - in fact high enough that the EU has (or is) investigated the charges.
For people living near country borders (even commuting across them - common in some parts of europe) this can be a big deal.
Gee, ever think if MSFT just got of their high horse and listened to this guy
;)
Then we'd be well and truly f**ked.
Since this guy stated that the hole was only for invalid record length of one, MS would just have blocked that. Meanwhile the existing exploits (with the source code - posted above - that you & Steve clearly didn't read / understand) would have carried on working despite the patch.
Happily, MS don't listen to him, and seem to be a bit better than him at analysing the exploits properly.
No problem. Now I guess you should get busy and patch your system... or maybe you run Linux
In which case you should still get busy and patch your system, since Linux patches for the vulnerability are available (a little later than the windows ones, but hey "win some, lose some".