Slashdot Mirror
SCO Claims Kernel Contains UnixWare Code
ergo98 writes "SCO has increased the intensity of the lawsuit with IBM by claiming to hold indisputable proof that copyrighted UnixWare code found its way into Linux, violating the rules of both camps. Whether this is true or not remains to be seen: SCO refuses to divulge the code in question, however they promise to reveal it in court shortly."
As already stated on LKML here, it's far more likely that they saw something that had been stolen from Linux or other GNU code in SCO, and thought is was the other way around.
It also isn't clear if SCO is referring specifically to Redhat userland, redhat kernel patches or what. It's only clear that they don't mean specifically the Linux kernal as found on kernel.org.
-If you wish to make a complaint, press 1. If you wish to wish upon a star, makes no difference who you are, press -- what else? -- the star key.
Compared to war, all other forms of human endeavor shrink to insignificance. God, how I love it. - Gen. George Patton
about the Sco vs. IBM suit, I can't help but think that SCO is going to be worse off than Mike Tyson's cellmate when all is said and done.
There are four boxes used in defense of liberty: soap, ballot, jury, ammo. Use in that order.
And they are repeated many many times! /*
*/
Those lines are exact duplicates of orginal Unix code! Oh no! They've got us!
Slashdot is like Playboy: I read it for the articles
[*] SCO lawsuit support (EXPERIMENTAL) (NEW)
If Y is selected, then copywrited code from unixware will be compiled into the kernel, if you have millions of $CURRENCY and would like to get SCO after you then say Y, most people would say N here.
Patch here
Even if this is true, shouldn't they have contacted Linus and had him remove the offending code? I'm sure he would have.
Since they are claiming Trade Secret status on the System V code, isn't failure to perform even basic attempts (such as contacting Linus) to minimise the impact of this leak enough to void the Trade Secret status of their code?
The more SCO speaks, the less credible this lawsuit sounds.
----
Open mind, insert foot.
...or do the stock quotes at the bottom of the article provide the best commentary on this issue?
Wouldn't it be interesting if someone managed to slip in copyrighted code intentionally, with the knowledge that it would eventually be found -- causing quite a bit of damage to the Linux movement...
Adjust your tinfoil hat, people.
So they can slam OSS, but what about going the other way? I've heard of software stealing GPL code in part and in whole, making modifications, and not releasing the source again. Some have been caught, I'm willing to bet a whole lot more haven't been.
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
I love this quote:
> "The Linux community would have me publish it now, (so they can have it) laundered by the time we can get to a court hearing. That's not the way we're going to go."
So you don't want us to fix this so-called infringement? Most companies do a cease-and-decist before a lawsuit, allowing the accused to make changes. If this infringment HAS cost them a billion in damages, wouldn't you think they would want the infringement to stop right away? They could still make their case in court and use the same so-called evidence to show that previous infringment caused the damage, but not allowing the accused to fix the problem just shows that it's not the infringement they care about. It's just a means to getting money.
In this article, they clearly refer to the kernel: "We're finding...cases where there is line-by-line code in the Linux kernel that is matching up to our UnixWare code," McBride said in an interview" How do they possibly expect to win a lawsuit when they can't even agree amongst themselves about where the UnixWare code appears in GNU/Linux? And what the hell is "the periphery of the Linux kernel"? Modutils? Fileutils? Util-linux?
The real "Libtards" are the Libertarians!
This seems quite reminiscent of the USL v. U.C. Regents case over the BSD release. USL maintained that the BSD code was tainted, but never cited any specific lines of code. USL decided to settle after the U.C. regents pointed out that USL was in violation of the license terms for the BSD code they were using in System V. At that point, USL probably realized that U.C. could force them to withdraw System V from the market and recall all existing copies in order to strip out the BSD code. Anyhow, as part of the settlement, CSRG did remove a few files that were said to be tainted, but since USL didn't indicate which files to remove, CSRG picked out a few of the files that were crufty and in need of replacement anyhow, and removed those.
Does anyone remember the letter that SCO sent out to customers back in the late 1990s, suggesting that customers would be better off with a professionally written and maintained operating system, rather than an amateur effort by a few hackers? It has a lot of other ridiculous comparisons like that. Someone (ESR?) wrote a parody letter refuting every one of their points.
I used to have the two letters posted outside my cube at a previous place of employment. I just tried to find them using Google, but I must not be using the right search terms.
Let's set up a fund to collect money from open source users to use for the sole purpose of buying SCO stock. We'll collect enough to just buy the damn company release all IP into the GPL that we own.
And that as they say will be that.
Shop smart, Shop S-Mart.
Ther are no WMD in the linux code, it was all moved to FreeBSD.
-- Bryan
If I recall correctly, companies must make an effort to minimize their damages under all circumstances if they want to be able to collect compensation for damages. For instance, if I am IBM, and my supplier of screws never delivers me my shipment of screws for my mainframes, I am responsible to find another supplier. I can't wait a year and not ship any mainframes and then try to collect damages of Billions of dollars of lost revenue. Such a claim would be absurd since I didn't do anything to minimize my damages.
Isn't this true for SCO? They were supplying source code to companies like IBM. Apparently, according to their claim, they were also losing great amounts of revenue to Linux due to the unauthorized use of this code in Linux. It seems like they could have minimized the damage by doing a "diff" command between the Linux sourcecode (which was always available) and their own code and found out immediately that there was tainted code in there.
By being open source, it seems that Linux should be the most compliant OS out their because anyone with such claims as SCO should immediately be able to check the source. For them to wait this long to check (as they are losing over a BILLION dollars) seems to be a gross incompetence of SCO management. What else could contributors to Linux do to ensure the compliance of Linux wihout access to SCO's code? It seems that by being open source, the community has already done everything in its power to comply to IP law. SCO losses are a result of its failure to do its own part ($diff file1 file2).
Besides, the fall of SCO did not happen overnight, why must IBM take disproportionate responsbility (assuming they are at fault, which is unsubstantiated at this time) for what appears to be very poor efforts on the part SCO to protect their own IP (especially since they are also a Linux distr.!!!).
Also, if I were an investor I would be very upset. SCO has basically changed their business model without proper disclosure to the SEC. It is pretty well known that after they made their claim, it would be impossible for them to continue as a software company. Yet they seem to be continuing to waste money on new releases of Linux products that nobody will buy. What is the logic of releasing products for an OS that you are trying to slow the development of? What kind of business strategy is that?
Finally, the fact of SCO is a Linux distro is really ironic.
I mean, if even they are openly distributing their own IP through Linux under the GPL, what right to they have to sue other companies for doing the same!? If they couldn't even ensure that they were not dilluting their own IP themselves (with a simple "diff" command), how can they require other entities to do so?
I really believe that SCO has not put enough thought behind this and some of upper management is going to be directly liable to the stock holders for some blatant acts of poor judgement.
Sdelat' Ameriku velikoy Snova!
/* Drunk. Fix later. (Dennis R) */
SCO released a linux distribution.
At least the kernel was released under the GPL.
I would like to see how they explain that IBM GPL release of code is much more damaging then their own release, under the GPL, of that same code.
The fact that SCO has licenced others to redistribute this code under the GPL should make it pretty hard to get damages for others doing the same.
"The Linux community would have me publish it now, (so they can have it) laundered by the time we can get to a court hearing. That's not the way we're going to go."
Now, admitting that anything is possible, I must ask, is McBride insane? Here is how to "clean" the code out of the Linux kernel:
Step 1: Log into kernel.org.
Step 2: Remove or patch the offending code in every version of the kernel ever posted to that site.
Step 3: Run complete tests on every patched kernel to make sure it builds and runs on all supported architectures.
Step 4: Contact RedHat, SCO (Caldera), IBM, debian.org, Suse, Slackware, and anyone who has ever distributed a Linux kernel and have them do the same.
Step 5: Contact every Linux user in the world and have them patch their kernels.
Laundering, indeed. I predict that this evidence will turn out to be shit.
I bet this is the stolen code:
for (i=0; i 256; i++) {
Dirty, stinking thieves!
So that is how they found the code... there is a bug... "i" is probably a single byte variable...and it just overran its bounds by one! (the range should only be from 0 to 255, not 256)
- SCO doesn't claim in its' filing that there is any SCO IP in the linux kernel, contrary to what McBride says
- SCO does claim in its' filing that certain compatability libraries that allow UnixWare binaries to run under linux are their IP.
- None of the current distros has a copy of any of these libraries.
- McBride should read his own companys' suit before giving interviews, but then he would be open to charges of "pump and dump" vis his SCO stock (not that ignorance is a defence, but
...)
This whole thing is so fucked up that it can only be a stock-market scam.I find this statement has more merit than anything from SCO. Corporate driven programming is much different from Open Source. With OSS, there's really no pressure to get stuff done and out the door, or at least far less than in the corporate world. This idea is based on Linus's many comments about when such and such release will be shipped : "when it's done".
Now contrast that with UnixWare version whatever, with a crackpot like McBride at the helm whipping up the team to get the code out the door. You can imagine the chaos: see the Mythical Man Month about OS/360, and I believe there's a book about Dave Cutler's team at M$. This is not Extreme Programming, it's the death march.
To conclude, which programmer is more likely to grab some peice of code that just works?
Here's another point: From my experience, OSS code is revised and rewritten constantly. Look at Ingo's work with the scheduler, or the recent work by several folks on the VM. Or Apache Xerces (XML4J). I've been using that for a few years, since it had jp (originally written by some IBMers at one of IBM's Japan labs I think), and that has been rewritten from scratch at least once. One last example - Mozilla was rewritten entirely, sidelining it for several years. That was a questionable move, but I say they did a good job - Mozilla is awesome.
Again contrast that with corporate software - how often do you rewrite working code from scratch? You do if business rules change, but I'd argue that with corporate software (think COBOL) it's more if it ain't broke don't fix it. Case in point: at the organization I work at, we have a database (well, more of a filesystem) written in assembler that is basically 25 year old code. Why? It works, it is very fast, it runs mission-critical systems, and it's very hard to modify, let alone maintain it. (Yes it is being replaced, so they say).
So, Unix code in Linux, copied line by line? Doubtful, I side with Perens.
To conclude, Perens has a good point. But as can be seen by the Sun/Netscape vs. Microsoft lawsuit, anything can happen in the courts. They'll have fun figuring out the "obfuscated" code.
The reason that SCO is pursuing this case in the first place is that they are doomed. They rely primarily on proprietary UNIX licenses (OpenServer and Unixware) for x86 hardware to survive and anyone with half a brain is making the easy migration from SCO UNIX to Linux. In the meantime SCO has to maintain not one but two proprietary UNIXes with a development team smaller than RedHat's, and they haven't even got a version of their software that runs on Itanium or Opteron processors. Not to mention the fact that they are already losing money with no relief in sight.
In short, SCO is screwed.
However, they realized that they could alleviate some of the hurting in the short run by running a FUD campaign against Linux. If they scare enough of their current customers into thinking that Linux has intellectual property problems then they might retain some key accounts for another round of upgrades. Some investors might even believe that they have a chance of making real money with their lawsuit, and this would give SCO managers a chance to cash in some of their SCO stock while it is still worth more than the paper it is printed on. That is what this circus is all about. SCO knows they aren't going to win. Heck, they aren't even *trying* to win. The whole thing is nothing more than an elaborate con job.
RedHat and friends could countersue for damages based on their ridiculous claims, but this isn't likely to make them any money. After all, if SCO had money they wouldn't be trying this stupid stunt in the first place.