% fortune -ae paul murphy

SCO: finally, an opportunity to judge for yourself

There's something in SCO's most recent press releases and court filings that lets us, finally, check out some of the facts for ourselves.

Remember, however, that the basic claim is simply that IBM allowed some of its people to use their access to, or knowledge of, contractually protected Unix source code (included covered derivitive works) as part of their contributions to Linux. Beyond that, everything else you've read on groklaw and elsewhere is fundamentally immaterial -not because it hasn't seriously damaged SCO's prospects for staying in business or had a negative effect on the Linux community, but because it really doesn't have anything to do with the fundamentals of the case.

My vision of what happened is simple: a bunch of guys tasked to deliver Linux on the System 390 had a tendency to ask themselves and some handy colleagues down the hall how some of the key problems were solved for AIX. At the technical level that kind of behavior simply makes sense - unfortunately IBM had a contract with AT&T and its successors that said they weren't allowed to release the result into the public domain.

So why did IBM circle the wagons when caught instead of quietly ante-ing up the standard license continuation fee the way Microsoft did? I really have no fixed idea - but what I've heard is that some fairly senior managers were involved in an internal spat over an unauthorized Linux port to the 370 architecture and may therefore have had deep personal stakes in getting the politically correct version out of the Boeblingin skunk works fast.

Of course that was then, this is now, and things are pretty messy with the whole thing a combination of tar pit and third rail for anyone who doesn't toe the IBM line.

Last week, however, SCO finally offered the court some serious substantiation - or so they said. According to the news.com report by Stephen Shankland the actual documents are sealed, but SCO claimed to have "identified 217 areas in which the company believes IBM or Sequent, a Unix server company IBM acquired, violated contracts under which SCO and its predecessors licensed the Unix operating system."

Here's more from that report:

"Some of these wrongful disclosures include areas such as an entire file management system; others are communications by IBM personnel working on Linux that resulted in enhancing Linux functionality by disclosing a method or concept from Unix technology," SCO said. "The numerosity and substantiality of the disclosures reflects the pervasive extent and sustained degree as to which IBM disclosed methods, concepts, and in many places, literal code, from Unix-derived technologies in order to enhance the ability of Linux to be used as a scalable and reliable operating system for business and as an alternative to proprietary Unix systems such as those licensed by SCO and others."

As I've said before I think the Sequent thing may turn out to be a deliberate red herring hauled in front of SCO's lawyers as sucker bait but the resolution there will be based on analyzing contracts, not code.

For the main issue, it's the code that counts - but no one can really talk about the facts because those who have access to the AT&T materials aren't allowed to say anything, and those who don't, can't form an independent opinion. However: this latest SCO formulation -that "some infractions are communications by IBM personnel working on Linux that resulted in enhancing Linux functionality by disclosing a method or concept from Unix.." - breaks that logjam.

The reason is that much of the discussion going into the 2.4 kernel and the revisions made to it is publically available. As a result I'm looking for help in scanning through the files available: first looking for threads that reveal disconnects between what was in the 2.4 kernel and basic Linux design ideas or thinking, and then following up to see where the "interloper" ideas might have come from.

For example this discussion from October of 2000 suggests that a key device for enabling direct I/O didn't really fit with core Linux programming ideas. Now, obviously, I don't have AIX 3.2 and later source to compare this to, but it seems like one of those dumbly implemented dumb ideas that made those products such a joy to work with.

There must be others -for example this one from 2003 (!) is interesting.

I imagine that there are probably lots of examples like this, and I'm not suggesting that their existence proves much - only that this kind of thing matches up to that particular line from SCO's press release and thus gives us our first real opportunity to research at least part of the claim ourselves.

So, if you're not busy right now... I'd like some help in locating and interpreting candidate threads from the 1998-2001 period. In particular please look for stuff affecting things like write addresses in device drivers, hardware memory management on the PowerPC, page fault and VM management, and floating point processing.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.