Most Read Technology Reporter For More Than Two Decades

Maureen O'Gara

Subscribe to Maureen O'Gara: eMailAlertsEmail Alerts
Get Maureen O'Gara: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

SCO Admits To Not Knowing Own Code History in Recent Q&A

SCO Admits To Not Knowing Own Code History in Recent Q&A

From the start, questions have surrounded the process and people SCO used to determine the alleged code violations in Linux. There is the phantom MIT mathematics department team which MIT itself can’t identify and which SCO has since said were people with former MIT mathematics department relationships, not MIT employees.  These former MIT people have still not stepped forward and given anyone an indication that they are up to the task, what methods they used, or that they even exist. 

 

The MIT problem casts doubt on the process SCO uses to identify allegedly infringing code but now we have to wonder more deeply about what steps SCO is taking to validate or understand its own claims.  Is it just a Jr. programmer at SCO that has been grudgingly tasked with writing some simple scripts to do some string comparisons?  When you hear SCO mention that just a few people at the top of the company are involved with the case, and none of these people have much history in UNIX code development, you get the idea that SCO’s internal discovery process is pretty thin.

 

On Tuesday, SCO published an open letter here. The letter is mostly posturing with very little information but the interesting thing is that on Thursday, Computer World came out with a Q&A with CEO McBride on the SCO letter.  In this Q&A, CEO McBride states, “Well, at SCO Forum, there were some folks that came out and basically sniffed out some of the [disputed System V] code we were showing and [concluded] that it emanated from SGI.”  That this code “emanated” from SGI was news to SCO.

 

Immediately after the SCO Forum, SCO stated that it should be in a position to know where disputed code came from.  But these SCO statements were another case of SCO officially guessing wrong, given McBride’s comments this week.  SCO showed this week that it has no idea what the history of a particular snippet of code might be – even a high profile snippet like the one SCO highlighted at SCO Forum.  It’s no surprise that SCO has shown ineptness again but there is more going on here than ineptness.

 

If SCO had no idea of the history of the code they showed at SCO Forum, that means they probably also have very little or no idea about the history of the other snippets of code that they alleged infringe.  More clearly, SCO does not know the history of the UNIX historical code base or its own code.

 

Let’s extend this thought a little further.  If SCO did not know the history of the SCO Forum snippets, their lack of  knowledge confirms that SCO did not do any detailed digging on even the most public chunk of code they have made available to the public so far.  If SCO couldn’t verify a poster child code example, it’s very safe to say, they have no spot method (per snippet) and no systematic method (millions of lines) for determining the history of any of the code in their legal claims.  SCO may be doing string comparisons to say code X looks like code Y but, as the SCO Forum example shows, SCO needs to dig far further than this to prove any type of infringement exists. That SCO accepts the Raymond / Perens conclusion as both correct and as new information, shows that SCO is not performing these checks, even on a per-snippet basis for code they choose to show.

 

From another perspective, we can also see in McBride’s comments that SCO is, unfortunately, using the analysis of Raymond/Perens to attack SGI.  This reliance on Raymond and Perens shows two other things are happening:  1) SCO is using the analysis of the open source community above its own analysis (or lack thereof), and 2) SCO does not seem to have done any work that can refute the Raymond / Perens analysis.  Not only can SCO not do the checks itself, this shows that even on a per-snippet basis, SCO has no hope of matching the credibility of analysis of the open source community.  SCO should be afraid of identifying any more code because they would have no earthly idea what the history of the code might turn out to be. Court will be a nightmare of surprises for SCO - just like SCO Forum.

 

So, for all purposes, it’s safe to say SCO and its crack legal team just can’t do the deeper historical analysis needed here.  Would a junior programmer be able to produce the findings that the open source community can?  No way.  Such an individual simply would not have the depth of historical knowledge to know where to look.  Eric Raymond and Bruce Perens are very smart, highly experienced individuals.  SCO has nobody on its staff with similar levels of knowledge of the UNIX family tree history and the various licensing actions and cases over they years that have opened UNIX to the public at various times and in various ways.

 

That SCO turned to an alleged MIT team admits they don’t have the resources in house to begin to tackle the job of researching code history.  String comparisons yes; code history, no.  And this job is not about writing an algorithm, as MIT mathematicians might be wont to do, this is all about historical, bookish research.  Now that the MIT team seems to be missing in action, it may be all up to SCO senior managers and executives and yet, I don’t see anyone in that group with the ability to make these determinations either.  SCO needs an Eric or a Bruce and they can’t get one.

 

Having no idea if its claims have merit has not stopped SCO so far so we can expect more from SCO along the lines of big claims with no merit.  And merit has risen up again with the open source code analysis having more merit within SCO than even SCO’s own analysis.  With little hope of ever effectively analyzing the history of the code, SCO is simply placing a tall order on the side of hope and wishful thinking when they claim "code infringement."

More Stories By Paul Nowak

Paul Nowak first used Linux in 1995 while migrating from Sun to Linux at the University of Michigan. He used Linux in subsequent IT projects including web, telecom, telemetry and embedded projects and is currently CIO of a small professional association based in Washington D.C.

Comments (65) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Jools 09/14/03 05:52:51 AM EDT

Is there no mechanism whereby IBM could present info like this to the court to show SCO is basically timewasting and get it struck out without a trial?

If the courts are taking until 2005 to start the case they must be pretty busy and to have McBride et al turn up with a non-existent case to waste the time of a judge, an entourage of lawyers and christ knows who else benefits no-one.

MonkeyPoop 09/14/03 05:26:50 AM EDT

kwalther: You don't have to prove someone made money from your copyrighted material to prove damages, just that they *caused* damage, which SCO claims was due to lost sales of Linux. "If Linux hadn't copied our valuable code and gave it away, then we wouldn't have lost billions in sales," was the essential message from Chris Sontag (VP IP, etc.). This is a valid claim, but they have the heavy burden of proving both 1) Actual damage 2) Amount of damages. Everyone knows that if SCO had such superior technology to Linux, they would have a sizable market... but they don't, so they won't. No damage here. Next case.

Joe Mason: You must realize that most UNIX's are hybrids of other UNIX software, so there is no "pure" UNIX. Linux, and all of SCO's UNIX flavors have some code or techniques in common.

Trying to lay claim to the code and techniques now, like SCO is doing, demonstrates how incompetent SCO executives are about the history of UNIX. They are out of touch with the real high-tech prince and princesses of the open source community and have no clue about the history of UNIX computer code. The open source community has discredited these guys so far, that it appears they are now being somewhat conciliatory. Why? Because they know their ass is grass, and mark my words, the stock dumping will start very soon.

SCO will lose in court, and get sued out of existence. All because they decided software engineers were too expensive (they fired all but 3... and this is supposedly a software company???).

(P.S. Sell all your Microsoft stock! They are going down hard because of Linux. Watch for lawsuits from Microsoft, against Linux, in the next year or two).

David Houghton 09/14/03 05:13:01 AM EDT

No, it work on the GNU GPL licence. So since SCO are only kicking up a fuss now (and had plenty of chances to study the code before then), they had already agreed to the terms of the licience. Which means that if code is in there that belonged to SCO, it is now available to everybody. SCO still own the code - they just can't get paid for anything except the ones they release. Freedom to Copy

Barney Rubble 09/14/03 05:11:26 AM EDT

Was that "crack legal team" or "legal crack team"

Fu Yee-chung 09/14/03 05:09:35 AM EDT

So, SCO had no intention to lie when they first started the lawsuit, they were just a bunch of clueless idiots who actually thought they had a case. Sadly, everything had gone south on them after the SCO Forum, and they realize they are on their way to becominng the laughing stock of the IT world forever. Now they have to resort to lying to drag the case on as long as they can, trying desparately to delay the inevitable. I kinda feel sorry for them. :)

Anon3 09/14/03 04:48:15 AM EDT

Not to defend SCO, but this kind of gross misunderstanding is annoying.

>If SCO did not know their alleged source-code was in linux in the first place, and linux was still being released for
>free, then there is no damages to award because no one was making money off of it. I can download linux for free.
>I'm not making any money off it; there are no damages to collect.

Does Not Matter.

Whether or not a profit is made from a given infringement is not relevent to whether or not damages can be awarded for that infringement. This is the old "non-commercial use" myth, and it's just that: a myth.

>It's a "We the People" software, and it will stay in the public domain. Period.

Linux isn't in the public domain, bonehead.

kwalther 09/14/03 01:49:15 AM EDT

If SCO did not know their alleged source-code was in linux in the first place, and linux was still being released for free, then there is no damages to award because no one was making money off of it. I can download linux for free.
I'm not making any money off it; there are no damages to collect.
AND linux, being a free OS will evolve past the Canopy Group. The kernel will change, just like everything else. It's a "We the People" software, and it will stay in the public domain. Period.

anon2 09/13/03 10:24:21 PM EDT

Of course, Mr. Mason, all proprietary OS vendors have full attribution for their source, right? It's unseen, so it must be theirs...

Joe Mason 09/13/03 08:54:46 PM EDT

It may be correct that SCO can't give chapter and verse on the history of every snippet, fine. The question that may be more important to Linux users is does Linux have a serious attribution problem with copyrighted code including licensed open source code? If more SGI problems come up in the future, that will also hurt the Linux code base. Big enterprise companies don't want to have to hire source code archeologists to make sure the Linux code isn't copyright infringing material or possibly violating some patents. Perens' and Raymond's work may have embarrassed SCO, but it wasn't a clean bill of health for Linux.

anon 09/13/03 08:49:16 PM EDT

SCO did know about SGI in advance, but they had to make a statement after SCO Forum because they started getting inquiries from people wanting to know if SCO planned to sue SGI.

SGI also made a statement that SCO has no basis for a claim.

The most amazing piece of evidence was actually the other slide show example, the berkley packet filter from BSD. Afterwards they claimed it was not meant to show obfuscated code, just that they could match similar code. The slide in question had the title "Obfuscated Code" with the subheading "Obfuscated System V Code Has Been Copied Into Linux Kernel Releases 2.4x and 2.5x"

http://brucep.webfarmhosting.com/VegasSlideShow/frame.htm (slide 15)

anon 09/13/03 06:30:50 PM EDT

Only the SVRx malloc code was public domain (probably, at least to the extent that was copied). The Linux malloc code is GPL, the original BPF code is BSD licensed and the Linux BPF code is GPL. Don't mistake licensed open source code with public domain, the difference is important both to this case and generally.

Also note that if you read the original article SCO didn't say that they didn't know the code was from SGI, just that Perens and Raymond had to work it out because it wasn't on the slides.

tim hawkins 09/13/03 06:24:02 PM EDT

All code shown was in public domain except for the SGI Code.
The SGI Code is not even in linux anymore. So that offending peice of code has been removed

anon 09/13/03 06:01:19 PM EDT

SCO didn't need Perens and Raymond to tell them that the code was from SGI, it was in the copyright statement at the top of the file. They had to have found that file in Linux to have any evidence at all so claiming they didn't know it was from SGI is clearly another LIE. Keep collecting soon there will be enough to demonstrate fraud.

(The Linux file is ../arch/ia64/io/sn/ate_utils.c)

Tom Adelstein 09/13/03 03:10:04 PM EDT

One of the great lessons anyone can learn belongs in the classification "counter-intelligence". Anyone having had the training and finally using it to identify the quality of intelligence - be it for marketing, litigation or security - would recognize the vast inconsistencies in SCO's statements over the months.

In previous writngs, I have also identified techniques of "disinformation". Clearly, SCO's statements fall into every category one might use to promulgate disinformation.

The risk faced by a litigant such as SCO in running off at the mouth is the fact that public statements can be questioned in hearings before a trial. With what I have seen, they will have some serious explaining to do.

So, if one questions their knowledge of their own code, what about their knowledge of the law?

Bob 09/13/03 02:26:49 PM EDT

Concerning the "rocket scientists," it turns out that the Canopy Group owns another entity, DataCrystal (www.datacrystal.com) that advertises itself as offering "Advanced Pattern Recognition." So this may be another way for Ralph Yarrow to extract cash from SCO and shovel it into a different Canopy pocket. When the SCO 10-Q is released shortly, we may be able to see whether SCO in fact purchased large volumes of "pattern recognition services" from its fellow Canopy venture.

A few moments spent with MapQuest's aerial photos and the business address provided on the DataCrystal site demonstrates that DataCrystal operates out of someone's house. It is either a very tiny company, or it is simply a shell that Yarrow uses to "hide the pea" now and then.

There is a relatively well-known artificial intelligence project also known as DataCrystal. The Canopy company does not appear to be related to the university project in any way. It just accidentally happens to have the same name.

The list of areas of expertise claimed by the Canopy version of DataCrystal is beyond belief. No one familiar with the field would believe for a moment that even the largest defense contractor has experts in so many different disciplines. That this offered by an outfit operating out of someone's house is ludicrous. There is definitely something odd happening there, and it may well be related to Darl McBride's "pattern recognition" efforts.