Holiday cheer from the SCO Group

Advertisement

We'll start with the quarterly results, as described in this press release. The company lost $1.6 million on revenue of $24.3 million. Of that, $10.3 million came from licensing agreements - all from Microsoft and Sun. It would appear that there are still no other paying licensees. In the conference call, SCO management stated that license revenue in the next quarter would be "minimal." Some direct questions were asked about just what sort of revenue was being received by other licensees, but the answers were, to put it charitably, evasive.

The more interesting part of today's activity is a view into the claims SCO plans to make in the coming months. To that end, there has been another press release, and a new letter being sent to Linux users. What the letter makes clear is that SCO now considers part of the Unix application binary interface (ABI) to be its property. Linux implements the Unix ABI, so SCO has picked out several dozen files which, it claims, violate its copyright. The full list is in the letter, but what it comes down to is each architecture's version of errno.h, signal.h, ioctl.h, plus a few others.

These include files all have the same form: they are really just long lists of #define statements assigning values to symbols. They define the various error codes returned by the kernel, the numbers associated with signals, and the numbers for ioctl() commands. Many of these numbers have nothing in common with any version of Unix, but many others do. So, if you compare the first part of the definitions in the 32V version of user.h with a 2.4 errno.h, you see:

#define EPERM   1
#define ENOENT  2
#define ESRCH   3
#define EINTR   4
#define EIO     5
#define ENXIO   6
#define E2BIG   7
#define ENOEXEC 8
#define EBADF   9
#define ECHILD  10
#define EAGAIN  11
#define ENOMEM  12
#define EACCES  13
#define EFAULT  14
#define ENOTBLK 15
#define EBUSY   16
#define EEXIST  17
#define EXDEV   18
#define ENODEV  19
#define ENOTDIR 20
...

#define EPERM            1
#define ENOENT           2
#define ESRCH            3
#define EINTR            4
#define EIO              5
#define ENXIO            6
#define E2BIG            7
#define ENOEXEC          8
#define EBADF            9
#define ECHILD          10
#define EAGAIN          11
#define ENOMEM          12
#define EACCES          13
#define EFAULT          14
#define ENOTBLK         15
#define EBUSY           16
#define EEXIST          17
#define EXDEV           18
#define ENODEV          19
#define ENOTDIR         20
...

The 2.4 version has comments on each line which have been removed in the above listing, but, even taking those into account, there is clearly a high degree of similarity between the two. The definitions in Linux are obviously taken from older Unix systems. That is not surprising; Linux was intended to implement the same interface. Linux is not alone in having reproduced the Unix error numbers; if you look at the Minix version of errno.h, you see the same interface used. Microsoft uses the same numbers. Modern BSD systems also use the same definitions, of course. The basic Unix numbers for errors and signals have been widely reproduced, to say the least.

If the files in question were, indeed, copied from an ancient Unix distribution, then the Linux developers have arguably violated the associated BSD license by leaving out the copyright headers. This is a copyright violation, but it is also easy to fix by simply restoring those headers. There are enough other sources for these numbers, however, that proving that they came into Linux via any particular path could be hard.

There are a couple of things that one should keep in mind, however, when evaluating SCO's new claims. One is that the copyright status of ancient Unix is uncertain at best, as has been reported many times. The judge in the BSDI case came to the conclusion that USL's chances of enforcing its copyrights were poor. SCO will not have improved those chances. Novell's recent reassertion of its claim to still own the Unix copyrights could also complicate matters for SCO.

The truly important issue, however, is that the old Unix ABI is exactly that: a well established ABI. Copyright law allows for the protection of expressions of an idea, but not the idea itself. Concepts used in an ABI, like "the number 12 means no memory is available," can be very difficult to copyright. If there is only one way to express an idea, you cannot get copyright protection for that expression. In this case, there are truly few alternatives to:

    #define ENOMEM 12

SCO will have a hard time convincing a judge anywhere that copyrights can protect this sort of code - especially given that the error names (but not the associated numbers) are part of the POSIX standard.

SCO seemingly intends to try, however - at least for as long as it takes to shake down some nervous users. To that end, the company is taking two approaches. One is to threaten anybody who distributes Linux with the offending files; that is what the letter was sent out for. From statements made in the conference call, one could conclude that SCO thinks it has users in a bind; constants like error and signal numbers cannot be changed without breaking binary applications. By claiming something that cannot be easily removed, SCO apparently hopes to inspire companies to pay up instead.

The other approach is described in the second press release: SCO is sending notices to its Unix licensees requiring them to "certify" that they are in compliance with the Unix agreement. The letter requires a long list of promises from Unix licensees, including:

It has long been clear that signing a contract with the SCO Group is a Bad Idea. The SCO Group is using its contracts to go after its customers - something which does not generally inspire those customers to buy anything else. The Unix contract is being used as a lever to force those customers to "certify" that they are not running Linux. Needless to say, at this point, few of these customers will be in a position to do that. They are now in a bit of a difficult situation; they can refuse to certify, pay SCO, or claim that Linux does not actually contain any copyrighted ABI code.

As a short-term strategy for SCO, this move must look pretty good. The use of the existing contracts in this way may well succeed in applying enough pressure to make some customers give in. None of those customers are going to appreciate this behavior, however; one would assume that many of them will decide (if they have not already) that entering into any other agreements with the SCO Group is not in their best interests. SCO is destroying whatever future business it may have still had to expedite a short-term shakedown.

A couple of other notes from the conference call are in order. It began with a statement that the call is copyrighted by SCO, and any reproduction ("in whole or in part") is prohibited. Transcripts will certainly be posted; it will be interesting to see if SCO tries to get them taken down. Analyst Dion Cornett (Decatur Jones Equity) appears to be getting a clue: he asked SCO whether it really believed it had a valid license to distribute Samba. Strangely enough, SCO's answer did not address that question at all. Finally, Darl McBride presented the SCO litigation scheme as "a model many companies will adopt" in the near future. If SCO succeeds in its attempts, that statement could well come true. The foundation of SCO's new claims appears weak at best, however. SCO is more likely to become a very different sort of example.