The Inquirer-Home

SCO reveals 'stolen code'

Ancient code from before the dawn of Unix
Fri Aug 22 2003, 11:46
IF YOU'VE been having trouble keeping the latest developments in the SCO vs. Linux saga straight, here's a quick(ish) summary.

SCO put a lot of effort into portraying their side of the case at the recent SCO forum. It started out with an intro film portraying SCO director Darl McBride as the Unix world's equivalent of James Bond. Licensed to file lawsuits? (The special effects in that Bond film were rendered with a Linux cluster by the way).

SCO then revealed some samples of the code it says was illegally copied into Linux. Apparently provoked by the calls of show us the code or shut up, it picked a couple of (presumably) the most egregrious examples and flashed them up on the projector.

Quicker than you can say Hagebuttentee, Erich Bonnert from German publishers Heise whipped out his camera and photographed the slides, thus providing the Linux community with the first concrete examples of the alledged million-line larceny.

Open Source experts like Bruce Perens, his good friend Eric S. Raymond and Greg Lehey descended on the snippets, eager to tear apart SCO's attack on their beloved operating system.

Some of the code was 'encrypted' by printing it with a Greek font. This back-of-a-cereal-packet secret code didn't slow down the Linux hackerati for long, and soon their analyses started pouring out into the wibbly wobbly web. SCO released the presentation to journalist Bob McMillan of IDG News Service and it is now linked from the Perens link above.

After several revisions, and a set of text analyses worthy of the best of the Bible researchers a concensus seems to be emerging, at least on the Open Source side of the debate. The first example is a memory allocation routine from the somewhat obscure Itanic section of the Linux kernel, contributed by SGI.

According to these analyses, it's a version of an ancient piece of code, dating back to at least 1973, and published in a half dozen contexts and under just as many licenses, some of them Open Source. So far so good for the Linux community; unfortunately the DNA fingerprinting implies that it is a descendent of the version in SCO's proprietary System V Unix, a version that on the face of it can't be used for Open Source projects. Another sticky point is that the Copyright ownership is listed in the file in question as being SGI's, yet it's pretty clear that the Copyright belongs to SCO: Regardless of what Open Source license SCO licensed its code under, you can't normally delete someones Copyright notice and substitute your own.

So at the very least, SGI has some explaining to do. Perhaps it has the right to do what it wants with that code, perhaps it messed up.

And the Linux community? You would think that they would be rushing to remove the incriminating code, so that the upcoming Linux 2.6 release could at least be free of this "living fossil" of the software world. But as it turns out it was already removed because a) the copyright situtation was unclear and b) it wasn't very good code, and Linux already had some code that did the same thing and was better.

Whether this is an indication that one of the people who signed the NDA indirectly tipped off the kernel developers, or whether this is an indication that the thousand eyeballs of Linux kernel development tend to spot problems like this automatically is hard to say.

There was a second code snippet in the SCO slides, but it doesn't seem to belong to SCO at all, being a part of the Berkeley Packet Filter, released under a license that is Open Source. Now there may be a different part of the file that SCO hasn't shown that actually does come from SCO's Unix, but then, why didn't it show that? SCO's assertion that this is its code casts doubt on SCO's ability to keep track of what code belongs to whom.

Perhaps someone needs to audit SCO's code for missing copyright messages... ยต

Share this:

Comments

There are no comments submitted yet. Do you have an interesting opinion? Then be the first to post a comment.

aboutus
Advertisement
Subscribe to INQ newsletters
Advertisement
INQ Poll

48 core processors

What would you use a 48-core processor for?