"The end-user documentation included with the redistribution, if any, must include the following acknowledgment: 'This product includes software developed by the Apache Software Foundation (http://www.apache.org/).' Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear."
However with Apache, it isn't a huge problem because the requirement has existed since day one so all of the Apache-licensed software has always been incompatible with the GPL. So anyone who wanted to write software and publish it under the terms of the GPL (and cares about copyrights) simply wouldn't use any of Apache's code. Or the author would add an exception to their license, something like: "This software is licensed under the terms of the GPL, with the exception that if you link this software with Apache code, redistributions are subject to the additional restrictions found in the Apache license." This would make it legal for distributors to attach the additional restrictions to the code. (Please note, I am not a lawyer, so please ask the Apache folks if you actually intend to use such a license.)
XFree86, unlike Apache, has not always had those restrictions, and there is a huge number of GPLed works that require linking with XFree86 code. Those works (usually) don't have any exceptions to the GPL in their licensing statement, so it is illegal for distributors to ship the software with the additional restrictions that the new XFree86 license requires.
Also note that the Apache Software Foundation has weakened their requirement for acknowledgement considerably in their new version 2.0 license, and as far as I know it is now considered compatible with the GPL by the FSF except for the newly added patent-defense clause (which the next version of the GPL might also have, so the licenses would be compatible then). The XFree86 project is moving backwards with its new license.
Of course the same thing cannot be both patented and a trade secret, but the method that CSS uses to "protect" content can be patented, while the actual keys used can be trade secrets. RSA used to be patented, but the secret keys people used were secret anyway.
And quite apart from that, IBM *made* x86 processors.
Yes, but they didn't make "Intel" processors. Obviously, that is by definition something that only Intel can do. Noticed how in the court filing wherever SCO means "x86" they wrote "Intel" instead?
Still, I have looked at thousands of licenses and none use the term copyright license, [...]
I just searched Google for "copyright license" (with quotes, i.e. for that phrase) and it found about 70300 hits, although at least the first few pages don't seem to actually contain that phrase.
One thing I know for sure is that in German civil law, it doesn't matter what people call a contract, what matters is what they actually agreed on. E.g. if you provide a service but call the accompanying contract a sales contract, it's still a service contract. However as I said, I am not a lawyer, nor am I familiar with the specifics of U.S. civil law and copyright law.
The ASF has set up a mailing list to discuss their new licenses (see here), and since two proposed special case licenses are not approved yet, I assume that mailing list is still open for participation. Maybe you should raise your concerns there?
What is unusual about this license is that it grants a license to the copyright. Most licenses only grant a right contained and protected by copyright law. For example, a company may grant a license to distribute a good, or to reproduce elements of an original work of authorship.
Huh? That's just what the Apache License does:
"[...] each Contributor hereby grants to You a [...] copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work [...]."
IANAL, but I don't think that just because it says "copyright license" instead of just "license" it does something fundamentally different from all other licenses.
Also note that they had to use the term "copyright license" simply because in the next section, the license also grants a "patent license" which contains a termination clause that applies only to the patent license, but not to the copyright license. If both parts were just called "license," there would be potential ambiguity about what the termination clause applies to.
Agreed. my point was that it would have been nice of the Apache hackers to send a little note to important groups like the OSI, Debian and the FSF to announce their intend to use this license.
I don't know about OSI and FSF, but they did request feedback from the Debian project. It was mentioned in one of the Debian Weekly News.
Well, I think that depends on whether the proprietary application actually requires the user to link it to the GPLed software (this as you said clearly violates the wishes of the GPLed software's author), or if the users just do that on their own, without the application vendor even planning for that.
In the second case, the vendor of the proprietary application obviously isn't doing anything wrong, and I also don't think that the user is. The GPL allows the user to modify the GPLed software and keep those modifications private anyway (provided the modified software isn't distributed at all), and I don't think doing such private modifications suddenly become wrong or even illegal if they contain not only code written by that user himself, but also code licensed from third parties (in this case, the proprietary application).
It appears that Keith Packard is translated into "Keith luggage pool of broadcasting corporations"
LOL:-)
Just in case anyone wants to know, here's why Google (probably) translates it that way:
In German, if you combine multiple nouns to describe a single thing, they become a single word, not simply a list of nouns as in English. E.g. if you combine "core" and "team" in English you get "core team," but in German you combine "Kern" and "Gruppe" into a single word, "Kerngruppe."
"Pack" is a German word for "luggage," although it is rarely used with that meaning.
"ARD" is one of the public German television and radio organizations, and it is organized in a sort-of federal way. Google obviously seems to recognize this name, but instead of keeping it untranslated (because it is a name) seems to replace it with a description instead.
Oops, sorry, I somehow missed the "every n'th packet" in your post. Yes, that would probably make sense for some projects, if the checked packets are selected randomly.
I think they should introduce some trusted user mode, let's say, so that results from users who have invested a certain amount of cpu time should be trusted [...]
How do you know how much CPU time a user invested? That's also information submitted by the user that you cannot trust.
Unless of course the "trusted user mode" involves requiring the user to run the software on some sort of "trusted" computer, Microsoft Palladium style. In that case you might be able to save 50% computing time, but I suppose at the same time the project would lose more than 50% of its users.
What I don't like about HCI and so called usability experts is that they seem to want to lump everybody into a single catagory.
I agree with you, but your quote is probably more correct than you intended it to be:-): those people you don't like are so-called usability experts. Real usability experts won't try to "improve" an interface by assuming that all users are stupid and dumbing it down.
I don't use a computer the same way my grandmother does,...
No, of course not. You're probably a user with lots of IT knowledge, and you want to be able to make use of that knowledge. There's nothing wrong with that, but this doesn't mean that your grandma should be required to have the same knowledge.
... and a system that tries to force me to isn't intuitive for me.
Are you sure about that? To pick a different example, are you also using your phone in a fundamentally different way from how your grandma uses it? I don't think so.
Sure, maybe you use some additional features that your phone offers, but if you simply want to call someone whose number you have written on paper somewhere, I bet you will use the phone very similar to how your grandma will do in the same situation. Does this mean that a phone doesn't have a simple interface? No, of course not. It just means that the phone can be used by anyone having the required domain knowledge (i.e., knowing what a phone and a phone number are), while also allowing those people who want more feautures and understand (or are willing to learn) how to use them to do that, without those additional features getting into the way of those who just want the basic feature set.
By the way, I don't think that there's anything fundamentally wrong with Mozilla's "Edit Ciphers" dialog (except it should be called "Choose Ciphers" or something similar, since you cannot edit the actual algorithms used). In fact I didn't even know about that dialog before reading this thread, and after briefly looking at it (in Mozilla 1.5) I think it looks a bit too cluttered, but it seems to have reasonable default settings, so if you don't understand the options or don't care, you can safely ignore it. Given that the "Details" buttons all display the same attributes, the developers probably should have designed the dialog as a table with a checkbox in the first column, and the algorithm details in the other columns. Anyone who understands the dialog will also understand, and probably prefer, a tabular design instead of the more verbose and less informational pseudo-sentences.
The Mozilla user interface lets users accomplish their task without requiring them to have more technical knowledge than they have: if you just want to browse the web, you can do that. If you want to activate or deactivate specific encryption algorithms, you by definition have the required technical knowledge (otherwise you wouldn't want to do it), and Mozilla allows you to do that.
By my definition, that's not a bad user interface, though it could probably be improved a little bit.
The money that doesn't get spent gets put into some sort of financial instrument, which then is put back into the economy in the form of money that can be used as capital.
Sure, but having a supply of capital for investments makes sense only if the investments that it can be used for make sense, and the investments make sense only if at the end of the chain, there are enough people who will actually consume the produced goods.
A healthy economy needs consumers just as much as it needs investors.
I don't know C#, but you have to write something like enum Name {... } in C# as well, don't you? I don't really see how this is an advantage over having to write class Name {... } in Java.
being able to use the newly declared enumeration's new type name for parameters instead of just "int" - remember semantics?
You can do typed enumerations in Java by using the typesafe enumeration pattern.
Basically a typesafe enum is a class with a private constructor (so no new instances can be created) and all the actualy constants are declared as final class members. Like this:
public class Example {
// private constructor private Example() { }
// the constants public final static Example A = new Example(); public final static Example B = new Example(); ... }
This allows you to do really nice things. For example, you could add some instance variables and methods to the class to add additional information to the constants (of course, initialize all the variables in the constructor and don't have any set methods, or your constants won't be constant any more!).
You have to be careful if you want to use serialization or similar stuff. You might want to take a look at Martin Fowler's great book "Effective Java," which describes this pattern and a huge number of other useful things. The typesafe enum description is in chapter 5, which is available online as one of four sample chapters.
Of course, even with typesafe enums, you still have to do lots of typing (even more, actually), so your point (b) might still be an advantage of C#. I think the JDK 1.5 will add support for creating typesafe enums in a more simple way, though.
Lots of little things like this, IMHO, make C# better than Java.
As I said, I don't really know C#, but still, from what I've heard about it, that's also the impression I got. I think Microsoft took a look at all the things Java didn't quite get right, and did them in a slightly better way. If I wanted to write a Windows-only application, it's very likely that I would use C# for the task. Or Python:-)
If he says that HP has no official position, that means that he denies SCO's interpretation that HP supports SCO's position, doesn't it?
Also note that Fink said: "HP's thinking was the indemnification was better than countersuits and other possible measures." In other words, even thought about countersuing them. They wouldn't think about that as a serious possibility if they believed that SCO's claims are valid. They probably decided to indemnify their customers instead because it gives them a marketing advantage as well as hurting the credibility of SCO's claims.
MSIE has been doing this for ages, and I never found it to be a problem, but rather more helpful than the old "404 Not found" messages we used to see.
You don't get to see a "404 No Found" response if the server doesn't even exist. You'd usually get an error message (generated by IE) that says something like "www.invaliddomain.com doesn't exist." (that's what Mozilla displays, I don't know IE's message).
The 404 response is what you get when your browser could send a HTTP request to the web server, but the server couldn't find the page you were requesting. The response page is generated by the web server, so how helpful it is depends on what the web server admins have configured. Some pages will not simply return an error message but also include a search box, for example.
You type junk into an URL and you expect a civilized answer?
Well, yes, I expect a somewhat helpful error message. But that's not actually the point. The main problem with Verisign's move is that they are assuming (like you seem to do) that the purpose of the Domain Name System is to find the web server that a user is trying to contact when he types an URL into his browser. But DNS isn't used for the web only, it is used to associate names with IP addresses. You can then use the returned IP address for whatever protocol you want, DNS doesn't tell you whether or not the server with the returned IP supports that protocol.
For all protocols that run non-interactively (i.e. without a human sitting in front of the computer and interactively deciding what server should be contacted next, and interpreting the responses), Verisign's action means that if contacting a remote system fails, the computer can now no longer find out if it's due to a misconfiguration and will likely never work (if the other computer doesn't exist), or if it's just a temporary problem (if the other computer does exist but does not respond).
In the US the continuation of claims after paying the fine would eventually lead to contempt of court charges. Would this not be the case in Germany as well?
Yes, probably, but they don't continue to make those claims. The preliminary injunction is only against "The SCO Group GmbH," i.e. the German subsidiary, not against the US parent company. I've just looked at SCO Group GmbH's web site, and not found any claims about Linux, information about their Linux licensing or anything like that.
The fine that SCO has to pay now is because after the injunction against them was issued, SCO took offline their German web site, but when they put it back online their "letter to Linux users" was still published on the HTTPS version of the web site. SCO claims that the continued publication was a mistake. That was in June, more information can be found in this article (German).
The court has now decided that SCO was negligent in operating their web server, that's why they have to pay the fine.
Furthermore, you aren't even using the right status code. It's 401 Unauthorized when you want to deny access, 404 means the content is missing
Yes, but...
First, the "correct" status code would be be 403 Forbidden, 401 Unauthorized is used if "the request requires user authentication" and will cause the browser to prompt the user for login information.
And for status 403, the HTTP standard (RFC 2616) says that "If the server does not wish to make this information [explaining why the request what not fulfilled] available to the client, the status code 404 (Not Found) can be used instead." The normal use for status 404 is if the server cannot find the requested resource, but according to the RFC it is also "commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable."
So, either status code 403 or 404 are correct when trying to prevent precise ("deep") links from working. I agree that 403 is preferable.
McBride:
"Only the [GPL's] extreme claim that nothing that one has developed belongs to oneself anymore can not go carry on any more."
Yeah right. But of course when SCO's contract with Sequent claims that all code developed by Sequent is owned by SCO, that's a valid contract?
And McBride isn't even correct. The GPL doesn't take away ownership. The code you write is your code, and will stay yours, and you can license it any way you want. However if you distribute software that includes code developed by someone else, not everything is yours. I don't think that just because you add something to a work created by someone else, you can suddenly dictate the terms for publication of the new, derived work. The other developer has to agree as well, and if he choses to only agree to publishing the whole work under the GPL, you'll have to accept that.
SCO's interpretation would severely weaken copyrights, to the point where if multiple authors cooperate in creating a work, any one of them can publish the whole work on his own, without even asking the other authors if they agree to the terms of publication.
Basically SCO's view seems to be that everything that might harm their business is illegal, and everything that benefits them is legal.
Hasn't SCO said something along the lines of a license not being valid unless it's a physically signed paper document? Then maybe one of Samba's copyright holders could send a nice letter to SCO, pointing out that their recent actions on the one hand indicate that they do not wish to agree to that license, but on the other hand they want to distribute Samba, so the copyright holder could ask SCO for a signed, physical copy of the GPL simply to make sure that they do agree to it with regards to Samba.
I am not a lawyer and I have no idea if, should they refuse to sign the license, this could be interpreted as SCO not accepting the license and thus not being allowed to distribute Samba. On the other hand, if they refuse to sign the license and still distribute Samba, they'd have to claim that signing a paper document is not required. That should weaken their argument about the GPL being invalid.
Even if this didn't result in additional legal trouble for SCO, if done correctly it could at least result in some really bad PR for them. "SCO refuses to sign license agreement for software it distributes" would make a nice headline, wouldn't it?
Slashdot Mirror
Note that Apache does have a very similar requirement in the Apache License, Version 1.1:
"The end-user documentation included with the redistribution, if any, must include the following acknowledgment: 'This product includes software developed by the Apache Software Foundation (http://www.apache.org/).' Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear."
However with Apache, it isn't a huge problem because the requirement has existed since day one so all of the Apache-licensed software has always been incompatible with the GPL. So anyone who wanted to write software and publish it under the terms of the GPL (and cares about copyrights) simply wouldn't use any of Apache's code. Or the author would add an exception to their license, something like: "This software is licensed under the terms of the GPL, with the exception that if you link this software with Apache code, redistributions are subject to the additional restrictions found in the Apache license." This would make it legal for distributors to attach the additional restrictions to the code. (Please note, I am not a lawyer, so please ask the Apache folks if you actually intend to use such a license.)
XFree86, unlike Apache, has not always had those restrictions, and there is a huge number of GPLed works that require linking with XFree86 code. Those works (usually) don't have any exceptions to the GPL in their licensing statement, so it is illegal for distributors to ship the software with the additional restrictions that the new XFree86 license requires.
Also note that the Apache Software Foundation has weakened their requirement for acknowledgement considerably in their new version 2.0 license, and as far as I know it is now considered compatible with the GPL by the FSF except for the newly added patent-defense clause (which the next version of the GPL might also have, so the licenses would be compatible then). The XFree86 project is moving backwards with its new license.
Of course the same thing cannot be both patented and a trade secret, but the method that CSS uses to "protect" content can be patented, while the actual keys used can be trade secrets. RSA used to be patented, but the secret keys people used were secret anyway.
Yes, but they didn't make "Intel" processors. Obviously, that is by definition something that only Intel can do. Noticed how in the court filing wherever SCO means "x86" they wrote "Intel" instead?
Maybe they just knew from which site they would more likely get publicity?
I just searched Google for "copyright license" (with quotes, i.e. for that phrase) and it found about 70300 hits, although at least the first few pages don't seem to actually contain that phrase.
One thing I know for sure is that in German civil law, it doesn't matter what people call a contract, what matters is what they actually agreed on. E.g. if you provide a service but call the accompanying contract a sales contract, it's still a service contract. However as I said, I am not a lawyer, nor am I familiar with the specifics of U.S. civil law and copyright law.
The ASF has set up a mailing list to discuss their new licenses (see here), and since two proposed special case licenses are not approved yet, I assume that mailing list is still open for participation. Maybe you should raise your concerns there?
Huh? That's just what the Apache License does:
"[...] each Contributor hereby grants to You a [...] copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work [...]."
IANAL, but I don't think that just because it says "copyright license" instead of just "license" it does something fundamentally different from all other licenses.
Also note that they had to use the term "copyright license" simply because in the next section, the license also grants a "patent license" which contains a termination clause that applies only to the patent license, but not to the copyright license. If both parts were just called "license," there would be potential ambiguity about what the termination clause applies to.
I don't know about OSI and FSF, but they did request feedback from the Debian project. It was mentioned in one of the Debian Weekly News.
I did. X.org was listed on the fourth and XFree86 on the sixth position. Not that bad.
Well, I think that depends on whether the proprietary application actually requires the user to link it to the GPLed software (this as you said clearly violates the wishes of the GPLed software's author), or if the users just do that on their own, without the application vendor even planning for that.
In the second case, the vendor of the proprietary application obviously isn't doing anything wrong, and I also don't think that the user is. The GPL allows the user to modify the GPLed software and keep those modifications private anyway (provided the modified software isn't distributed at all), and I don't think doing such private modifications suddenly become wrong or even illegal if they contain not only code written by that user himself, but also code licensed from third parties (in this case, the proprietary application).
"People new to Linux" probably won't download a kernel anyway.
Hope this helps.
By the same reasoning, unless the FBI is doing something illegal, what do they have to hide from judicial oversight?
LOL :-)
Just in case anyone wants to know, here's why Google (probably) translates it that way:
Oops, sorry, I somehow missed the "every n'th packet" in your post. Yes, that would probably make sense for some projects, if the checked packets are selected randomly.
How do you know how much CPU time a user invested? That's also information submitted by the user that you cannot trust.
Unless of course the "trusted user mode" involves requiring the user to run the software on some sort of "trusted" computer, Microsoft Palladium style. In that case you might be able to save 50% computing time, but I suppose at the same time the project would lose more than 50% of its users.
I agree with you, but your quote is probably more correct than you intended it to be :-): those people you don't like are so-called usability experts. Real usability experts won't try to "improve" an interface by assuming that all users are stupid and dumbing it down.
No, of course not. You're probably a user with lots of IT knowledge, and you want to be able to make use of that knowledge. There's nothing wrong with that, but this doesn't mean that your grandma should be required to have the same knowledge.
Are you sure about that? To pick a different example, are you also using your phone in a fundamentally different way from how your grandma uses it? I don't think so.
Sure, maybe you use some additional features that your phone offers, but if you simply want to call someone whose number you have written on paper somewhere, I bet you will use the phone very similar to how your grandma will do in the same situation. Does this mean that a phone doesn't have a simple interface? No, of course not. It just means that the phone can be used by anyone having the required domain knowledge (i.e., knowing what a phone and a phone number are), while also allowing those people who want more feautures and understand (or are willing to learn) how to use them to do that, without those additional features getting into the way of those who just want the basic feature set.
By the way, I don't think that there's anything fundamentally wrong with Mozilla's "Edit Ciphers" dialog (except it should be called "Choose Ciphers" or something similar, since you cannot edit the actual algorithms used). In fact I didn't even know about that dialog before reading this thread, and after briefly looking at it (in Mozilla 1.5) I think it looks a bit too cluttered, but it seems to have reasonable default settings, so if you don't understand the options or don't care, you can safely ignore it. Given that the "Details" buttons all display the same attributes, the developers probably should have designed the dialog as a table with a checkbox in the first column, and the algorithm details in the other columns. Anyone who understands the dialog will also understand, and probably prefer, a tabular design instead of the more verbose and less informational pseudo-sentences.
The Mozilla user interface lets users accomplish their task without requiring them to have more technical knowledge than they have: if you just want to browse the web, you can do that. If you want to activate or deactivate specific encryption algorithms, you by definition have the required technical knowledge (otherwise you wouldn't want to do it), and Mozilla allows you to do that.
By my definition, that's not a bad user interface, though it could probably be improved a little bit.
Sure, but having a supply of capital for investments makes sense only if the investments that it can be used for make sense, and the investments make sense only if at the end of the chain, there are enough people who will actually consume the produced goods.
A healthy economy needs consumers just as much as it needs investors.
I don't know C#, but you have to write something like enum Name { ... } in C# as well, don't you? I don't really see how this is an advantage over having to write class Name { ... } in Java.
You can do typed enumerations in Java by using the typesafe enumeration pattern.
Basically a typesafe enum is a class with a private constructor (so no new instances can be created) and all the actualy constants are declared as final class members. Like this:
This allows you to do really nice things. For example, you could add some instance variables and methods to the class to add additional information to the constants (of course, initialize all the variables in the constructor and don't have any set methods, or your constants won't be constant any more!).
You have to be careful if you want to use serialization or similar stuff. You might want to take a look at Martin Fowler's great book "Effective Java," which describes this pattern and a huge number of other useful things. The typesafe enum description is in chapter 5, which is available online as one of four sample chapters.
Of course, even with typesafe enums, you still have to do lots of typing (even more, actually), so your point (b) might still be an advantage of C#. I think the JDK 1.5 will add support for creating typesafe enums in a more simple way, though.
As I said, I don't really know C#, but still, from what I've heard about it, that's also the impression I got. I think Microsoft took a look at all the things Java didn't quite get right, and did them in a slightly better way. If I wanted to write a Windows-only application, it's very likely that I would use C# for the task. Or Python :-)
If he says that HP has no official position, that means that he denies SCO's interpretation that HP supports SCO's position, doesn't it?
Also note that Fink said: "HP's thinking was the indemnification was better than countersuits and other possible measures." In other words, even thought about countersuing them. They wouldn't think about that as a serious possibility if they believed that SCO's claims are valid. They probably decided to indemnify their customers instead because it gives them a marketing advantage as well as hurting the credibility of SCO's claims.
You don't get to see a "404 No Found" response if the server doesn't even exist. You'd usually get an error message (generated by IE) that says something like "www.invaliddomain.com doesn't exist." (that's what Mozilla displays, I don't know IE's message).
The 404 response is what you get when your browser could send a HTTP request to the web server, but the server couldn't find the page you were requesting. The response page is generated by the web server, so how helpful it is depends on what the web server admins have configured. Some pages will not simply return an error message but also include a search box, for example.
Well, yes, I expect a somewhat helpful error message. But that's not actually the point. The main problem with Verisign's move is that they are assuming (like you seem to do) that the purpose of the Domain Name System is to find the web server that a user is trying to contact when he types an URL into his browser. But DNS isn't used for the web only, it is used to associate names with IP addresses. You can then use the returned IP address for whatever protocol you want, DNS doesn't tell you whether or not the server with the returned IP supports that protocol.
For all protocols that run non-interactively (i.e. without a human sitting in front of the computer and interactively deciding what server should be contacted next, and interpreting the responses), Verisign's action means that if contacting a remote system fails, the computer can now no longer find out if it's due to a misconfiguration and will likely never work (if the other computer doesn't exist), or if it's just a temporary problem (if the other computer does exist but does not respond).
Yes, probably, but they don't continue to make those claims. The preliminary injunction is only against "The SCO Group GmbH," i.e. the German subsidiary, not against the US parent company. I've just looked at SCO Group GmbH's web site, and not found any claims about Linux, information about their Linux licensing or anything like that.
The fine that SCO has to pay now is because after the injunction against them was issued, SCO took offline their German web site, but when they put it back online their "letter to Linux users" was still published on the HTTPS version of the web site. SCO claims that the continued publication was a mistake. That was in June, more information can be found in this article (German).
The court has now decided that SCO was negligent in operating their web server, that's why they have to pay the fine.
Yes, but...
First, the "correct" status code would be be 403 Forbidden, 401 Unauthorized is used if "the request requires user authentication" and will cause the browser to prompt the user for login information.
And for status 403, the HTTP standard (RFC 2616) says that "If the server does not wish to make this information [explaining why the request what not fulfilled] available to the client, the status code 404 (Not Found) can be used instead." The normal use for status 404 is if the server cannot find the requested resource, but according to the RFC it is also "commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable."
So, either status code 403 or 404 are correct when trying to prevent precise ("deep") links from working. I agree that 403 is preferable.
But as far as I know none of the countries has its own space program, they cooperate in the European Space Agency.
Yeah right. But of course when SCO's contract with Sequent claims that all code developed by Sequent is owned by SCO, that's a valid contract?
And McBride isn't even correct. The GPL doesn't take away ownership. The code you write is your code, and will stay yours, and you can license it any way you want. However if you distribute software that includes code developed by someone else, not everything is yours. I don't think that just because you add something to a work created by someone else, you can suddenly dictate the terms for publication of the new, derived work. The other developer has to agree as well, and if he choses to only agree to publishing the whole work under the GPL, you'll have to accept that.
SCO's interpretation would severely weaken copyrights, to the point where if multiple authors cooperate in creating a work, any one of them can publish the whole work on his own, without even asking the other authors if they agree to the terms of publication.
Basically SCO's view seems to be that everything that might harm their business is illegal, and everything that benefits them is legal.
Hasn't SCO said something along the lines of a license not being valid unless it's a physically signed paper document? Then maybe one of Samba's copyright holders could send a nice letter to SCO, pointing out that their recent actions on the one hand indicate that they do not wish to agree to that license, but on the other hand they want to distribute Samba, so the copyright holder could ask SCO for a signed, physical copy of the GPL simply to make sure that they do agree to it with regards to Samba.
I am not a lawyer and I have no idea if, should they refuse to sign the license, this could be interpreted as SCO not accepting the license and thus not being allowed to distribute Samba. On the other hand, if they refuse to sign the license and still distribute Samba, they'd have to claim that signing a paper document is not required. That should weaken their argument about the GPL being invalid.
Even if this didn't result in additional legal trouble for SCO, if done correctly it could at least result in some really bad PR for them. "SCO refuses to sign license agreement for software it distributes" would make a nice headline, wouldn't it?