Unfortunately, we do not yet know the particular details of the contract, which will be the crux of the eventual ruling, but SCO is hinting that the contract explicitly states that all derivative work reverts to SCO in some fashion. If the contract really does grant SCO exclusive control over derivative work, then IBM might be found guilty.
You might wish to go to the SCO web site and read the contracts. Or at least, those contracts that SCO included as exhibits in their lawsuit.
The contracts discuss derivative works, but they never define what they mean. They basically say that IBM owns the derivative work, but they must hold it confidential.
In their lawsuit, SCO is using a very agressive definition for "derivative work". By their definition, any code you include with System V to create a derivative work is itself a derivative work even when there is no System V code in there.
At least one part of the lawsuit seem to be entirely contradicted by the contracts. The contract spells out that IBM can use what they learn from System V code as long as they do not copy the code directly to the other work and as long as they do not directly reference certain confidential documentation to do the work.
As far as the definition of "derivative work" goes, I would expect that a judge would expect to see a non-standard definition of the phrase to be explicitly spelled out in the contract. Since there is no explicitly spelled out definition of "derivative work" in the conrtract as far as I can determine, it only seems logical that a more canonical definition would be used.
So, on that matter, I think IBM should be in the clear.
Anyway, the contracts, at least some of them, are publically available from www.sco.com as well as SCO's original complaint, the amended complaint, the exhibits, and IBM's answers to the original complaint.
Re:Excellent article.
on
My Visit to SCO
·
· Score: 4, Interesting
There is more to Technologies developed by other companies as add-ons to SysV were incorporated into Linux. This is not copyright infringement at all, but violates contracts signed by the original parties. than just that.
To be specific, SCO is claiming that the addons are a "derivative work" of System V.
Consider the definition of "derivative work" found in Title 17 of the U.S. code:
A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''.
From this definition it appears that for something to be a "derivative work" it would need to be substantially the same overall work as the original work.
In other words, a "derivative work" of an operating system would itself be an operating system or something functioning largely as an operating system. Or it could be code copied from the original operating system into another operating system.
The original work is still there in some form as a part of the derivative work.
In this case, the RCU code developed by Sequent, the JFS code regardless of whether it is the original AIX version or the original OS/2 version, and any other code developed directly by IBM, Sequent, or other sources apart from AT&T/Novell/SCO are not by themselves derivative works because they do not embody anything close to the original work.
They are not a recasting, a transformation, or an adaptation of the original work.
They are not derived from the original work.
They do not embody the original work.
They do not contain the original work or elements of the original work.
They are not revisions of the original work.
They are the modifications that can be applied to the original work to produce a derivative work.
SCO's definition of "derivative work" does not match up at all with any notion I hold about what is and what is not a derivative work.
The problem with any postage is that it can be forged. If you have some sort of public/private key, though, then only the people you give your key to would be able to email you... Now that I've started thinking, that might be a really good way to allow authorized email.
I've considered only accepting e-mail that is either encrypted with my PGP key or that is digitally signed with a PGP/GPG key who's public key is found on a local key server or with a certificate from an acceptable certificate authority.
While our Internet connection was down for a few hours one day because someone cut the cable, my oldest brother sent me an e-mail that was returned as undeliverable a very short time later.
It turned out that his provider only tried to deliver it two times (IIRC) a few minutes apart and then bounced it as undeliverable!
So SCO says IBM can't distribute code that IBM owns because it was first used on derivative workds of System V.
As someone pointed out yesterday, the letter of understanding that is Exhibit C in SCO's complaint explicitly agrees that IBM owns their derivative works. They may just not be allowed to distribute them.
Assume for the moment that the modifications themselves are derivative works. (I don't think this is likely from the definition of derivative work from Title 17 of the U.S. Code.)
But even if is a derivative work, IBM still owns that code. The code is not stolen or misappropriated, merely released in a manner that might possibly be a contract violation. While SCO might possibly be able to demand that everyone stop using it or maybe remove it from future versions, it doesn't necessarily follow that everyone would owe SCO any damages or licensing payments at all.
Noone is in possession of stolen property or SCO's intellectual property.
The whole matter then becomes nothing more than a contract dispute over whether or not IBM has the right to distribute code they own.
I think that the whole matter then boils down to whether or not the modifications themselves are considered a derivative work.
If the judge and jury agrees with SCO that the modifications are a derivative work of System V when there is no System V code in it, then IBM might owe something in the way of damages. It might be possible that they could just be ordered to retrieve the code (unrelease it) and owe no damages at all.
But it's hard to see how anyone who does not have a contract with SCO would owe them anything at all on this matter.
One thing to keep in mind is that the code SCO claims is infringing on their rights did not already exist in SCO's copies of System V and their own derived code.
What SCO is claiming is that their rights include the modifications made by companies licensing the AT&T System V code.
Their contracts specify that any derived works created by the licensees is also covered by the license.
But their use of the phrase "derived works" does not seem at all reasonable or acceptable.
The question is what does the phrase mean? If you look at Title 17 of the U.S. Code (available from wwww.law.cornell.edu), you find the following definition:
A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''.
In other words, when you modify SCO's licensed code, the result is a derivative work and is consequently covered by the license.
However, they are claiming that the modifications themselves are also derivative works, apart from the object being modified.
But if you look at the definition, the derivative work is a transformation, adaptation, revision,..., of the original work.
The code in question is largely or maybe entirely code that was done by others apart from AT&T/Novell/SCO and added to their licensed copy of the code to create something better. The code that you get when you add the additional code to the original code is clearly a derivative work and SCO clearly has interests in keeping you from distributing the resulting derivative work.
But SCO seems to be claiming that the code added to System V to create a derivative work of System V is itself a derivative work.
The only other possibility I can imagine is that they are claiming that you can't copy code directly from the derivative work into another product because of the licenses. (See Exhibit C of their lawsuit.)
But I haven't seen any evidence that IBM has done that. If someone at IBM excerpted the additions to the code so that none of the System V code was present and those excerpts were added to the Linux code, I don't think think there would be any violations at all.
If someone at IBM did copy the additions directly from the derived work and was careful to avoid copying any System V code over, I suppose that would be a technical violation of the contract. I think a technical violation of that sort would be so minor that they wouldn't warrant anything more than a letter from SCO to IBM demanding that they be more careful.
And there are no allegations that I've heard that IBM did a copy and paste of their own additions directly from the SCO code to their own code.
It would be nice to find out what some knowledgeable lawyers thought about the issue of whether or not adding Sequent or IBM's own code to System V makes their own code a "derived work" of System V. It could be that the legal system sees it some other way.
One other point. If SCO is interpreting the phrase "derived work" in an unobvious way, then the phrase should probably have been clarified in the agreement instead of leaving it ambiguous. In law, isn't an ambiguity in a contract generally interpreted against the side who wrote the contract? Since the basic contract was probably written by AT&T and then hammered out between both sides, I think that any ambiguity would likely be decided in IBM's favor.
They didn't in the original complaint, but they filed an amended complaint yesterday that does allege copyright infringement, but they are still mainly talking about contracts.
From Paragraph 139 of the amended complaint:
IBM has even gone so far as to publish the DYNIX/ptx copyright as part of the source code and documentation contribution of UNIX-derived RCU technology it has improperly made available to the open source community.
Paragraph 135 of the complaint is rather interesting:
135.ÂÂÂÂÂÂÂÂÂ With respect to the scope of rights granted for use of the System V source code under Section 2.01 of the Software Agreement, Sequent received the following:
[A] personal, nontransferable and nonexclusive right to use in the United States each Software Product identified in the one or more Supplements hereto, solely for Licenseeâ(TM)s own internal business purposes and solely on or in conjunction with Designated CPUs for such Software Product. Such right to use includes the right to modify such Software Product and to prepare derivative works based on such Software product, provided the resulting materials are treated hereunder as part of the original Software Product. [Emphasis added.]
In other words, Sequent appears to have agreed that the derivative work is to be treated as if it was part of the original SCO code.
But it seems to me that they are arguing about the entire product, as amended. I don't see from the quote that the modifications themselves belong to SCO. Only that the resulting work composed of Sequent's modifications AND of the original code are to be treated as confidential.
I'd readily grant that Sequent's modifications of SCO code does not convert the entire resulting product to something that can be freely distributed.
But I don't see that it result in SCO's ownership of the modifications themselves. They do have a legitimate interest in keeping their code private even when the modifications are added. But where does it say that the modifications themselves must be kept confidential when not included as part of the source code itself?
Maybe there is some legalese version of the word treated that really means that any and all modifications belong to SCO.
Replacing infringement code would help to limit future damages, but it wouldn't do anything for past damages.
The real result of revealing the code is that it would be put under a microscope to determine every detail of the lineage of that code and how it got into Linux.
In particular, for every piece of alleged infringing code, it would be determined who wrote it (IBM, SCO/Caldera, AT&T, other provider, an independent contributor,...), where it first appeared (System V, Linux, BSD, a pre-System V Unix that has been publically released), and how it got there.
SCO don't want to discuss where the code came from and they appear to be stating that it just doesn't matter (see the byte.com story) -- that it infringes on their rights even if it was done by someone else.
I don't think SCO wants to subject the code to the intense scrutiny that could show that the code is completely in the clear.
You are correct that the Open Group will still own the trademark.
IBM's position is that they have not breached the contract and that the contract is still in effect.
Of course, IBM could end up countersuing SCO for damages caused by SCO's unfounded claims and SCO could give them the code to settle out of court on the countersuit.
IBM will not have gained that right by winning the lawsuit unless either SCO or their successor explicitly grants IBM that right or makes the code publically available for some unknown reason.
Neither possibility is at all reasonable or probable.
From Exhibit C, the only major restrictions were that IBM couldn't copy the code from one to the other and they couldn't refer to the AT&T proprietary documents while developing the other code.
On the other hand, Exhibit C does say that there is nothing in their agreement that bars IBM from developing other products using "ideas, concepts, know-how of techniques related to data processing embodied in SOFTWARE PRODUCTS subject to this Agreement." Therefore, the agreement clearly does not say that IBM cannot use what they learn from the licensed code to develop their own.
Try going to news.google.com, enter SCO in the search box, click on "sort by date", and go to the second page of search results. The article is titled "Gettin' my mojo back".
From http://www.infoworld.com/article/03/06/16/24OPcrin gely_1.html:
Without even knowing it, SCO may have started a war of attrition with much larger enemies that have deeper pockets. Within the halls at AT&T, folks were chattering just last week that AT&T still has reserved rights on Unix. Naturally, the company is paying close attention to the various legal claims that SCO is making and may join the battle soon. My spy said the word around AT&T is that this will all be resolved shortly. But one has to wonder how long SCO could survive if it had opponents in multiple courtrooms â" those being, of course, IBM and AT&T.
You won't be able to just grab one at random. You may be able to do that for the low order bits, but the proper higher order bits will be necessary for routing.
From Peterson, LL and Davie BS, Computer Networks A Systems Approach, Second Edition, Morgan Kaufmann Publishers:
IPv6 addresses do not have classes, but the address space is still subdivided in various ways based on the leading bits. Rather than specifying different address classes, the leading bits specify different uses of the IPv6 address....
First, the entire functionality of IPv4's three main address classes (A, B, and C) is contained inside the 001 prefix. Aggregate Global Unicast Addresses, as we shall see shortly, are a lot like classless IPv4 addresses, only much longer....
Again, the key idea is to use an address prefix -- a set of contiguous bits at the most significant end of the address -- to aggregate reachability information to a large number of networks and even to a large number of ASs. The main way to achieve this is to assign an address prefix to a direct provider and than for that direct provider to assign longer prefixes that begin with that prefix to its subscribers.... Thus, a provider can advertise a single prefix for all of its subscribers....
there is ongoing research on other addressing schemes, such as geographic addressing, in which a site's address is a function of its location rather than the provider to which it attaches. At present, however, provider-based addressing is necessary to make routing work efficiently....
One place where aggregation may make sense is at the national or continental level. Continental boundaries form natural divisions in the Internet topology, and if all addresses in Europe, for example, had a common prefix, then a great deal of aggregation could be done, so that most routers in other continents would only need one routing table entry for all networks with the Europe prefix.
Just think how many IP addresses a port scanner would have to try just to locate a single computer, much less finding one with a particular vulnerability.
I've been wondering whether there is any liability against SCO in the U.S. for making the claims they have been making if they do not prove to be true.
Couldn't they be held liable for malicious interference with every Linux distributor in the country?
I bet they are monitoring the downloads for IP addresses. Then they serve the service providers with subpoenas for the identity of whoever is using that address. Then they sue everyone.
Has SCO joined the RIAA? If so, then maybe their on-line distribtions have been poisoned.
Seriously, the latest news is that they are getting ready to file suit against a major hardware firm for contract violations. And they are claiming that EVERY version of Linux contains their code.
See http://www.businessweek.com/technology/cnet/storie s/1017267.htm
I think that it has more to do with SCO claims against Linux than against IBM since the claims against IBM are on contract issues, not copyright issues.
Considering the IBM culture and the way that IBM reportedly required their Linux developers to meet with lawyers to discuss the legal issues involved before doing any Linux work at all, the claim that IBM misappropriated their code strains my credulity far past the breaking point. To me, that seems to be about the least likely scenario of all possible scenarios.
Anyway, in the lawsuit you referenced, the judge's dismissed the lawsuit because the plaintiff, Gene Jacobsen, waited for three books to be published before raising issues of copyright infringement when he had every opportunity to object at the first book.
SCO had every opportunity to objecting to the alleged infringement a long time ago. Instead of objecting to the alleged infringement, they let it continue.
Gene Jacobsen says he didn't even read the first book until later and so he couldn't have complained about the infringement. SCO claims they hadn't compared the code until now and so they couldn't have complained. The parallels between the two cases are really strong.
SCO really should have done their due dilligence in a timely manner. They had every reason to do so and every opportunity to do just that. That they didn't is their fault and not that of the Linux community.
The fact that they waited until now to make the claims strikes me as being very suspicious.
And that's assuming that there really is an infringement, which I doubt.
It seems to me that SCO is attempting to maximize damages. I don't know if it applies to copyright law, but in many points of law, my understanding is that it is up to the injured party to try to mitigate damages. If they don't, the damages are frequently set to what they should have been had they mitigated damages.
For example, if someone throws a baseball through your window, you can't sue them a year later and collect for all the rain damage that has occurred since then because you refused to break the window.
And there is the question of when SCO learned of the alleged infringement. They have been quoted as saying that there wasn't anyone to sue before now. It sounds to me like they failed to mitigate damages while waiting for there to be someone big enough to sue.
You might wish to go to the SCO web site and read the contracts. Or at least, those contracts that SCO included as exhibits in their lawsuit.
The contracts discuss derivative works, but they never define what they mean. They basically say that IBM owns the derivative work, but they must hold it confidential.
In their lawsuit, SCO is using a very agressive definition for "derivative work". By their definition, any code you include with System V to create a derivative work is itself a derivative work even when there is no System V code in there.
At least one part of the lawsuit seem to be entirely contradicted by the contracts. The contract spells out that IBM can use what they learn from System V code as long as they do not copy the code directly to the other work and as long as they do not directly reference certain confidential documentation to do the work.
As far as the definition of "derivative work" goes, I would expect that a judge would expect to see a non-standard definition of the phrase to be explicitly spelled out in the contract. Since there is no explicitly spelled out definition of "derivative work" in the conrtract as far as I can determine, it only seems logical that a more canonical definition would be used.
So, on that matter, I think IBM should be in the clear.
Anyway, the contracts, at least some of them, are publically available from www.sco.com as well as SCO's original complaint, the amended complaint, the exhibits, and IBM's answers to the original complaint.
There is more to Technologies developed by other companies as add-ons to SysV were incorporated into Linux. This is not copyright infringement at all, but violates contracts signed by the original parties. than just that.
To be specific, SCO is claiming that the addons are a "derivative work" of System V.
Consider the definition of "derivative work" found in Title 17 of the U.S. code:
A ''derivative work'' is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represent an original work of authorship, is a ''derivative work''.
From this definition it appears that for something to be a "derivative work" it would need to be substantially the same overall work as the original work.
In other words, a "derivative work" of an operating system would itself be an operating system or something functioning largely as an operating system. Or it could be code copied from the original operating system into another operating system.
The original work is still there in some form as a part of the derivative work.
In this case, the RCU code developed by Sequent, the JFS code regardless of whether it is the original AIX version or the original OS/2 version, and any other code developed directly by IBM, Sequent, or other sources apart from AT&T/Novell/SCO are not by themselves derivative works because they do not embody anything close to the original work.
They are not a recasting, a transformation, or an adaptation of the original work.
They are not derived from the original work.
They do not embody the original work.
They do not contain the original work or elements of the original work.
They are not revisions of the original work.
They are the modifications that can be applied to the original work to produce a derivative work.
SCO's definition of "derivative work" does not match up at all with any notion I hold about what is and what is not a derivative work.
The problem with any postage is that it can be forged. If you have some sort of public/private key, though, then only the people you give your key to would be able to email you... Now that I've started thinking, that might be a really good way to allow authorized email.
I've considered only accepting e-mail that is either encrypted with my PGP key or that is digitally signed with a PGP/GPG key who's public key is found on a local key server or with a certificate from an acceptable certificate authority.
While our Internet connection was down for a few hours one day because someone cut the cable, my oldest brother sent me an e-mail that was returned as undeliverable a very short time later.
It turned out that his provider only tried to deliver it two times (IIRC) a few minutes apart and then bounced it as undeliverable!
So SCO says IBM can't distribute code that IBM owns because it was first used on derivative workds of System V.
As someone pointed out yesterday, the letter of understanding that is Exhibit C in SCO's complaint explicitly agrees that IBM owns their derivative works. They may just not be allowed to distribute them.
Assume for the moment that the modifications themselves are derivative works. (I don't think this is likely from the definition of derivative work from Title 17 of the U.S. Code.)
But even if is a derivative work, IBM still owns that code. The code is not stolen or misappropriated, merely released in a manner that might possibly be a contract violation. While SCO might possibly be able to demand that everyone stop using it or maybe remove it from future versions, it doesn't necessarily follow that everyone would owe SCO any damages or licensing payments at all.
Noone is in possession of stolen property or SCO's intellectual property.
The whole matter then becomes nothing more than a contract dispute over whether or not IBM has the right to distribute code they own.
I think that the whole matter then boils down to whether or not the modifications themselves are considered a derivative work.
If the judge and jury agrees with SCO that the modifications are a derivative work of System V when there is no System V code in it, then IBM might owe something in the way of damages. It might be possible that they could just be ordered to retrieve the code (unrelease it) and owe no damages at all.
But it's hard to see how anyone who does not have a contract with SCO would owe them anything at all on this matter.
One thing to keep in mind is that the code SCO claims is infringing on their rights did not already exist in SCO's copies of System V and their own derived code.
What SCO is claiming is that their rights include the modifications made by companies licensing the AT&T System V code.
Their contracts specify that any derived works created by the licensees is also covered by the license.
But their use of the phrase "derived works" does not seem at all reasonable or acceptable.
The question is what does the phrase mean? If you look at Title 17 of the U.S. Code (available from wwww.law.cornell.edu), you find the following definition:
In other words, when you modify SCO's licensed code, the result is a derivative work and is consequently covered by the license.
However, they are claiming that the modifications themselves are also derivative works, apart from the object being modified.
But if you look at the definition, the derivative work is a transformation, adaptation, revision, ..., of the original work.
The code in question is largely or maybe entirely code that was done by others apart from AT&T/Novell/SCO and added to their licensed copy of the code to create something better. The code that you get when you add the additional code to the original code is clearly a derivative work and SCO clearly has interests in keeping you from distributing the resulting derivative work.
But SCO seems to be claiming that the code added to System V to create a derivative work of System V is itself a derivative work.
The only other possibility I can imagine is that they are claiming that you can't copy code directly from the derivative work into another product because of the licenses. (See Exhibit C of their lawsuit.)
But I haven't seen any evidence that IBM has done that. If someone at IBM excerpted the additions to the code so that none of the System V code was present and those excerpts were added to the Linux code, I don't think think there would be any violations at all.
If someone at IBM did copy the additions directly from the derived work and was careful to avoid copying any System V code over, I suppose that would be a technical violation of the contract. I think a technical violation of that sort would be so minor that they wouldn't warrant anything more than a letter from SCO to IBM demanding that they be more careful.
And there are no allegations that I've heard that IBM did a copy and paste of their own additions directly from the SCO code to their own code.
It would be nice to find out what some knowledgeable lawyers thought about the issue of whether or not adding Sequent or IBM's own code to System V makes their own code a "derived work" of System V. It could be that the legal system sees it some other way.
One other point. If SCO is interpreting the phrase "derived work" in an unobvious way, then the phrase should probably have been clarified in the agreement instead of leaving it ambiguous. In law, isn't an ambiguity in a contract generally interpreted against the side who wrote the contract? Since the basic contract was probably written by AT&T and then hammered out between both sides, I think that any ambiguity would likely be decided in IBM's favor.
SCO is now claiming copyright infringement.
They didn't in the original complaint, but they filed an amended complaint yesterday that does allege copyright infringement, but they are still mainly talking about contracts.
From Paragraph 139 of the amended complaint:
Paragraph 135 of the complaint is rather interesting:
In other words, Sequent appears to have agreed that the derivative work is to be treated as if it was part of the original SCO code.
But it seems to me that they are arguing about the entire product, as amended. I don't see from the quote that the modifications themselves belong to SCO. Only that the resulting work composed of Sequent's modifications AND of the original code are to be treated as confidential.
I'd readily grant that Sequent's modifications of SCO code does not convert the entire resulting product to something that can be freely distributed.
But I don't see that it result in SCO's ownership of the modifications themselves. They do have a legitimate interest in keeping their code private even when the modifications are added. But where does it say that the modifications themselves must be kept confidential when not included as part of the source code itself?
Maybe there is some legalese version of the word treated that really means that any and all modifications belong to SCO.
Replacing infringement code would help to limit future damages, but it wouldn't do anything for past damages.
...), where it first appeared (System V, Linux, BSD, a pre-System V Unix that has been publically released), and how it got there.
The real result of revealing the code is that it would be put under a microscope to determine every detail of the lineage of that code and how it got into Linux.
In particular, for every piece of alleged infringing code, it would be determined who wrote it (IBM, SCO/Caldera, AT&T, other provider, an independent contributor,
SCO don't want to discuss where the code came from and they appear to be stating that it just doesn't matter (see the byte.com story) -- that it infringes on their rights even if it was done by someone else.
I don't think SCO wants to subject the code to the intense scrutiny that could show that the code is completely in the clear.
You are correct that the Open Group will still own the trademark.
IBM's position is that they have not breached the contract and that the contract is still in effect.
Of course, IBM could end up countersuing SCO for damages caused by SCO's unfounded claims and SCO could give them the code to settle out of court on the countersuit.
IBM will not have gained that right by winning the lawsuit unless either SCO or their successor explicitly grants IBM that right or makes the code publically available for some unknown reason.
Neither possibility is at all reasonable or probable.
From Exhibit C, the only major restrictions were that IBM couldn't copy the code from one to the other and they couldn't refer to the AT&T proprietary documents while developing the other code.
On the other hand, Exhibit C does say that there is nothing in their agreement that bars IBM from developing other products using "ideas, concepts, know-how of techniques related to data processing embodied in SOFTWARE PRODUCTS subject to this Agreement." Therefore, the agreement clearly does not say that IBM cannot use what they learn from the licensed code to develop their own.
That's a weird link.
Try going to news.google.com, enter SCO in the search box, click on "sort by date", and go to the second page of search results. The article is titled "Gettin' my mojo back".
From http://www.infoworld.com/article/03/06/16/24OPcrin gely_1.html:
I wonder what rights AT&T retained.
You won't be able to just grab one at random. You may be able to do that for the low order bits, but the proper higher order bits will be necessary for routing.
...
...
... Thus, a provider can advertise a single prefix for all of its subscribers. ...
...
From Peterson, LL and Davie BS, Computer Networks A Systems Approach, Second Edition, Morgan Kaufmann Publishers:
IPv6 addresses do not have classes, but the address space is still subdivided in various ways based on the leading bits. Rather than specifying different address classes, the leading bits specify different uses of the IPv6 address.
First, the entire functionality of IPv4's three main address classes (A, B, and C) is contained inside the 001 prefix. Aggregate Global Unicast Addresses, as we shall see shortly, are a lot like classless IPv4 addresses, only much longer.
Again, the key idea is to use an address prefix -- a set of contiguous bits at the most significant end of the address -- to aggregate reachability information to a large number of networks and even to a large number of ASs. The main way to achieve this is to assign an address prefix to a direct provider and than for that direct provider to assign longer prefixes that begin with that prefix to its subscribers.
there is ongoing research on other addressing schemes, such as geographic addressing, in which a site's address is a function of its location rather than the provider to which it attaches. At present, however, provider-based addressing is necessary to make routing work efficiently.
One place where aggregation may make sense is at the national or continental level. Continental boundaries form natural divisions in the Internet topology, and if all addresses in Europe, for example, had a common prefix, then a great deal of aggregation could be done, so that most routers in other continents would only need one routing table entry for all networks with the Europe prefix.
Just think how many IP addresses a port scanner would have to try just to locate a single computer, much less finding one with a particular vulnerability.
I've been wondering whether there is any liability against SCO in the U.S. for making the claims they have been making if they do not prove to be true.
Couldn't they be held liable for malicious interference with every Linux distributor in the country?
I bet they are monitoring the downloads for IP addresses. Then they serve the service providers with subpoenas for the identity of whoever is using that address. Then they sue everyone. Has SCO joined the RIAA? If so, then maybe their on-line distribtions have been poisoned. Seriously, the latest news is that they are getting ready to file suit against a major hardware firm for contract violations. And they are claiming that EVERY version of Linux contains their code. See http://www.businessweek.com/technology/cnet/storie s/1017267.htm
That's very interesting.
I think that it has more to do with SCO claims against Linux than against IBM since the claims against IBM are on contract issues, not copyright issues.
Considering the IBM culture and the way that IBM reportedly required their Linux developers to meet with lawyers to discuss the legal issues involved before doing any Linux work at all, the claim that IBM misappropriated their code strains my credulity far past the breaking point. To me, that seems to be about the least likely scenario of all possible scenarios.
Anyway, in the lawsuit you referenced, the judge's dismissed the lawsuit because the plaintiff, Gene Jacobsen, waited for three books to be published before raising issues of copyright infringement when he had every opportunity to object at the first book.
SCO had every opportunity to objecting to the alleged infringement a long time ago. Instead of objecting to the alleged infringement, they let it continue.
Gene Jacobsen says he didn't even read the first book until later and so he couldn't have complained about the infringement. SCO claims they hadn't compared the code until now and so they couldn't have complained. The parallels between the two cases are really strong.
SCO really should have done their due dilligence in a timely manner. They had every reason to do so and every opportunity to do just that. That they didn't is their fault and not that of the Linux community.
The fact that they waited until now to make the claims strikes me as being very suspicious.
And that's assuming that there really is an infringement, which I doubt.
There is also the question of mitigating damages.
It seems to me that SCO is attempting to maximize damages. I don't know if it applies to copyright law, but in many points of law, my understanding is that it is up to the injured party to try to mitigate damages. If they don't, the damages are frequently set to what they should have been had they mitigated damages.
For example, if someone throws a baseball through your window, you can't sue them a year later and collect for all the rain damage that has occurred since then because you refused to break the window.
And there is the question of when SCO learned of the alleged infringement. They have been quoted as saying that there wasn't anyone to sue before now. It sounds to me like they failed to mitigate damages while waiting for there to be someone big enough to sue.