|
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:
Error | System V Comment | Minix 1.5.10 Comment |
| EPERM | Not super-user | operation not permitted |
EBADF | Bad file number | bad file descriptor |
ECHILD | No children | no child process |
EAGAIN | No more processes | resource temporarily unavailable |
ENOMEM | Not enough core | not enough space |
ENOTBLK | Block device required | Extension: not a block special file |
EBUSY | Mount device busy | resource busy |
EXDEV | Cross-device link | improper link |
ENFILE | File table overflow | too many open files in system |
ENOTTY | Not a typewriter | inappropriate I/O control operation |
ETXTBSY | Text file busy | no 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:
Error | System V Value | Minix 1.5.10 Value | Linux 0.01 Value |
| ERANGE | 34 | 34 | 34 |
EDEADLK | 45 | no value | 35 |
ENAMETOOLONG | 78 | no value | 36 |
ENOLCK | 46 | no value | 37 |
ENOSYS | 89 | no value | 38 |
ENOTEMPTY | 93 | no value | 39 |
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.
|
|
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 | # ]
|
|
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 | # ]
|
|
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
|
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 | # ]
|
|
Authored by: Anonymous on Saturday, February 21 2004 @ 09:00 PM EST |
Excellent work [ Reply to This | # ]
|
|
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 | # ]
|
- ENOTTY - Authored by: Anonymous on Saturday, February 21 2004 @ 09:25 PM EST
- ENOTTY - Authored by: Anonymous on Saturday, February 21 2004 @ 09:32 PM EST
- ENOTTY - Authored by: Anonymous on Saturday, February 21 2004 @ 09:35 PM EST
- ENOTTY - Authored by: dkpatrick on Saturday, February 21 2004 @ 09:45 PM EST
- ENOTTY - Authored by: DannyB on Sunday, February 22 2004 @ 03:08 PM EST
- What's your point? - Authored by: Anonymous on Sunday, February 22 2004 @ 12:35 AM EST
- ENOTTY - Authored by: DrStupid on Sunday, February 22 2004 @ 09:11 AM EST
- ENOTTY - Authored by: PJ on Saturday, February 21 2004 @ 09:44 PM EST
- ENOTTY - Authored by: MaxiCat_42 on Sunday, February 22 2004 @ 12:09 AM EST
- ENOTTY - Authored by: MaxiCat_42 on Sunday, February 22 2004 @ 12:10 AM EST
- ENOTTY - Authored by: RevSmiley on Sunday, February 22 2004 @ 12:40 AM EST
- OT: ENOTTY - Authored by: johan on Sunday, February 22 2004 @ 01:46 PM EST
- ENOTTY - Authored by: cmcnabb on Monday, February 23 2004 @ 01:30 PM EST
- ENOTTY - Authored by: codermotor on Sunday, February 22 2004 @ 02:02 AM EST
- ENOTTY - Authored by: Anonymous on Sunday, February 22 2004 @ 03:24 PM EST
- ENOTTY - Authored by: iMeowbot on Saturday, February 21 2004 @ 10:23 PM EST
- ENOTTY - Authored by: Anonymous on Saturday, February 21 2004 @ 10:28 PM EST
- As time approaches infinity - Authored by: Anonymous on Saturday, February 21 2004 @ 11:32 PM EST
- The (in)famous "Not a typewriter" - Authored by: bmcmahon on Sunday, February 22 2004 @ 02:36 AM EST
- ENOTTY - Authored by: Anonymous on Sunday, February 22 2004 @ 03:52 AM EST
- ENOTTY - Authored by: DrStupid on Sunday, February 22 2004 @ 09:03 AM EST
- ENOTTY - Authored by: Anonymous on Sunday, February 22 2004 @ 10:44 AM EST
- ENOTTY - Authored by: Anonymous on Sunday, February 22 2004 @ 11:37 AM EST
- ENOTTY Summary - 26 ways to sundown - Authored by: Anonymous on Monday, February 23 2004 @ 10:18 AM EST
- ENOTTY - Authored by: Anonymous on Monday, February 23 2004 @ 12:44 PM EST
- A few more of these? - Authored by: om1er on Sunday, February 22 2004 @ 09:33 AM EST
|
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 | # ]
|
|
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 | # ]
|
- But is gcc clean? - Authored by: PJ on Saturday, February 21 2004 @ 09:43 PM EST
- exactly .. - Authored by: pdalton on Saturday, February 21 2004 @ 11:16 PM EST
- exactly .. - Authored by: RealProgrammer on Saturday, February 21 2004 @ 11:39 PM EST
- exactly .. - Authored by: Anonymous on Sunday, February 22 2004 @ 05:48 AM EST
- exactly .. - Authored by: Anonymous on Sunday, February 22 2004 @ 08:00 AM EST
- exactly .. - Authored by: Anonymous on Sunday, February 22 2004 @ 02:39 PM EST
- exactly .. - Authored by: rand on Sunday, February 22 2004 @ 06:06 PM EST
- exactly .. - Authored by: Anonymous on Sunday, February 22 2004 @ 07:02 AM EST
- exactly .. - Authored by: Anonymous on Sunday, February 22 2004 @ 08:58 AM EST
- exactly .. - Authored by: DrStupid on Sunday, February 22 2004 @ 09:34 AM EST
- But is gcc clean? - Authored by: RealProgrammer on Saturday, February 21 2004 @ 11:22 PM EST
- But is gcc clean? - Authored by: k12linux on Sunday, February 22 2004 @ 01:08 AM EST
- Implications of questioning gcc - Authored by: Anonymous on Sunday, February 22 2004 @ 01:26 AM EST
- Bombing Pearl Harbor - Authored by: Anonymous on Sunday, February 22 2004 @ 03:35 AM EST
- But is gcc clean? - Authored by: meke on Sunday, February 22 2004 @ 06:56 AM EST
- But is gcc clean? - Authored by: Anonymous on Sunday, February 22 2004 @ 07:04 AM EST
- Comparing SysV errno.h vs. Linux - Authored by: mflaster on Sunday, February 22 2004 @ 08:22 AM EST
- In any case it has nothing to do with IBM. They have to sue FSF for that. - Authored by: Anonymous on Sunday, February 22 2004 @ 10:31 AM EST
- But is SysV clean? [Irony] - Authored by: Anonymous on Sunday, February 22 2004 @ 02:01 PM EST
|
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 | # ]
|
|
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
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
- sco reply: - Authored by: josmith42 on Saturday, February 21 2004 @ 11:26 PM EST
- class action - Authored by: Anonymous on Sunday, February 22 2004 @ 12:22 AM EST
- class action - Authored by: Anonymous on Sunday, February 22 2004 @ 01:04 AM EST
- class action - Authored by: PJ on Sunday, February 22 2004 @ 03:44 AM EST
|
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 | # ]
|
|
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 > and < 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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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—[in] days not weeks—bring suit against a Linux-using
company," he said. [ Reply to This | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
- The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society - Authored by: Anonymous on Sunday, February 22 2004 @ 05:03 PM EST
- No - Authored by: Jack Hughes on Sunday, February 22 2004 @ 05:09 PM EST
- The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society - Authored by: pogson on Sunday, February 22 2004 @ 05:26 PM EST
- The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society - Authored by: Jude on Sunday, February 22 2004 @ 06:34 PM EST
- The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society - Authored by: Alastair on Sunday, February 22 2004 @ 07:26 PM EST
- The ABI Files: More on Errno.h -- by Warren Toomey, UNIX Heritage Society - Authored by: Anonymous on Monday, February 23 2004 @ 03:29 AM EST
- 'Bullshit'? 'Stupid'? - Authored by: aug24 on Monday, February 23 2004 @ 07:33 AM EST
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 | # ]
|
|
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 < and
> to wrap the file names.[ Reply to This | # ]
|
|
|
|
|