I got asked to comment on them by some local firms.

Most of the listed files are really the same file in different architecture
subtrees -- if you filter them down, there's really only about 16 unique
files. A majority of them are header files that describe a large number of
standard symbolic value to error code mappings, all of which are documented
in the POSIX standards and in the BSD source, which the Regents of
California have published permission to use these materials without the
standard BSD copyright header. The other files are reimplementations of
things like toupper() and tolower(), which existed far earlier than the
existance of Linux (or SCO for that matter). Linus has admitted to authoring
some of the really ugly bits of those files, an embarassment for him -- that
code is thoroughly ugly and embarassing to look at.

SCO claims these are part of the ABI, although there is little or no
executable code in any of the files (I don't consider #define statements
executable). I don't see how a bunch of constant definitions constitutes a
ABI.

It's clearly a desperation move for SCO. The analysis on
http://www.groklaw.com is excellent for this case, and should be required
reading for your CIO.

-- db

David Boyes
Sine Nomine Associates


> -----Original Message-----
> From: Linux on 390 Port [mailto:[EMAIL PROTECTED]
> Behalf Of Joe
> Poole
> Sent: Monday, December 29, 2003 3:36 PM
> To: [EMAIL PROTECTED]
> Subject: SCO Christmas Letter
>
>
> We received our Christmas letter from SCO, warning us that we may not
> make Santa's list next year if we persist in befriending
> penguins with
> questionable ancestry.  Although dated on December 19th, the
> letter did
> not arrive in time for Christmas Eve and therefore could not
> be placed
> in the CIO's stocking.  CIO immediately forwarded same to the
> barristers so that they might also enjoy the season's greetings.
>
> Has anyone else on this list received the SCO Christmas
> Carol?  Not as
> well written as that by Charles Dickens, but classically entertaining
> nonetheless.
>

Reply via email to