decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
Saturday, February 21 2004 @ 08:25 PM EST

SCO's Chris Sontag said, at the Harvard appearance, that despite Linus' claiming authorship of ABI files such as errno.h and stating he didn't refer to UNIX when writing them, he, Sontag, still had issues with those files. So Groklaw member Warren Toomey from the Unix Heritage Society has done some work digging up a bit more on errno.h. I'm sure it will convince the reasonable folks at SCO that they are barking up the wrong tree. Or it won't. But the rest of you may read it and reach your own conclusions. This is only the first in what will be several articles on the ABI files by Dr. Toomey.

****************************************************

The ABI Files: Errno.h
~ by Warren Toomey, the Unix Heritage Society

Introduction

In SCO's REVISED SUPPLEMENTAL RESPONSE TO DEFENDANT'S FIRST AND SECOND SET OF INTERROGATORIES, their supplemental response to interrogatory 12 states:

SCO objects to this question as overly broad and unduly burdensome, and on the basis that it seeks information neither relevant nor calculated to reasonably lead to the discovery of admissible evidence insofar as it requests the identity of source code and other material in Linux contributed to Linux by parties other than IBM or Sequent. Subject to and without waiving these objections, as it pertains to SCO's rights involving IBM's contributions to Linux, SCO has set forth that information in response to Interrogatories Nos. 1 and 9 and the corresponding exhibits. As to others who have violated the terms of their Software and Sublicensing Agreements, that information is contained in Exhibits A through C. Specifically, in Exhibit A, it details the line-for-line copying of UNIX System V code that improperly appears in Linux. Similarly, in Exhibit B, SCO identifies the application binary interfaces ("ABIs") that SCO has rights to that are improperly in Linux. Specifically, in 1992, Unix Systems Laboratories (USL), SCO's predecessor in interest, sued Berkeley Software Design, Inc. (BSD) for, among other things, copyright infringement. One of the bases of that action was BSD's copying and distributing some USL UNIX System V files without proper permission or attribution. The confidential Settlement Agreement that ended the Unix Systems Laboratories, Inc. v. Berkeley Software Design, Inc., litigation required BSD to change the copyright information in certain of these files, including the nine files listed in Exhibit B. To SCO's knowledge, BSD complied with the terms of the Agreement, and gave USL the proper attribution, as also set forth in Exhibit B. At a later time, persons as yet unknown copied these files into Linux, erasing the USL copyright attribution in the process. The files in Linux that improperly use the ABIs are as follows [list omitted]:

SCO asserts that "line-for-line copying of UNIX System V code . . . improperly appears in Linux'' and that "persons as yet unknown copied these files into Linux, erasing the USL copyright attribution in the process''.

This report looks at SCO's assertion of direct copying of System V code into Linux with copyright removal and compares it with the assertion from Linus Torvalds that the code in question came from another source. This report examines only the ABI file errno.h.

The errno.h file in all Unix and Unix-like systems (and in many other non-Unix systems) is a list of possible errors that can be returned to an application program when it asks the operating system to perform a task, known as a "system call'', and that task cannot proceed normally. Some of the reasons for system call failures are lack of permissions, others are temporary lack of resources, while others occur because the application program gave an invalid request to the operating system.

Many systems share a common list of errors, and this list of errors is defined by the POSIX standard and also the Single UNIX standard. As these are both open standards, SCO cannot claim any copyright on the list of error names. However, each error must have a unique number, so that the operating system can communicate the error number back to the application program. For example, the error "operation not permitted'' (known as EPERM in the POSIX standard) might be given the value 2 in a specific Unix or Unix-like system. The actual value for each error is not defined by the POSIX standard, but if systems do use a consistent error numbering scheme, then executable binaries from one system can run on other systems and understand the errors that the other systems report. The choice of numbers and how they are alloted to the errors is arbitrary and without 'expressive content', so the mere facts of what number goes with which error cannot normally be copyrighted.

To have a valid assertion that "line-for-line copying of UNIX System V code . . . improperly appears in Linux'' for errno.h, SCO needs to demonstrate that error names, their numeric values, and any associated program comments were directly copied from System V to Linux.

Errno.h in Linux 0.01 to 0.96c

Linus Torvalds released version 0.01 of the Linux kernel source around the "middle of [19]91'', and this includes the kernel file linux/include/errno.h. SCO asserts that this file was copied from System V source code as noted above. Linus and others, on the other hand, assert that the file "was taken from Minix''. Let's examine Linus' assertion and then SCO's assertion.

Linus believes that he used the error definitions in Minix to construct the errno.h file in Linux 0.01. The Minix operating system, version 1.1, was released by Andy Tanenbaum and Prentice-Hall around 1987 as a book and an accompanying set of floppy disks. Subsequent releases quickly followed: 1.2 around 1988, 1.3 in 1988, 1.4 in January 1989, 1.5.0 in November 1989 and 1.5.10 in May 1990. Minix 1.6 was developed in-house after 1.5, then released to beta-testers in October 1992. It was followed up by Minix 1.7.1 in November 1995. If Linus did use Minix to construct the errno.h file, then it would have been based on the file from Minix 1.5.10.

The early vesions of Minix (1.1 to 1.4) had a very plain errno.h file: no copyright notice, no comment header, no comment for each definition. Minix 1.5 was a significant rewrite; although there is no copyright notice, the 1.5.10 errno.h file contains a comment header and comments for each error definition. More importantly, each definition's value is wrapped with a _SIGN macro to convert from negative numbers in the Minix kernel to the positive numbers used by the applications.

The earliest errno.h from Linux 0.01 has this comment:

/* 
 * ok, as I hadn't got any other source of information about  
 * possible error numbers, I was forced to use the same numbers  
 * as minix.  
 * Hopefully these are posix or something. I wouldn't know (and posix  
 * isn't telling me - they want $$$ for their f***ing standard). 
 * 
 * We don't use the _SIGN cludge of minix, so kernel returns must 
 * see to the sign by themselves.  
 * 
 * NOTE! Remember to change strerror() if you change this file!
 */ 
Taking this comment at face value, it gives the impression that Linus did in fact use the errno.h file from Minix to construct the Linux 0.01 errno.h file. But do the error names and values match up? By stripping the Minix _SIGN macro and the error comments away using:

    grep define Minix/1.5/errno.h | sed 's/(_SIGN//;s/).*//'
and comparing the results with the Linux 0.01 errno.h kernel, we see that every error definition has the same name and value. The definition of the external variable errno is also identical between the files:

   extern int errno;
Thus there is significant evidence that Linus did refer to the Minix 1.5.10 errno.h file to produce Linux 0.01 errno.h. Let's now examine SCO's assertion that the errno.h file from Linux originated in System V.

Obtaining a copy of System V (binaries or otherwise) has proved to be difficult. However, I have been able to obtain a copy of System V errno.h with this copyright notice:

/*      Copyright (c) 1984, 1986, 1987, 1988, 1989, 1990 AT&T   */ 
/*      All Rights Reserved                                     */
/*      THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T     */
/*      The copyright notice above does not evidence any        */ 
/*      actual or intended publication of such source code.     */ 
#ifndef _SYS_ERRNO_H 
#define _SYS_ERRNO_H 
#ident  "@(#)/usr/include/sys/errno.h.sl 1.1 4.0 10/15/90 58840 AT&T-SF"
/*
 *              PROPRIETARY NOTICE (Combined)  
 *    
 *  This source code is unpublished proprietary information  
 *  constituting, or derived under license from AT&T's Unix(r) System V.  
 *  In addition, portions of such source code were derived from Berkeley  
 *  4.3 BSD under license from the Regents of the University of  
 *  California.  
 *    
 *    
 *    
 *              Copyright Notice   
 *    
 *  Notice of copyright on this source code product does not indicate   
 *  publication.  
 *    
 *      (c) 1986,1987,1988,1989  Sun Microsystems, Inc.  
 *      (c) 1983,1984,1985,1986,1987,1988,1989  AT&T.  
 *                All rights reserved.
 */
The file, with the October 15, 1990 ident stamp is roughly contemporaneous with the first release of Linux. It is interesting that the file has a combined copyright notice from both AT&T and the Regents of the University of California.

The System V errno.h file is wrapped by the C-preprocessor defines

#ifndef _SYS_ERRNO_H 
#define _SYS_ERRNO_H 
...
#endif  /* _SYS_ERRNO_H */
which is similar to Linus' file, but which is also standard C practice to prevent a header file from being included twice into a C program. The System V errno.h file does not have a definition of the errno variable, unlike the Linux and Minix files. Each error definition also has a comment, as does the Minix file, but there are several differences between the System V and Minix comments:

ErrorSystem V CommentMinix 1.5.10 Comment
EPERMNot super-useroperation not permitted
EBADFBad file numberbad file descriptor
ECHILDNo childrenno child process
EAGAINNo more processesresource temporarily unavailable
ENOMEMNot enough corenot enough space
ENOTBLKBlock device requiredExtension: not a block special file
EBUSYMount device busyresource busy
EXDEVCross-device linkimproper link
ENFILEFile table overflowtoo many open files in system
ENOTTYNot a typewriterinappropriate I/O control operation
ETXTBSYText file busyno longer used

There are several more examples of different comments. This indicates that the Minix 1.5.10 errno.h file did not come directly from System V, and the earlier versions of Minix errno.h did not have comments.

Returning to the Linux 0.01 & System V comparison, the error names and values are identical from EPERM up to ERANGE, but then the equivalence breaks down:

ErrorSystem V ValueMinix 1.5.10 ValueLinux 0.01 Value
ERANGE343434
EDEADLK45no value35
ENAMETOOLONG78no value36
ENOLCK46no value37
ENOSYS89no value38
ENOTEMPTY93no value39

The simplest explanation here is that Linus borrowed error names and values from Minix from EPERM up to ERANGE, but Minix did not define errors 35 onwards. As new errors were required in Linux, these were added on an as-required basis, and so the numbers 35 to 39 were allocated. The difference in numbering between Linux 0.01 and System V supports the assertion that Linux 0.01 errno.h came from Minix 1.5.10 and not from System V.

Errno.h in Linux 0.97 Onward

The errno.h file in Linux does not change substantially from 0.01 to 0.96c of the kernel. The definition of ERROR is removed, and three new errors are defined: ELOOP as 40, ERESTARTSYS as 512 and ERESTARTNOINTR as 513.

However, from Linux version 0.97 the file (timestamped July 26 1992) changes significantly. In fact, this has been the only significant change to errno.h, and it remains essentially unchanged from 0.97 through to the 2.4.18 Linux kernel. In the new 0.97 errno.h file, the header comment about Minix _SIGN and the POSIX standard is removed, errors now have comments, and error numbers go from 1 up to 121 (then 512 and 513):

#ifndef _LINUX_ERRNO_H
#define _LINUX_ERRNO_H
#define EPERM            1      /* Operation not permitted */
#define ENOENT           2      /* No such file or directory */
#define ESRCH            3      /* No such process */
#define EINTR            4      /* Interrupted system call */
#define EIO              5      /* I/O error */
#define ENXIO            6      /* No such device or address */
#define E2BIG            7      /* Arg list too long */
#define ENOEXEC          8      /* Exec format error */
#define EBADF            9      /* Bad file number */
#define ECHILD          10      /* No child processes */
...
#define ENAVAIL         119     /* No XENIX semaphores available */
#define EISNAM          120     /* Is a named type file */
#define EREMOTEIO       121     /* Remote I/O error */
/* Should never be seen by user programs */
#define ERESTARTSYS     512
#define ERESTARTNOINTR  513
#endif
The large amount of new error numbers, and the fact that this predates Minix 1.6, strongly suggests that this new file was not derived from Minix. Was it directly derived from System V? Again, the evidence does not suggest so. From error numbers 35 onwards, both the System V and the Linux 0.97 files use different numbers for the same error names. Linux 0.97 has 121 errors; System V has 151 errors. While some error comments are identical apart from letter case, many error comments are different.

Where did the errno.h file for Linux 0.97 originate? The members of the Linux Kernel Archive mailing list searched for the origins of the file, and after some analysis, Linus Torvalds came to the conclusion that the errno.h file was automatically generated from the release of the libc-2.2.2 library that was part of the Gnu C compiler 2.2.2 for Linux (released on July 19 1992). Linus shows that "I can re-create _exactly_ the linux-0.97 "errno.h" file by using the "sys_errlist[]" contents from "libc-2.2.2". In particular, [a] trivial [C program] will generate the exact (byte-for-byte) list that is in the kernel''. Importantly, the regularity of the spacing within the 0.97 errno.h file strongly supports the idea that the file was not written by hand.

The file string/errlist.c from the libc-2.2.2 library has no copyright notice, and begins thus:

#include 
#include 
#include 

/* This is a list of all known signal numbers.  */

CONST char *CONST sys_errlist[] = {
        "Unknown error",                        /* 0 */
        "Operation not permitted",              /* EPERM */
        "No such file or directory",            /* ENOENT */
        "No such process",                      /* ESRCH */
        "Interrupted system call",              /* EINTR */
        "I/O error",                            /* EIO */
        "No such device or address",            /* ENXIO */
        "Arg list too long",                    /* E2BIG */
        "Exec format error",                    /* ENOEXEC */
From all of this analysis, I conclude that the errno.h file in Linux was not copied directly from UNIX System V. Early versions of the file were derived from the Minix source code, and the version of errno.h from Linux 0.97 onwards originated from a file distributed with the Gnu C compiler 2.2.2 for Linux.

Regardless of the origins of the errno.h files in Minix and the Gnu C compiler, it cannot be asserted, in my opinion, that Linus Torvalds or some other person directly copied a System V ABI file into Linux. Nor can it be asserted that Linus Torvalds or some other person removed a copyright notice from a file when the Linux errno.h file was constructed: it has been shown that the Minix errno.h files nor the libc-2.2.2 errlist.c file contained copyright notices.

I'll end with a short comment on this assertion by SCO in their supplemental response:

In 1992, Unix Systems Laboratories (USL), SCO's predecessor in interest, sued Berkeley Software Design, Inc. (BSD) for, among other things, copyright infringement. One of the bases of that action was BSD's copying and distributing some USL UNIX System V files without proper permission or attribution.
Firstly, Berkeley Software Design, Inc. is known by the acronym BSDi; the acronym BSD is reserved for the distributions of code that were released by the University of California, Berkeley. Secondly, SCO is completely wrong when they assert that infringing distribution of System V code was one of the bases of the lawsuit. In fact, nowhere in the court papers is System V even mentioned, except as a product that USL sells. All mention of copyright infringement in the USL vs. BSDi lawsuit relates to the 32V distribution from USL. For this reason, I consciously decided not to discuss BSD code in this article; that's a whole topic for later consideration.

Coming up next: a look at signal.h and the other ABI files.


  


The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society | 355 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
Authored by: rand on Saturday, February 21 2004 @ 08:43 PM EST
Love it. I can't wait for the next installment.

---
carpe ductum -- "Grab the tape" (IANAL and so forth and so on)

[ Reply to This | # ]

The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
Authored by: Rocketman56 on Saturday, February 21 2004 @ 08:50 PM EST
Thanks for the illuminating article..

Looking back at the Earlier (SIII, 32V, V7m, V7, etc.) versions of errno.h,
there is a nice progression that leads to the System V version.

You've shown how errno.h in Linux has a completely different history, even
though the "intent" of the file is similar, based on a Published
Standard..

SCO has gnawed off more than they can swallow with their assertion!

Steve

[ Reply to This | # ]

    errata
    Authored by: Anonymous on Saturday, February 21 2004 @ 08:59 PM EST
    In the following paragraph,
    "The large amount of new error numbers, and the fact that this predates
    Minix 1.6, strongly suggests that this new file was not derived from Minix. Was
    it directly derived from System V? Again, the evidence does not suggest so. From
    error numbers 35 onwards, both the System V and the Minix 0.97 files use
    different numbers for the same error names. Minix 0.97 has 121 errors; System V
    has 151 errors. While some error comments are identical apart from letter case,
    many error comments are different."
    the references "Minix 0.97" should be changed to read "Linux
    0.97"

    [ Reply to This | # ]

    • errata - Authored by: Anonymous on Monday, February 23 2004 @ 12:35 AM EST
    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Saturday, February 21 2004 @ 09:00 PM EST
    Havan't most people here concluded by now that no amount of evidence will
    convince SCO executives to admit that they were wrong? Even if they personally
    conclude we're right and they're wrong, they will never admit it in public. I'm
    still trying to decide if Darl really believes the claims he makes or if he
    knows they're false and continues to lie.

    I wonder if there are consequences they might face like a shareholder lawsuit if
    they continue to intentionally carry on the charade long after they've been
    publically and repeatedly discredited like this.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Saturday, February 21 2004 @ 09:00 PM EST
    Excellent work

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Steve Martin on Saturday, February 21 2004 @ 09:02 PM EST
    I am in awe. A few more of these and The SCO Group will demonstrably have no
    legal leg to stand on. Thanks to Dr. Toomey for this wonderful analysis.


    ---
    "When I say something, I put my name next to it." -- Isaac Jaffee, "Sports
    Night"

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Random BedHead E on Saturday, February 21 2004 @ 09:12 PM EST
    This is the most glorious stuff to read. It pretty clearly shows that Linus had
    no idea what was in POSIX (by way of his comment), and that he therefore had no
    idea what was in UNIX. One of the things I love about this site is that we can
    compare real analyses with the tripe coming from SCO in interviews.

    I think the factual disconnect with SCO is coming from the illusion that they
    are right. They seem to have a very abstract idea that they are correct, and
    their uninformed confidence is causing them to make some huge errors in
    judgement. Perhaps if they stopped acting so smug and did a little research
    they'd either drop their case or show up to court with actual evidence.

    But this would be a lot less fun if they did.

    [ Reply to This | # ]

    But is gcc clean?
    Authored by: mflaster on Saturday, February 21 2004 @ 09:27 PM EST
    Early versions of the file were derived from the Minix source code, and the version of errno.h from Linux 0.97 onwards originated from a file distributed with the Gnu C compiler 2.2.2 for Linux.
    I've asked this before, of PJ and others. I think it's clear that Linux got the errno comments from the output of strerror off of libc 2.2.2.

    But is that sufficient? I mean obviously Linus did nothing wrong. But if this was presented to SCO, wouldn't they just say "Hey, GCC stole our valuable copyrighted ABI files, copied them into the compiler, and stripped the copyrights!" So maybe they'd have to sue somebody else, but that's never bothered them before.

    Is it possible to go the final step, and show that the strings made it into gcc through a legal path? I had proposed e-mailing the maintainer that checked in the changes. I tracked down a recent e-mail address for him, though I don't have it handy.

    Feel free to e-mail me at mflaster_wp at flaster dot net if anyone would like to discuss.

    Mike

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Saturday, February 21 2004 @ 09:27 PM EST
    This is the sort of thing I expected (and I suspect the Rabid Rats of SCO
    expected) when their frothy allegations were exposed to sunlight. To any
    programmer, it is irrefutable, indubitable proof.

    That may not be the same thing as saying it will persuade a jury of non-peers,
    so a handful of Darl's microcephalic cousins from the local electorate may not
    see it the same way. But this, combined with IBM's ability to assume the
    leadership of the U.S. government's legal departments again (as they did during
    the Carter administration when the Federal anti-trust suit against them was
    abandoned) should prove conclusive.

    Put another way, it's nice to know the Nazgul have acquired a taste for roast
    orc.

    [ Reply to This | # ]

    GCC
    Authored by: lpletch on Saturday, February 21 2004 @ 09:29 PM EST
    Okay the file was generated from libc. The next question is where did the info
    in libc used to generate the file come from?

    ---
    lpletch@adelphia.net

    [ Reply to This | # ]

    • GCC - Authored by: DrStupid on Sunday, February 22 2004 @ 10:28 AM EST
    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: sbungay on Saturday, February 21 2004 @ 09:33 PM EST
    Well done... VERY well done. Unfortunately, like many here I don't think SCO
    will ever admit they are in the wrong, I don't think those at the helm are good
    enough people to do so. It takes a mighty good person to admit their mistakes
    and look for no scapegoat, it's far easier to refuse to acknowlege the truth and
    blamethrow.

    ---
    Programmer: A red eyed mumbling mamal that converses with inanimate objects.

    IANAL IAAP

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: rkrishnam_can01 on Saturday, February 21 2004 @ 09:35 PM EST
    Thanks for the great work Dr. Toomey. Apart from bebunking SCO claims, I found
    it very educational.
    I am looking forward to the next installment(s).

    Raja

    [ Reply to This | # ]

    OT - David Berlind at ZDNet
    Authored by: The Mad Hatter r on Saturday, February 21 2004 @ 09:38 PM EST


    I think we mailbombed the poor guy. I got back a VERY long (6 paragraph) form
    letter reply from him. The gist is that all he was trying to do was point out
    that the matter is before the courts, and no one knows which way the courts will
    rule.

    I think he was overwhelmed by all the attention. Let's give him a week or so to
    recuperate <GRIN>.



    ---
    Wayne

    telnet hatter.twgs.org

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: arch_dude on Saturday, February 21 2004 @ 09:45 PM EST
    Brilliant analysis. Thanks.

    We see that Linus created (or could have created) the errno.h in Linux 0.97 from
    the GNU GCC compiler 2.2.2 version of errlist.h

    But where did the GNU GCC compiler get the information in the 2.2.2 version of
    errlist.h? Is there a way to trace this back?

    It's not absolutely essential, of course, since we can use all sorts of good
    arguments both in law and in equity to demonstrate that errno.h cannot belong to
    SCOG. But it would be nice to absolutely destroy SCOG's crazy claim. Ideally, we
    will be able to document a clear chain of development back to a
    pre-Bourne-convention file that did not have a copyright notice.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Saturday, February 21 2004 @ 09:57 PM EST
    I have two books on my shelf which both list the first 34 entries of errno.h :

    The Unix System V Environment, Steven R. Bourne, (C) Bell System Laboratories
    Inc., 1987, ISBN 0-201-18484-2

    and

    System Calls and Library Routines, Unix Programmer's Manual Volume 2, Steven V.
    Earhart, Editor, (C) American Telephone and Telegraph Co., 1986, ISBN
    0-03-009314-7

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Saturday, February 21 2004 @ 10:02 PM EST
    I notice this:

    * (c) 1986,1987,1988,1989 Sun Microsystems, Inc.

    How and where does SUN fit into this mess? And I
    fail to see any copyright attributions to the
    Regents of UCB despite the claim that there is joint
    ATT and UCB copyright claims in the sys V code ...

    anyone care to explain ? TIA

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: chrisbrown on Saturday, February 21 2004 @ 10:02 PM EST

    While I continue to be amazed and heartened by the expert commentary and analysis GROKLAW contributors provide dispelling SCO's FUD and myths, I am further comforted by knowing that IBM, being a UNIX licensee and developer has even more resources and information to crush SCO's arguments. IBM, I am certain, actually knows more about UNIX Sys V than SCO does since their employees and divisions have had far more stability and longevity.

    I look forward with relish the day IBM's case is seen in court.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: seeds on Saturday, February 21 2004 @ 10:16 PM EST
    I'm an old windows, new linux, developer and decided to look back at old M$
    development materials that I have kept. The errno.h from M$ C++ 1.52, file
    copyright 1992, has identical defines up to number 34 and shares def for 36. I
    am not including a copy of the file as it has an M$ copyright notice at the top
    and, as we know, that can have implications.

    Should SCO go after M$? That would be fun to watch! :-)

    [ Reply to This | # ]

    non-i386 is different
    Authored by: Anonymous on Saturday, February 21 2004 @ 10:28 PM EST
    Hey, stop looking at the i386 file.
    Most ABI files come in 3 versions:

    1. Linus himself (used by i386, ppc, sh)
    2. BSD (used by alpha, sparc)
    3. SysV (used by mips)

    This was done for SunOS, OSF/1, and IRIX
    compatibility. Long ago, it was important
    that these ports could run Netscape binaries
    for the platform's native OS.

    [ Reply to This | # ]

    sco reply:
    Authored by: Anonymous on Saturday, February 21 2004 @ 10:49 PM EST
    Expect something along the lines of: "Well, the Linux community is clearly
    against us, and are eager to make up all kinds of half-truths and outright lies.
    We know we are clearly in the right, and they can only conjure up obscure
    theories. In the end we expect to be proven correct by the court of law, where
    we will vigorously prove our assertions. In the meantime, our preparations for
    end-user lawsuits will continue." Steams you up, don't it? One likes to
    think the truth wins out eventually, but in the meantime this is the kind of FUD
    that gets sent out on the newswires (and keeps SCO's stock price artificially
    high), while carefully reasoned analysis like this is completely lost on
    financial analysts and much of the mainstream tech press. Why are these people
    so frigging incompetent?

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: DashEvil on Saturday, February 21 2004 @ 10:51 PM EST
    I'm pretty sure that BSD is an abbriviation, not an acronym. :P Small
    technicality, but okay. :)


    ---
    ---
    yar, SCO be walkin' the plank when we be done with them.

    [ Reply to This | # ]

    Missing less/greater than signs
    Authored by: Xenographic on Saturday, February 21 2004 @ 10:55 PM EST
    It seems that some <s and >s are missing, such as in some of the #includes
    (this is why we don't see the file they include after the #include statement).
    You need to use &gt; and &lt; to display those two chars, respectively.
    The plain old text mode seems to be setting those properly for me, I'm not sure
    what you'll do if you have to work in HTML mode, since the allowed HTML (at
    least for me...) doesn't seem to include those entities.

    [ Reply to This | # ]

    libc 2.2.2 origin?
    Authored by: mobrien_12 on Saturday, February 21 2004 @ 11:17 PM EST
    Wasn't the libc originally used with GCC a BSD library?

    Does this libc file share anything in common with USL UNIX? Can we say without
    a doubt to the most stubborn of SCO supporters that it wasn't from a SYSV
    library and didn't have USL copyrights stripped off?




    [ Reply to This | # ]

    Formatting Error
    Authored by: Anonymous on Saturday, February 21 2004 @ 11:36 PM EST
    #include statements have been mangled.

    It should be #include <something.h> however the <'s and >'s weren't
    escaped. leaving meaningless lines.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: H0B0 on Saturday, February 21 2004 @ 11:50 PM EST
    Thats a nice analysis. But I felt a sense of deja vu upon reading the article
    given I`d read a similar analysis just last night, by an individual named Loren
    Heal who apparently attends the University of Illinois. If you are not already
    familiar with her work, you should visit this person`s site. It is well laid
    out, well written, and informative as regards files, and as regards the various
    'things' called 'UNIX':


    http://healconsulting.com/



    I had posted here on this site expressing a wish to have someone articulate
    exactly what I later found on Loren Heal`s site, namely a breakdown of the
    various things called UNIX, and those files in these court cases relating to
    each of those UNIX 'varities', i.e. where each file in the court cases derives
    from. The individual in question has done an outstanding job of bringing clarity
    to each and every aspect of the case, as per technicalities. Any others who wish
    to write on the technical merits of the various code claims would do well to
    peruse Loren Heal`s site.

    Two pages that are especially worth reading are:

    SCO Timeline
    Commentary on the SCO Dec 19 2003 ABI Files letter


    H0B0

    [ Reply to This | # ]

    OT: Stowell spotted
    Authored by: Anonymous on Saturday, February 21 2004 @ 11:53 PM EST
    http://www.eweek.com/article2/0,4149,1533567,00.asp

    On IBM memo:

    Blake Stowell, director of public relations for the Lindon, Utah based
    companies, said that "both sides are still waiting for the magistrate to
    approve or disapprove the second amendment filing but with this, IBM is helping
    bring the process along."

    On SCO and end-users:

    Meanwhile, SCO is prepping to file charges against a large corporate user of
    Linux.. And the countdown is ticking, according to Stowell. "SCO would
    soon&#8212;[in] days not weeks&#8212;bring suit against a Linux-using
    company," he said.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: JoeMorton on Sunday, February 22 2004 @ 12:08 AM EST
    Did I miss something?

    In Exhibit 1 to IBM's Report on SCO's Compliance, under "SUPPLEMENTAL RESPONSE TO INTERROGATORY NO 12," SCO admits

    ...persons as yet unknown copied these files into Linux...
    just above the list of files starting with linux-2.4.21/include/asm-alpha/errno.h.

    Does this make the whole response irrelevant for the suit against IBM? Or does SCO hope to identify someone at IBM as being responsible with the "catch" from the fishing expedition?

    Either way, this article shoots a lot of holes into the SCO infringement argument for errno.h. Excellent work.

    #include <stddisclaim.h> /* Includes ianal.h */

    [ Reply to This | # ]

    back in 2003.
    Authored by: kberrien on Sunday, February 22 2004 @ 12:38 AM EST
    Remember back in early 2003, when SCO first made its allegations. Show us the
    code, we'll check, and fix it if need be was the reply from the community.

    Of course we really never got the chance, in large part.

    But this article/investigation is exactly what we all wanted to happen many
    months ago, had SCO's motivation not been income, but rather settling a dispute.
    A verifyable claim was made by SCO, and effectively disputed/disproved.

    Slap a Bates numbers on it! Excellent work!

    [ Reply to This | # ]

    Abrupt Transition in article on 'expressive content' not copyrightable
    Authored by: LvilleDebugger on Sunday, February 22 2004 @ 01:18 AM EST
    From the article:

    "The choice of numbers and how they are alloted to the errors is arbitrary
    and without 'expressive content', so the mere facts of what number goes with
    which error cannot normally be copyrighted."

    OK. I believe you. But why. Abrupt transition. Needs a footnote at least to
    flesh out "expressive content."

    (Reserve right to eat my words if author clarifies well later...I'm worried I'll
    forget my critique.)

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Sunday, February 22 2004 @ 01:28 AM EST
    Maybe I missed something along the way. I just don't see why any of
    this might be material info in a case against IBM. SCO argues that IBM
    improperly gave some source code to Linux project. But the errno.h
    file goes back way before IBM contributed anything to Linux.

    We are here discussing, whether Linus got the code from one place or
    another in 1991. Why does this concern the IBM case?

    Secondly, just because SCO has a source file with some copyrights
    listed, they still have to prove they actually own the product. At one
    time, a lot of source code floated freely between Berkeley and AT&T.
    How do we know, this code was actually contributed by AT&T? How do
    we know, this code was not also contributed by Berkeley, then
    "floated" to somebody else, before the two organizations started
    retroactively copyrighting code.

    IBM appears only in the later part of the foodchain. Perhaps SCO
    needs to go back and first sue Berkeley over again.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: ram on Sunday, February 22 2004 @ 01:30 AM EST
    This paper concludes:

    ...it has been shown that the Minix errno.h files nor the libc-2.2.2 errlist.c file contained copyright notices.

    This *should* be written:

    ...it has been shown that neither the Minix errno.h files nor the libc-2.2.2 errlist.c file contained copyright notices.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: blacklight on Sunday, February 22 2004 @ 02:09 AM EST
    The SCO group's coyrights violation allegation is a loser. I see three lines of
    defense: (1) The SCO Group distributed under the GPL the Linux source code
    including the ABI files for years from its own web site. Assuming (and that's
    just that: an assumption) that the SCO Group has valid copyrights over the ABI
    Files, the text of the GPL itself constitutes written permission to distribute,
    reproduce, etc.; (2) the SCO Group's title to the copyrights is in serious doubt
    since Novell (re)-registered for overlapping copyrights; (3) the ABI files are
    not copyrightable.

    The fourth line of defense may very well be that the SCO Group's copyrights do
    not apply to these files, if Dr. Toomey continues on his analysis path. In
    summary, it is no wonder that IBM is not opposing the SCO Group's request to
    amend its complaint. The process is indeed moving along, because the SCO Group
    dropped the trade secret violations like a hot potato, thus validating the
    groklaw community's previous analysis of these allegations.

    [ Reply to This | # ]

    MINIX code declared free of UNIX code.
    Authored by: mobrien_12 on Sunday, February 22 2004 @ 02:12 AM EST

    Just in case anyone asks

    The official MINIX homepage says

    MINIX has been written from scratch, and therefore does not contain any AT&T code--not in the kernel, the compiler, the utilities, or the libraries. For this reason the complete source can be made available (by FTP or via the WWW).

    [ Reply to This | # ]

    What if Darl attacks Minix?
    Authored by: piskozub on Sunday, February 22 2004 @ 03:09 AM EST
    I still wonder if the only (desperate) attact SCO can mount is through Andy
    Tanenbaum (Minix) connection? What I mean are the first 35 error numbers common
    for Unix, Minix and Linux.

    We know they come from ancient Unix which was released to public domain several
    times, but if SCO wants to drag the case in courts and at the same time milk the
    end users, it is the only way can continue.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Vaevictis on Sunday, February 22 2004 @ 03:46 AM EST
    "While some error comments are identical apart from letter case, many error
    comments are different."

    Keep in mind that many of the error comments are DIRECTLY from the IEEE posix
    description of the error. See
    http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html

    It's no coincidence that they're identical -- they're PART of the POSIX
    standard. Keep in mind that the authors of the standard explicitly state that
    they consider it fair use to implement these interfaces, and they have
    permission to use some of the stuff in the standard from such companies as ...
    heh, Novell! :)

    http://www.opengroup.org/austin/papers/posix_faq.html (see question five for
    fair use commentary)
    http://www.opengroup.org/onlinepubs/007904975/copyr.html

    hrmph.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: jmc on Sunday, February 22 2004 @ 04:23 AM EST

    I was going to say "but SCO say that 2.2 kernels and older are OK" and these files (apart from some of the "architecture dependent" ones) are in 2.2 and identical but it noticed that SCO have quietly said now, in Q24 of their FAQ that:

    All commercial users of any version of Linux need an SCO IP License.

    However this page still says

    This new license is called "SCO Intellectual Property License for Linux" and applies to commercial use of the Linux 2.4 and later versions

    SCO couldn't possibly be speaking with a forked tongue here could it? No silly idea shame on me....

    [ Reply to This | # ]

    Is this why SCOG believe they have something on Linus and the ABI?
    Authored by: john_chr on Sunday, February 22 2004 @ 04:26 AM EST
    I have come across something that may be of relevance with respect to SCOG's claims on the ABI and interface files like errno.h.

    Whilst reading the comments recently on the SCOG Lehman letters I recalled something that I recently read in Glyn Moody's book "Rebel Code - Linux and the Open Source Revolution" (published by Penguin Books (somewhat appropriately!), 2001 & 2002 with new postscript, ISBN 0738206709 (well according to Amazon as I could not find the ISBN on the copy I have)) regarding how Linus wrote the initial Posix related constants and definitions. The following quote comes from pp 40-41 of the aforementioned book and concerns events in 1991:

    [start of quote]

    As Linus wrote later in a short history of Linux he put together in 1992, the consequence of these sustained bouts of programming was that "by July 3rd I had started to think about actual user-level things: Some of the device drivers were ready, and the hard disk actually worked. Not too much else." The shift in interest is evident from his next posting to the comp.os.minix newsgroup, on 3 July, where he asked about something called Posix for "a project" - Linux, in other words. He wrote

    Hello netlanders,

    Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules?

    Posix is a standard that defines how programs run on Unix - what Linus referred to as "actual user-level things," rather than system-level - and defines a kind of general Unix compatibility. Posix was drawn up to address the problem of the highly fragmented Unix market that existed at the time where programs running on one flavor of Unix could not run on another. When an operating system follows the Posix specifications it can run any Posix-compliant application.

    Linus explains, "I wanted to know what the standards said about all the interfaces" - the ways programs interact with the kernel - "because I didn't want to port all the programs. Every time that I had a problem porting a program to Linux, I changed Linux so that it would port. I never ported programs, but I ported the kernel to work with the programs." This was the approach that Richard Stallman had adopted for his GNU project, and with the same benefit of ready access to a large base of Unix applications.

    Unfortunately, as Linus recalls, "One of the people who responded to my original query about the Posix standards said 'Sorry, they aren't available electronically, you have to buy them.' That essentially meant that OK, I couldn't afford them." But Linus had another idea: "We had SunOS at the University." SunOS was an early version of Sun's variety of Unix that later became Solaris. "So I used SunOS manual pages to find out the interfaces for stuff."

    [end of quote]

    (emphasis mine)

    The quote is a bit long but I thought it would be best to give a bit more of the context. Looking at Eric Levenez' excellent Unix family tree (www.levenez.com/unix/) it appears that SunOS is primarily an offshoot of 4.1 BSD with the usual periodic tweaks/compatibility alignments/borrowings(?) (I'm not sure what all of Eric's arrows between Unix-like OS flavours implies exactly) from BSD and Unix Sys V along the way. The likely version Linus would have been looking at would have been either SunOS 4.1 (released Mar 1990) or SunOS 4.1.1 (released Nov 1990 - also renamed Solaris 1). SunOS 4.1.2 was released Dec 1991 so that would have been too late given what was said in the quote above occurred in July 1991. It wasn't until July 1992 that Solaris 2 was released that was based mainly on Unix Sys V with elements of BSD-based SunOS included.

    I haven't seen the "short history of Linux" that was written in 1992 to confirm the quote from the book. Unfortunately, Moody does not give any useful references that I could find to this 1992 history that Linus is supposed to have written. There is a whole host of reasons (outlined in previous Groklaw articles and this one) that make SCO's claims very weak, but I couldn't help thinking that the above published quote together with the similar purpose and identical file names giving rise to SCO's view that they still had a problem with Linus' authorship of those files. Looking at SunOS Man pages to glean some of the Posix standard may well be OK (IANAL) - according to Moody's book he didn't say he looked at/copy the actual files directly although IIRC anyone can read those files on a SunOS machine (and indeed on a Solaris machine you still can - I did so on our work Solaris 8 box the other day). Perhaps that is what SCOG is thinking - that if he looked at the Man pages he looked at and copied from the files themselves.

    Can anyone throw any light on Linus' "short history of Linux he put together in 1992"? Is Moody's book just wrong? Does it matter anyway as constants such as in errno.h are covered by Posix and the Single UNIX standard?

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: ra on Sunday, February 22 2004 @ 05:37 AM EST
    I wonder if anyone in this thread can write a three or four paragraph answer to
    the question "Does Linux infringe SCO's copyrights by using "ABI"
    header files?"

    The proto-FAQ I'm working on attempts to address that question but I don't think
    it does a good job yet. I would be very happy to replace the answer I've come
    up with with a better one written by someone who better understands exactly what
    the headers files are, where they come from and how they are used.

    [ Reply to This | # ]

    Keep in mind
    Authored by: Anonymous on Sunday, February 22 2004 @ 07:00 AM EST
    That 32V was released to the world by Caldera(newSCO) themselves, and that 32V
    matched exactly the first 34 variables. It was also noted in the BSDi vs USL
    case that these had been widely distributed WITHOUT a copyright notice and
    therefore fell into the public domain.

    Does anyone else see Darl McBride as Don Quixote, that might be a good lead-in
    for your book PJ;-)

    [ Reply to This | # ]

    OT: The Open Group is a toothless tiger?
    Authored by: belzecue on Sunday, February 22 2004 @ 07:29 AM EST
    This page alone should be grounds enough for the Open Group to force SCO to comply with the terms of use (usage guide) for UNIX branding.

    On this page (and others), SCO states the now familiar line:

    "The SCO® Group, owner of the UNIX® operating system, ..."

    However, Sections 5.5 and 6.4 of the TMLA specify that:

    5.5 The Licensee shall not intentionally, in any written material or otherwise, make any reference to or use of the Trademarks in such a manner as may lead the reader thereof to believe that the Licensee is licensed to apply the Trademarks to any product which is not listed in the Register at the time such reference is made.

    By omitting the productname "SCO" from the statement, SCO is implying that there is a product "the UNIX® operating system". There is no such single product. The correct attribution should be:

    "The SCO® Group, owner of the SCO UNIX® operating system, ..."

    Next...

    6.4 Except as provided in Sub-clause 2.3 or Clause 5, the Licensee shall not make any representation or do any act which may be taken to indicate that it has any right, title, or interest in or to the ownership or use of the Trademarks except under the terms of this Agreement and, subject to Sub-clause 2.3, acknowledges that nothing contained in this Agreement or done pursuant to this Agreement shall give the Licensee any right, title, or interest in or to the Trademarks save as granted hereby. To the extent that any use of the Trademarks by the Licensee in any part of the Territory may result in a development of goodwill in the Trademarks in that part of the Territory, such goodwill shall be held for the benefit of and shall be vested automatically in the proprietor of the registrations.

    By using the statement:

    "UNIX® and UnixWare, used under an exclusive license, are registered trademarks of The Open Group in the United States and other countries."

    SCO implies that the trademark UNIX is licensed exclusively to SCO. That is in direct breach of Section 6.4.

    SCHEDULE 5: TRADEMARK USAGE GUIDE clearly states that:

    2.1 Use in Text and Descriptive Materials

    "Always try to follow the Trademark with the common generic (the dictionary name) of the product:

    [WRONG] UNIX is a ......
    [CORRECT] A UNIX system is a ......

    · Trademarks should be used as adjectives, not as nouns:

    [WRONG] ABC Company’s UNIX
    [CORRECT] ABC Company’s UNIX system"

    ... more grounds for the Open Group to take SCO to task.

    So the question is... why the heck don't they?

    [ Reply to This | # ]

    -so how is this different from the MS leaked code problem?
    Authored by: Anonymous on Sunday, February 22 2004 @ 09:48 AM EST
    I don't know if this is on topic but....

    All the talk is about line-for-line copying of files...

    But that was never talked about with respect to the recently leaked MS code...?
    - in that situation the statements were 'don't even LOOK at the code' or things
    could get complicated.

    So why doesn't the same apply here to the idea of somebody getting 'clues' from
    code and using it...

    - just wondering - appreciate clarification.

    [ Reply to This | # ]

    It's too bad
    Authored by: Anonymous on Sunday, February 22 2004 @ 10:27 AM EST
    To bad there isn't a Groklaw for every publicly traded company. Imagine having
    access to this level of detail on every stock on the board. To much research
    today is just compositing (or should I say composting?) automated information
    gathered from various sources and branding that research. But until you have a
    real person pouring over the data, comparing this and that, the automated
    information resources are largely a waste of time.

    It's also been a real eye-opener about the open source community. I'm 100%
    positive going into this SCO saw OSS/FOSS advocates as a disorganized,
    navel-gazing rabble that lacked both resources and the ability to organize any
    kind of effective defense. It's a pretty safe conclusion that they
    underestimated the sophistication, depth and tenacity of the open source
    movement. Sure there's a lot of squabbling and in-fighting...right up until
    they're attacked. Then they put their differences aside and close ranks on the
    intruder. This has vindicated OSS as both a development strategy and a
    philosophy.

    [ Reply to This | # ]

    POSIX material to be in Linux manpages - official
    Authored by: Anonymous on Sunday, February 22 2004 @ 10:38 AM EST
    IEEE and The Open Group Okay "Linux Manual Pages Project" to Incorporate Material from the POSIX® Standard - which, by an uncanny coincidence, was announced on the same day as this article.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Sunday, February 22 2004 @ 11:29 AM EST
    Errno.h ?

    SCO has no intention of claiming rights to any files. They never did. This is a
    simple pump and dump with statements and public appearances to cover tracks.
    Nothing else. A deep resentment that Linux is making great headway while they
    live in the past with old technology and no understanding of how to improve upon
    it. A technology that is getting harder to sell. SCO is a hollow shell of a
    company living only off FUD and their commitment to not go down without the
    world knowing who they are. Claiming a place in history is their goal. Before
    taking their final dive, they need to make these public statements to claim
    innocence of fraud and wrong doing which will eventually end up an Enron#II.


    They have no proof. They never did. Nor are they going to dig up anything of any
    substance. Simple pump and dump and this will carry on until the law puts a stop
    to it and punishes for the corruption.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: ptb on Sunday, February 22 2004 @ 12:12 PM EST
    I went looking for the source of errno.h myself but you all beat me to it. It's
    a ridiculous idea to claim that the standard unix list of error *names* is
    copyright, and presumably SCO are basing their claim on the internal numbering
    given to those errors at the rhs of the page. But ...

    1) those errors do not match their numbers more than about 50%
    2) numbers are not copyright
    3) anyone can get those numbers by reverse engineering in any bsd unix with a
    printf statement, so I don't see why they think they are copied.
    4) they plainly aren't copied since they often do not match.


    Now - you all have been at work and spotted that errno.h got revamped when
    people started to help linus out. Linus plainly did not copy. The new errno.h
    plainly comes from libc-2.2.2 (NOT gcc - you all led me on a goosechase looking
    at old gcc until I realised it was in libc, not gcc).
    The libc that I can locate is dated in 1993 which about fits.

    [ ] libc.2.2.2.z 06-Jun-1993 18:21 80k

    I can confirm by running strings on this that this contains the errno codes.

    It also contains the following (Berkeley) copyrights:

    @(#)addbytes.c 5.4 (Berkeley) 6/1/90
    @(#)addch.c 5.5 (Berkeley) 6/1/90
    @(#)addstr.c 5.5 (Berkeley) 6/1/90
    @(#)box.c 5.4 (Berkeley) 6/1/90
    @(#)clear.c 5.4 (Berkeley) 6/1/90
    @(#)clrtobot.c 5.5 (Berkeley) 6/1/90
    @(#)clrtoeol.c 5.4 (Berkeley) 6/1/90
    @(#)cr_put.c 5.5 (Berkeley) 6/1/90
    @(#)cr_tty.c 5.8 (Berkeley) 6/1/90
    @(#)curses.c 5.7 (Berkeley) 6/1/90
    @(#)delch.c 5.4 (Berkeley) 6/1/90
    @(#)deleteln.c 5.4 (Berkeley) 6/1/90
    @(#)delwin.c 5.4 (Berkeley) 6/1/90
    @(#)endwin.c 5.4 (Berkeley) 6/1/90
    @(#)erase.c 5.4 (Berkeley) 6/1/90
    @(#)fullname.c 5.4 (Berkeley) 6/1/90
    @(#)getch.c 5.6 (Berkeley) 6/1/90
    @(#)getstr.c 5.4 (Berkeley) 6/1/90
    @(#)id_subwins.c 5.4 (Berkeley) 6/1/90
    @(#)idlok.c 5.4 (Berkeley) 6/1/90
    @(#)initscr.c 5.6 (Berkeley) 3/3/91
    @(#)insch.c 5.4 (Berkeley) 6/1/90
    @(#)insertln.c 5.4 (Berkeley) 6/1/90
    @(#)longname.c 5.4 (Berkeley) 6/1/90
    @(#)move.c 5.5 (Berkeley) 6/1/90
    @(#)mvprintw.c 5.8 (Berkeley) 6/19/91
    @(#)mvscanw.c 5.5 (Berkeley) 4/15/91
    @(#)mvwin.c 5.4 (Berkeley) 6/1/90
    @(#)newwin.c 5.4 (Berkeley) 6/1/90
    @(#)overlay.c 5.6 (Berkeley) 6/1/90
    @(#)overwrite.c 5.4 (Berkeley) 6/1/90
    @(#)printw.c 5.8 (Berkeley) 4/15/91
    @(#)putchar.c 5.4 (Berkeley) 6/1/90
    @(#)refresh.c 5.5 (Berkeley) 3/3/91
    @(#)scanw.c 5.7 (Berkeley) 4/15/91
    @(#)scroll.c 5.4 (Berkeley) 6/1/90
    @(#)standout.c 5.4 (Berkeley) 6/1/90
    @(#)toucholap.c 5.4 (Berkeley) 6/1/90
    @(#)touchwin.c 5.4 (Berkeley) 6/1/90
    @(#)tstp.c 5.6 (Berkeley) 3/3/91
    @(#)unctrl.c 5.4 (Berkeley) 6/1/90


    but of course the headers do not persist into the binary. People are currently
    looking for source code for this old library.

    What I can see is that it contains code from as early as Feb 28 1991:

    gdbm fatal: %s.
    This is GDBM version 1.5, as of February 28, 1991.
    kC-*.g
    @(#)tzfile.h 7.1
    UFC-crypt, patchlevel 1a, @(#)patchlevel.h 1.6 01/31/92


    So doesn't this predate any sysv code? It's all Berkeley
    as far as I can see!

    Oh, if you want to see the syserr table, it looks like this in the binary:

    Unknown error
    Operation not permitted
    No such file or directory
    No such process
    Interrupted system call
    I/O error
    No such device or address
    Arg list too long
    Exec format error
    Bad file number
    No child processes
    Try again
    Out of memory
    Permission denied
    Bad address
    Block device required
    Device or resource busy
    File exists
    Cross-device link
    No such device
    Not a directory
    Is a directory
    Invalid argument
    File table overflow
    Too many open files
    Not a typewriter
    Text file busy
    File too large
    No space left on device
    Illegal seek
    Read-only file system
    Too many links
    Broken pipe
    Math argument out of domain of func
    Math result not representable
    Resource deadlock would occur
    File name too long
    No record locks available
    Function not implemented
    Directory not empty
    Too many symbolic links encountered
    Operation would block
    No message of desired type
    Identifier removed
    Channel number out of range
    Level 2 not synchronized
    Level 3 halted
    Level 3 reset
    Link number out of range
    Protocol driver not attached
    No CSI structure available
    Level 2 halted
    Invalid exchange
    Invalid request descriptor
    Exchange full
    No anode
    Invalid request code
    Invalid slot
    File locking deadlock error
    Bad font file format
    Device not a stream
    No data available
    Timer expired
    Out of streams resources
    Machine is not on the network
    Package not installed
    Object is remote
    Link has been severed
    Advertise error
    Srmount error
    Communication error on send
    Protocol error
    Multihop attempted
    RFS specific error
    Not a data message
    Value too large for defined data type
    Name not unique on network
    File descriptor in bad state
    Remote address changed
    Can not access a needed shared library
    Accessing a corrupted shared library
    .lib section in a.out corrupted
    Attempting to link in too many shared libraries
    Cannot exec a shared library directly
    Illegal byte sequence
    Interrupted system call should be restarted
    Streams pipe error
    Too many users
    Socket operation on non-socket
    Destination address required
    Message too long
    Protocol wrong type for socket
    Protocol not available
    Protocol not supported
    Socket type not supported
    Operation not supported on transport endpoint
    Protocol family not supported
    Address family not supported by protocol
    Address already in use
    Cannot assign requested address
    Network is down
    Network is unreachable
    Network dropped connection because of reset
    Software caused connection abort
    Connection reset by peer
    No buffer space available
    Transport endpoint is already connected
    Transport endpoint is not connected
    Cannot send after transport endpoint shutdown
    Too many references: cannot splice
    Connection timed out
    Connection refused
    Host is down
    No route to host
    Operation already in progress
    Operation now in progress
    Stale NFS file handle
    Structure needs cleaning
    Not a XENIX named type file
    No XENIX semaphores available
    Is a named type file
    Remote I/O error

    From which you can at least deduce the likely ordering
    as written in the code.

    Linus is on the job too:

    ========================

    Home Weekly edition Kernel Security Distributions
    Archives Search Penguin Gallery Calendar LWN.net FAQ
    Subscriptions Advertise Write for LWN Contact us Privacy

    Re: SCO's infringing files list

    From: Linus Torvalds <torvalds-AT-osdl.org>
    To: Mitchell Blank Jr <mitch-AT-sfgoth.com>
    Subject: Re: SCO's infringing files list
    Date: Tue, 23 Dec 2003 09:25:53 -0800 (PST)
    Cc: "Giacomo A. Catenazzi" <cate-AT-pixelized.ch>,
    "linux-kernel-AT-vger.kernel.org"
    <linux-kernel-AT-vger.kernel.org>, "Eric S. Raymond"
    <esr-AT-thyrsus.com>

    Bingo!

    On Tue, 23 Dec 2003, Mitchell Blank Jr wrote:
    >
    > This does seem to be the case - from an FAQ that H J Lu posted about that
    time:
    >
    > | From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
    > | Subject: FAQ about gcc (how to compile program under Linux)
    > | Date: Sun, 19 Jul 92 06:40:05 GMT
    > | [...]
    > | Another file, XXXXinc.tar.Z, where XXXX is the current version number
    > | of Linux kernel, has all the header files to replace the header files
    > | from kernel. YOU MUST INSTALL IT. Please read README for details.

    Ok, this is the source.

    In particular, I can re-create _exactly_ the linux-0.97 "errno.h" file
    by
    using the "sys_errlist[]" contents from "libc-2.2.2". In
    particular, this
    trivial loop will generate the exact (byte-for-byte) list that is in the
    kernel:

    int i;

    for (i = 1; i < 122; i++) {
    const char *name = names[i];
    int n = strlen(name);
    char *tabs = "tt"+(n > 7);
    const char *expl = libc222_errlist[i];
    printf("#definet%s%s%2dt/* %s */n",
    name, tabs, i, expl);
    }

    here, the "names[]" array was filled in with the error names, ie

    const char *names[] = { "none",
    "EPERM", "ENOENT", "ESRCH", "EINTR",
    "EIO", "ENXIO", "E2BIG",
    ...

    and the "libc222_errlist[]" array was filled in with the strings found
    by
    just downloading the old "libc-2.2.2" binary that can still be found
    at

    http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/

    and then just doing a "strings - libc-2.2.2" and
    "sys_errlist[]" will be
    obvious:

    static char *libc222_errlist[] = {
    "Unknown error",
    "Operation not permitted",
    ...

    This was literally a five-minute hack (I wrote the silly loop yesterday to
    see what it does with the current "strerror()" - there is very good
    correlation even today, but using the libc-2.2.2 sys_nerrlist[] you get
    _exactly_ the same result).

    So this is definitely the source of the kernel error header. It's either a
    file from the libc sources, or it is literally auto-generated like the
    above (I actually suspect the latter - now that I did the auto-generation
    it all felt very familiar, but that may just be my brain rationalizing
    things. Humans are good at rationalizing reality.).

    Can anybody find the actual libc _sources_? Not the kernel headers that
    hjl mentions (those are the old ones from _before_ the change), but the
    file "libc-2.2.2.tar.Z"?

    Anyway, we know where the kernel header comes from. Let's figure out where
    the libc data comes from.

    Linus



    ===========================

    So he also concludes that libc-2.2.2 is what people have to look for the source
    to.

    I didn't find it. I may have an aout machine at home that I can look at.



    ---
    PTB

    [ Reply to This | # ]

    Proofreading (minor)
    Authored by: Anonymous on Sunday, February 22 2004 @ 12:56 PM EST
    From the "Conclusions" section:

    "...it has been shown that neither the Minix errno.h files nor the libc-2.2.2 errlist.c file contained copyright notices."

    [ Reply to This | # ]

    OT: What SCO does for R&R
    Authored by: crythias on Sunday, February 22 2004 @ 01:04 PM EST
    Because I don't have permission or am too lazy for a direct link, I'll just point to a google search, and leave it as a task for the reader to figure out what this post is regarding.

    Apologies in advance to PETA, the ASPCA, and, of course, Tux fans everywhere.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Sunday, February 22 2004 @ 01:17 PM EST
    I'm sorry, but no one seems to be commenting on what
    annoys me most about this. What do errno values
    matter? Is this "copied technology"? Are these
    valuable secret techniques and code that Linux
    could not have developed by themselves?? How can
    they possibly be saying that? Linus had a choice
    of what numbers to use. It could have been
    arbitrary!!! Picking a number for a list of names,
    for crying out loud. I think all of us reach that
    level of ability by age 6.

    How does this make Linux faster, better in any
    way shape or form? What has it got to do with
    anything?? Generally, isn't the point of copying
    technology or code to acquire something you would
    not have been able to do by yourself (at least
    without some effort)???

    jrg

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Sunday, February 22 2004 @ 02:46 PM EST
    I followed "The Unix Heritage Society" link in the main article above
    and was fascinated to see "Other Web Pages/Dennis Ritchie's Home
    Page". http://cm.bell-labs.com/who/dmr/index.htm

    I went there and found, from Dennis Ritchie himself:-

    "NEW - Some court papers from the lawsuit brought by USL against BSDI,
    then the University of California, in the early 1990s about Unix intellectual
    property. These may be relevant today in view of SCO's recent actions. "
    at

    http://cm.bell-labs.com/cm/cs/who/dmr/bsdi/bsdisuit.html

    Don't know how new this is. Apologies if I'm duplicating what has already been
    covered.

    [ Reply to This | # ]

    The SCOG has done a professional job of researching UNIX history
    Authored by: Anonymous on Sunday, February 22 2004 @ 02:49 PM EST
    Know your opponent!

    The SCOG does not try to say anything useful. Yet, indicators do arise on
    occasion to show that the SCOG and their allies apply all the history of SW IP,

    UNIX in particular.

    Groklaw is usually playing catch-up. However, Groklaw's Internet environment
    allows our community to catch up very quickly. This is a great way to catch
    the bad guys in the act.


    In 1983, DEC, IBM, and AT&T corporate staff were reacting to the upcoming
    first vote on POSIX. I thought that these large corporations were very
    concerned that the C language, C runtime environment, and the UNIX API
    were actually being standardized. No one could know the impact on the
    stakeholders. This was the harbinger of a revised business model.

    I observed DEC making directed threats at individuals. They would be
    ridiculed and lose opportunities for graduate funding and jobs. DEC stated
    that the POSIX API would fail as an engineering standard and be seen as folly.

    I observed IBM making general claims that IBM would ignore POSIX and define
    their own standards. IBM has created many de facto standards and also
    embraced POSIX.

    I observed AT&T making legal claims that AT&T's IP prevented anyone from

    actually creating POSIX compliant software. AT&T waved the threat of their
    ABI based IP and trade secrets.

    The POSIX committee, IEEE, and ANSI also observed and reacted.

    My points:
    1) SCOG knows the legal history and actively diverts their foes through
    misdirection.
    2) In the past, AT&T, and other companies with IP, have found attacking the

    tool chain to be their optimum legal attack. Claiming part of the API as the
    ABI is a clear signal of this attack.
    3) There is a family of official standards that depend on each other for the
    complete API.
    4) The standards groups, IEEE, ANSI, and others have dealt with these attacks
    in the past.
    5) SCOG plans to fight this to their demise.
    6) The last time a CEO of an IT firm really believed selling OSs is like selling

    bottled water, his name was John Sculley and he would have sunk his
    company if the Board had not kicked him out.

    SCOG continues hunting for weakness. The captive IT press continues
    publishing FUD as cover. The judges are deciding the basis for a trial.

    Groklaw keeps uncovering the truth. I want to be part of this team!

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Sunday, February 22 2004 @ 04:19 PM EST
    Importantly, the regularity of the spacing within the 0.97 errno.h file strongly supports the idea that the file was not written by hand.

    I call B******T on this one. I mean come on. We all have modern text editors and when you're putting something into a distribution you make the format nice if you want to be able to maintain it later.

    That one line is just stupid and should be left out of the argument.

    [ Reply to This | # ]

    History is perserved, and looked at!
    Authored by: farrellj on Sunday, February 22 2004 @ 04:25 PM EST
    There are very few good results of the SCO Fiasco...but one of them is the fact
    that both Linux's and Unix's history is being dug up, examined, and because of
    that, preserved. As pervasive as MS operating systems are, far more of our
    Planet's infrastructure runs on Unix and Unix-like operating systems, and like
    the piping of water into a Roman City is studied today, so to can the Unix &
    Co infrastructure be looked at hundreds of years from now to gain insite into
    our civilization. I think that is important.

    ttyl
    Farrell

    [ Reply to This | # ]

    OT: SCO is now selling the Linux IP licenses online
    Authored by: Anonymous on Sunday, February 22 2004 @ 04:32 PM EST
    Here is the link http://www.thesco group.com/scosource/linuxlicense.html

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: zjimward on Sunday, February 22 2004 @ 04:41 PM EST

    I'm under the impression that SCO will just respond to this as code which has
    been "munged around solely for the purpose of hiding the authorship or
    origin of the code." How do you prove that this is not the case? SCO wants
    the right, like other software companies, to say that not only can't you write
    the code like the original, but you can't write it in another way because that
    breaks our intellectual property. The DMCA law has done away with reverse
    engineering. The same as it was wrong to descrable the CSS code. Where will it
    stop?

    [ Reply to This | # ]

    Was Eric's timeline the trigger for SCO's legal crusade?
    Authored by: Anonymous on Sunday, February 22 2004 @ 04:58 PM EST

    Maybe others on Groklaw have spotted this, but if so I couldn't find it.

    There's an ZDNet interview with Darl McBride at Caldera GeoFORUM Las Vegas in 8/02, just after he became CEO. In it he says "... the intellectual properties that we hold--we own SVRx, UnixWare, SCO Unix--in terms of the Unix timeline, the thread that runs through the middle of these is really SVRx. All of the subsequent Unix licensing that happened broke off from that. We own all that intellectual property ...".

    And on Eric's site there's a picture (scroll down to see it) of Darl holding up the timeline on stage at GeoFORUM. He obviously thought it was important, and of course the one on the SCO website is a mutilated version.

    I just wonder if it was Eric's timeline, with the suggestive links from UNIX TSS 7 to MINIX to LINUX, and showing links from AIX and BSD to Linux, that got McBride started on this whole scheme. You can just imagine him arriving at SCO, seeing the chart on some geekwall, and saying "holy s**t - do you realise what this means!". And the rest, as they say, is history.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Sunday, February 22 2004 @ 05:24 PM EST
    May I suggest that we stop treating SCO’s header files as if they don’t have
    anything copied from earlier public versions of the files. I suspect that if we
    DIFF those files with the older files we will find that large parts of them are
    indeed copies of the earlier works. This being the case an argument can be made
    that SCO is trying to re-copyright them. As this type of file changes very
    slowly I wouldn’t be surprised that there is very little difference between
    them.
    IANAL
    bobm

    [ Reply to This | # ]

    Attention PJ -- Correction needed
    Authored by: johan on Sunday, February 22 2004 @ 06:17 PM EST
    The sequence:

    #include
    #include
    #include

    Should most likely be:

    #include <???>
    #include <???>
    #include <???>

    (where ??? stands for some header file).

    I suspect that the '<' and '>' didn't get quoted properly.

    [ Reply to This | # ]

    Lack of due diligence
    Authored by: Anonymous on Sunday, February 22 2004 @ 07:09 PM EST
    Quoting from the Australia (next) article:

    11 SCO's explanation is far from clear: "During the period that SCO distributed Linux, SCO was unaware of the copyright violations. Copyrights cannot be given up by unintentional or llegal inclusion in a GPL product. The owner of the copyrights must transfer the copyrights in writing, which SCO has never done." Response to question 5 of http://www.thescogroup.com/scosource/linuxqanda.html

    This needs to be addressed, and might well render the whole issue of history moot. Licensing under the GPL does not transfer the ownership of the copyright, so the rules requiring explicit written transfer of copyright don't apply. I haven't seen too much commentary on this point, but it may be of some importance, since it reduces the scope of this issue.

    SCO is basically stating that they didn't do their due diligence on their Linux product line by not determining that there was encumbered material within the kernel. This isn't a mere technicality, or in some obscure area of the kernel that nobody thought to look in until somebody had to go off and fix a bug. errno.h is among the most visible of all kernel files, since it's a header file that's exported to user space, and it's probably one of the most commonly referenced header files that's shared between user and kernel space. So if SCO did any system programming at all, they would have had reason to review it.

    Surely Caldera's Lizard installation program -- which presumably they wrote themselves -- had to check error status many times, since a key function of this program is to probe for hardware, which involves making calls into the kernel and checking return status. Almost certainly at least one of these involves a Linux-specific ioctl() or the like that could return an error status that matters, and in the process of development or debugging at least one SCO programmer would need to refer to errno.h. So almost certainly at least one SCO engineer should have been able to see that there was something wrong with this file.

    More generally, the programmers who wrote Lizard and any other software developed by Caldera knew that they were coding to a UNIX-like API, and if Caldera/SCO believed that there were any issues, they could have raised them at the time.

    Another file that is likely even more damning to SCO is signal.h (SCO lists the asm-*/signal.h files). A lot of shell (in particular) programmers are lazy and use the numeric constants (e. g. kill -9) rather than the symbolic names (kill -KILL). If anyone can find even one shell script written by Caldera that uses a numeric signal argument to the 'kill' command, that would constitute proof that Caldera knew that Linux was using the same signal numbers as UNIX, and chose not to object at the time.

    What's interesting about all of this is that the only material that SCO claims to be in violation that is even potentially a copyright violation (as opposed to violation of contract terms, which would presumably have different implications for third parties) is errno.h, signal.h, stat.h, ctype.h, ioctl.h, ioctls.h, ipc.h, acct.h, and ctype.c. With the exception of the last three, all of these are files that any system programmer (and many application programmers) would routinely reference in the writing of just about any UNIX application. Perhaps we can demonstrate that Caldera/SCO surely would have seen this material from the very start of their Linux work, and didn't have any problem with it at the time.

    The implication is that even if SCO holds the copyright to these files, they knowingly or negligently failed to enforce their copyrights for many years, and are now exposing the company to costly litigation with no assurance of success in order to stuff the genie back into the bottle. Would this lack of even the most basic due diligence be grounds for a shareholder lawsuit on the one hand or being unable to enforce their copyright on the other?

    -Robert Krawitz rlk@alum.mit.edu

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: utahbob55 on Sunday, February 22 2004 @ 10:35 PM EST
    Thanks!

    That was a very helpful explanation. I was a bit confused as well.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Monday, February 23 2004 @ 01:03 AM EST
    What is this "Errno.h"? It's "errno.h", dammit.

    --mbp

    [ Reply to This | # ]

    Arbitrary nums and dubious copyright theory
    Authored by: Anonymous on Monday, February 23 2004 @ 03:08 AM EST
    Nice research! Dr. Toomey's article was excellent. Thanks to Dr. Toomey and PJ for posting it.

    However I wonder about some of the copyright theories being proposed in the discussion. IANAL and I'll be the first to admit I don't have all the answers. But this doesn't mean I will agree to anything just because it helps bring down SCO. One important source of strange opinions is the term "arbitrary".

    I find the theory that a numbering scheme cannot be protectible expression to be unconvincing. Clearly not all courts find tables of values (eg Huffman tables) to be unprotectable. The arbitrariness is exactly the thing that allows for protectible expression. If numbering schemes were NOT arbitrary (they had to conform to a published standard, for example), then any text making the necessary assignments would "merge" with the idea. The doctrine of merger would thus apply. However if its arbitrary, the creative author has room to create.

    If one comes up with a creative way of numbering error flags, it seems not unreasonable to claim this could be protectible expression. For example, if one creatively groups the error numbering such that bit operations quickly cluster interesting groups for testing, then this is a creative assignment of numberings. Look, for example, at the ERESTARTSYS and up flags: the 9th bit appears to be used as a flag. This is NOT arbitrary. Perhaps the history of the error numbers clears Linux, but the legal theory that arbitrary number assignments aren't protectible does not (IMO and IANAL) do this.

    A second issue is the questionable idea that SCO should be going after Minix if Linux copied from Minix. It looks like Minix is in the clear, but assume someone copied from System V, perhaps by finding one of the "liberated" System V files and copying portions of it into somewhere (even Free BSD). Then even if someone else is the "original" infringer, it doesn't necessarily mean that Linux isn't infringing too, right? If Bob copies from Mary and Sammy copies from Bob, Mary can still sue Sammy, right? I mean, maybe Mary sues Bob also, but Sammy's not in the clear, right? Clarification by a lawyer (or someone genuinely knowledgable) would help here.

    In the subsequent article, perhaps Dr. Toomey or others can clarify whether the derivation history of the later 2.4 errno.h clears all copyright infringement issues. I think it can be said that there has been no direct copying, but the current article leaves open the question of indirect copying (as the libc discussion indicates). I'm wondering if the history can show that the numbering scheme turns out to be, when not independent, reverse engineered in a clean manner.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: lordmhoram on Monday, February 23 2004 @ 08:39 AM EST
    Just one small point of order (apologies if someone else has already drawn
    attention to it.)

    "The Minix operating system, version 1.1, was released by Andy Tanenbaum
    and Prentice-Hall around 1987 as a book and an accompanying set of floppy
    disks."

    As I recall, in the first versions, the system on a set of floppies was
    available as an extra to the book at quite a substantial further price (I
    remember it put me off buying it at the time.) It was only later that Tanenbaum
    decided to release the system on CD with the book itself.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: pooky on Monday, February 23 2004 @ 10:47 AM EST
    I am not really a programmer these days and I do not claim to know a great
    detail about the history of UNIX, so this may be a very uninformed question.

    It would seem from everything above to conclude that the 1st 34 errors in Linux
    and Unix (and Minix) are all substantially identical. Same codes, same numbers.
    That suggests to ME that they all derive from the same source, something created
    in or before 1990. Possibly is the source of this section 32V? and if so, how
    can SCO possibly hold claim over this section of code, if 32V is the source
    reference, since 32V, AFAIK, was moved into the realm of the public a loooooong
    time ago?

    -pooky

    ---
    Veni, vidi, velcro.
    "I came, I saw, I stuck around."

    [ Reply to This | # ]

    The first 34 error codes
    Authored by: Anonymous on Monday, February 23 2004 @ 05:51 PM EST
    The first 34 error codes where already present in system 7 (dated 1979 on Eric's timeline). If you look on Dennis Ritchie's home page there is a link to system 7 man pages, one of which is intro.2. In this manual page, you can find the definition of the 34 error code (plus 0 which is not an error). These error code, including the error message, match the 34 first error codes of linux-0.97 except for 1, 10-12, 16 and 33-34 where the error message changes but neither the name nor the number of the error. You can test for yourself everything is publicly available. Observe that the information is available to anybody but not in the form of a header (so that it is not copyrightable for use in a header). (Observe also that a header, as already stated more than enough times, is not copyrightable)

    Loïc

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: zjimward on Monday, February 23 2004 @ 07:37 PM EST

    Yes, but 321 Studio was ordered today by a federal judge to stop selling
    software that can crack DVD anti-piracy code, allowing users to make copies of
    DVDs. The ruling is a huge win for Hollywood studios, and 321 Studios is vowing
    to appeal. The judge has given the company seven days to pull its software off
    store shelves. This just proves that many companies, SCO, RIAA, MPAA are going
    to try and define it to limit competition.

    [ Reply to This | # ]

    The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society
    Authored by: Anonymous on Thursday, March 04 2004 @ 05:51 AM EST
    Comment on "errno.h" attributed to Linus Torvalds:

    /*
    * ok, as I hadn't got any other source of information about
    * possible error numbers, I was forced to use the same numbers
    * as minix.
    * Hopefully these are posix or something. I wouldn't know (and posix
    * isn't telling me - they want $$$ for their f***ing standard).
    *
    * We don't use the _SIGN cludge of minix, so kernel returns must
    * see to the sign by themselves.
    *
    * NOTE! Remember to change strerror() if you change this file!
    */

    Source (reliability unknown):
    http://www.mentalhygiene.com/kernelnotes.html

    [ Reply to This | # ]

    Minor typo (HTML trouble)
    Authored by: Anonymous on Thursday, March 11 2004 @ 05:33 AM EST
    discussing string/errlist.c, you include a slice of code from that file; which
    begins with three # include directives; but, of course, the <...> wrapping
    the file names cause them to be read as HTML tags, which aren't recognised as
    anything, so the filenames aren't displayed. You need to use &lt; and
    &gt; to wrap the file names.

    [ Reply to This | # ]

    Groklaw © Copyright 2003-2013 Pamela Jones.
    All trademarks and copyrights on this page are owned by their respective owners.
    Comments are owned by the individual posters.

    PJ's articles are licensed under a Creative Commons License. ( Details )