SCO's infringing files list

SCO's infringing files list

[Stan Bubrouski]

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

Guys,

According to the totally inept, idiotic, SCO group, these files are
copyrighted by them (and recently by Novell I might add):

include/asm-alpha/errno.h 

include/asm-arm/errno.h 

include/asm-cris/errno.h 

include/asm-i386/errno.h 

include/asm-ia64/errno.h 

include/asm-m68k/errno.h 

include/asm-mips/errno.h 

include/asm-mips64/errno.h 

include/asm-parisc/errno.h 

include/asm-ppc/errno.h 

include/asm-ppc64/errno.h 

include/asm-s390/errno.h 

include/asm-s390x/errno.h 

include/asm-sh/errno.h 

include/asm-sparc/errno.h 

include/asm-sparc64/errno.h 

include/asm-x86_64/errno.h 

include/asm-alpha/signal.h 

include/asm-arm/signal.h 

include/asm-cris/signal.h 

include/asm-i386/signal.h 

include/asm-ia64/signal.h 

include/asm-m68k/signal.h 

include/asm-mips/signal.h 

include/asm-mips64/signal.h 

include/asm-parisc/signal.h 

include/asm-ppc/signal.h 

include/asm-ppc64/signal.h 

include/asm-s390/signal.h 

include/asm-s390x/signal.h 

include/asm-sh/signal.h 

include/asm-sparc/signal.h 

include/asm-sparc64/signal.h 

include/asm-x86_64/signal.h 

include/linux/stat.h 

include/linux/ctype.h 

lib/ctype.c 

include/asm-alpha/ioctl.h 

include/asm-alpha/ioctls.h 

include/asm-arm/ioctl.h 

include/asm-cris/ioctl.h 

include/asm-i386/ioctl.h 

include/asm-ia64/ioctl.h 

include/asm-m68k/ioctl.h 

include/asm-mips/ioctl.h 

include/asm-mips64/ioctl.h 

include/asm-mips64/ioctls.h 

include/asm-parisc/ioctl.h 

include/asm-parisc/ioctls.h 

include/asm-ppc/ioctl.h 

include/asm-ppc/ioctls.h 

include/asm-ppc64/ioctl.h 

include/asm-ppc64/ioctls.h 

include/asm-s390/ioctl.h 

include/asm-s390x/ioctl.h 

include/asm-sh/ioctl.h 

include/asm-sh/ioctls.h 

include/asm-sparc/ioctl.h 

include/asm-sparc/ioctls.h 

include/asm-sparc64/ioctl.h 

include/asm-sparc64/ioctls.h 

include/asm-x86_64/ioctl.h 

include/linux/ipc.h 

include/linux/acct.h 

include/asm-sparc/a.out.h 

include/linux/a.out.h 

arch/mips/boot/ecoff.h 

include/asm-sparc/bsderrno.h 

include/asm-sparc/solerrno.h 

include/asm-sparc64/bsderrno.h 

include/asm-sparc64/solerrno.h

Any thoughts?

-sb

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: SCO's infringing files list

[Joseph Pingenot]

>Any thoughts?

Yep.  After a very partial and preliminary look (ctype.h, signal.h, errno.h)
  I would recommend that SCO sue the much larger pot of Microsoft Windows
  users out there.
So far as I can tell, Visual Studio ships with these files as well, although
  I can't compare the Linux, SCO, and Windows versions of them.
Anyone with more info?

-Joseph


-- 
Joseph===============================================trelane@digitasaru.net
      Graduate Student in Physics, Freelance Free Software Developer

Re: SCO's infringing files list

[Stan Bubrouski]

On Mon, 2003-12-22 at 16:14, Joseph Pingenot wrote:
> >Any thoughts?
> 
> Yep.  After a very partial and preliminary look (ctype.h, signal.h, errno.h)
>   I would recommend that SCO sue the much larger pot of Microsoft Windows
>   users out there.
> So far as I can tell, Visual Studio ships with these files as well, although
>   I can't compare the Linux, SCO, and Windows versions of them.
> Anyone with more info?
> 
> -Joseph
> 

SCO contends that as part of BSD settlement these files must retain a
System V copyright header...unfortunately for them that settlement onyl
affected BSD and no one else, and the judge made clear it didn't believe
USL held the copyrights to these files sine they were previously
released without a copyright statement.

Furthermore the private settlement still isn't public so their claims
are beyond dubious, they fall into fraudulent at this point.  These
files have been published in books and elsewhere... and are mostly
defines, no code or methods...

Looks bleak for them, as long as the press doesn't jsut use this to keep
backing SCO as heros...god it makes me sick...in any other country these
fiends would be behind bars for trying extort money for things they
don't own and haven't proven they own.  Swindlers.

Come on SEC, step up you quivering cowards.

-sb

Re: SCO's infringing files list

[Tom Felker]

On Monday 22 December 2003 2:42 pm, Stan Bubrouski wrote:
> Guys,
>
> According to the totally inept, idiotic, SCO group, these files are
> copyrighted by them (and recently by Novell I might add):

> include/asm-i386/errno.h

> Any thoughts?
>
> -sb

The original errno.h, from linux-0.01, says it was taken from minix, and goes 
up to 40.  Between linux-0.96c and linux-0.97, that file was replaced with 
the present version, which includes the error strings and goes up to 121.

Where did the 0.97 to present version come from?

-- 
Tom Felker, <tcfelker@mtco.com>
<http://vlevel.sourceforge.net> - Stop fiddling with the volume knob.

Everything else about computers has become cheaper and faster.  Why
not software?

Re: SCO's infringing files list

[Linus Torvalds]

On Mon, 22 Dec 2003, Tom Felker wrote:
> 
> The original errno.h, from linux-0.01, says it was taken from minix, and goes 
> up to 40.

Good eyes - I only analysed the ctype.h thing, and didn't look up errno.h
in the original sources. errno.h has a _big_ comment saying where the
numbers came from (and some swearwords about POSIX ;)

Looking at signal.h, those numbers also seem to largely match minix. Which
makes sense - I actually had access to them.  

In both cases it's only the numbers that got copied, though. And not all
of them either - for some reason I tried to make the signal numbers match
(probably lazyness - not so much that I cared about the numbers
themselves, but about the list of signal names), but for example the
SA_xxxx macros - in the very same file - bear no relation to the minix
ones.

		Linus

Re: SCO's infringing files list

[jw schultz]

On Mon, Dec 22, 2003 at 01:55:00PM -0800, Linus Torvalds wrote:
> 
> 
> On Mon, 22 Dec 2003, Tom Felker wrote:
> > 
> > The original errno.h, from linux-0.01, says it was taken from minix, and goes 
> > up to 40.
> 
> Good eyes - I only analysed the ctype.h thing, and didn't look up errno.h
> in the original sources. errno.h has a _big_ comment saying where the
> numbers came from (and some swearwords about POSIX ;)
> 
> Looking at signal.h, those numbers also seem to largely match minix. Which
> makes sense - I actually had access to them.  
> 
> In both cases it's only the numbers that got copied, though. And not all
> of them either - for some reason I tried to make the signal numbers match
> (probably lazyness - not so much that I cared about the numbers
> themselves, but about the list of signal names), but for example the
> SA_xxxx macros - in the very same file - bear no relation to the minix
> ones.

And for the names, perhaps they would care to sue The Open
Group?
http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
And that probably applies to the rest of these header files.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: SCO's infringing files list

[Stan Bubrouski]

On Mon, 2003-12-22 at 19:26, jw schultz wrote:
> And for the names, perhaps they would care to sue The Open
> Group?
> http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
> And that probably applies to the rest of these header files.

Just to shore up what jw was talking about:

http://www.opengroup.org/onlinepubs/007904975/basedefs/signal.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html
http://www.opengroup.org/onlinepubs/007904975/basedefs/ctype.h.html

and for a listing of all the defines the open group has (dir listing):

http://www.opengroup.org/onlinepubs/007904975/basedefs/

Best Regards,

sb

Re: SCO's infringing files list

[Florian Weimer]

jw schultz wrote:

> And for the names, perhaps they would care to sue The Open
> Group?

Not the names, but the comments. 8-)

> http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html

The comments were added in Linux 0.99.1, and I'm not sure what was the
source.  For example, Linux has:

#define ENOTTY          25      /* Not a typewriter */

Solaris:

#define ENOTTY  25      /* Inappropriate ioctl for device       */

Current POSIX:

    [ENOTTY]
        Inappropriate I/O control operation.

I couldn't find any historic Minix header files.  Minix 2 has:

#define ENOTTY        (_SIGN 25)  /* inappropriate I/O control operation */

Re: SCO's infringing files list

[Giacomo A. Catenazzi]

Florian Weimer wrote:

> jw schultz wrote:
> 
> 
>>And for the names, perhaps they would care to sue The Open
>>Group?
> 
> 
> Not the names, but the comments. 8-)
> 
> 
>>http://www.opengroup.org/onlinepubs/007904975/basedefs/errno.h.html
> 
> 
> The comments were added in Linux 0.99.1, and I'm not sure what was the
> source.  For example, Linux has:
> 
> #define ENOTTY          25      /* Not a typewriter */
> 
> Solaris:
> 
> #define ENOTTY  25      /* Inappropriate ioctl for device       */
> 
> Current POSIX:
> 
>     [ENOTTY]
>         Inappropriate I/O control operation.
> 
> I couldn't find any historic Minix header files.  Minix 2 has:
> 
> #define ENOTTY        (_SIGN 25)  /* inappropriate I/O control operation */

In 
http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c

/* Extended support for using errno values.
    Written by Fred Fish.  fnf@cygnus.com
    This file is in the public domain.  --Per Bothner.  */
(...)
#if defined (ENOTTY)
   ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
#endif


FYI there was a proposed patch to change "Not a typewriter" to 
"Inappropriate ioctl for device". Check the interesting thread of lkml:
http://www.ussg.iu.edu/hypermail/linux/kernel/0105.1/0471.html

ciao
	giacomo

Re: SCO's infringing files list

[Linus Torvalds]

On Tue, 23 Dec 2003, Giacomo A. Catenazzi wrote:

> Florian Weimer wrote:
> > 
> > The comments were added in Linux 0.99.1, and I'm not sure what was the
> > source.

No, the comments are already there in 0.97 (and they are _not_ in
0.96c-pl2, which is the last patch before that that I have found).

The timeline looks like (this is by no means guaranteed correct, the dates
are from things like the patch files that may not be the originals, but 
they look consistent):

 0.96c:		July 4th, 1992
 0.96c-pl1:	July 11th
 0.96c-pl2:	July 18th

	--- here somewhere ---

 0.97:		Aug 1st


The errno change was apparently done on or around July 25, 1992. That's
the date on the "errno.h" file in the linux-0.97 archive, and it is
consistent with the above release dates.

If anybody has newgroup/mailing list archives from around that time, it
would be very nice to see what that finds..

> >	  For example, Linux has:
> > 
> > #define ENOTTY          25      /* Not a typewriter */

My _suspicion_ is that it comes from "strerror()". That's how I'd
personally have done it (ie write a simple script to generate the errno
values and the comments). But this is over a decade ago, and I sure as 
hell can't remember who would have done that.

It might even have been me, but I doubt it - I've never been that big into
comments, so it's likely somebody else was more motivated than me to make 
errno.h cleaner. But if I did it, I definitely would have done it with a 
script.

Btw: there is some incidental "evidence" that that original 0.97 version
of <linux/errno.h> is automatically generated: the thing looks to have
very regular whitespace. It looks like it was generated with

	#define\t%s\t\t%2d\t/* %s */

and then tab-corrected for the symbolic name lengths. There are no spaces 
at ends-of-lines, and _all_ of the spaces between "define" and the actual 
error mnemonic are actually _tabs_.

And this is true for _all_ the Exxxx defines _except_ for the two special
kernel entries: ERESTARTSYS and ERESTARTNOINTR were clearly not generated
the same way, because they have a regular _space_ between the #define and
the EXXXX.

That just makes me go "hmm..". You can't actually see the TAB vs <space> 
thing when you open the file normally, because they both end up being 
aligned the same way. So I'd suspect a script that generated the 
list of the "normal" error codes simply because

 - people just aren't that regular by hand
 - most people would use a space in between #define and XXXX, as also 
   shown by the two cases that clearly are _not_ scripted.

For example, grepping for "#define" followed by space shows up 1836 such
entries in the 0.97 kernel. In contrast, doing the same for "#define"  
followed by a tab shows 227 such entries - of which the errno.h ones are a
solid block of 121 entries, while the others are a lot more random (and 44
of the remaining ~100 cases have multiple tabs and are thus _visible_ as
such).

So just from a regularity standpoint, it does look auto-generated.

> > Solaris:
> > 
> > #define ENOTTY  25      /* Inappropriate ioctl for device       */
> > 
> > Current POSIX:
> > 
> >     [ENOTTY]
> >         Inappropriate I/O control operation.
> > 
> > I couldn't find any historic Minix header files.  Minix 2 has:
> > 
> > #define ENOTTY        (_SIGN 25)  /* inappropriate I/O control operation */

The "Not a typewriter" thing is the obvious one from just reading the
error number mnemonic. Hard to tell where it comes from, but it definitely
does not rule out strerror() in that timeframe.

> In 
> http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c
> 
> /* Extended support for using errno values.
>     Written by Fred Fish.  fnf@cygnus.com
>     This file is in the public domain.  --Per Bothner.  */
> (...)
> #if defined (ENOTTY)
>    ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
> #endif

Something like that may well be the source of the string. Fred Fish was 
active long before this timeframe (if it's the same Fred Fish - he used to 
do freeware collections for the Amiga in the '80's).

But there were multiple libc's around (estdio, libc5, glibc..), and it 
could be any of them.

Trying to find the kernel list archives from that timeframe would likely
clarify the issue. There were several lists back then: "linux-activists"  
mailing list, and of course the "comp.os.linux" newsgroup (this was before
it split into multiple newsgroups).

I've found some archives for linux-activists, but no newsgroup archives 
going that far back.. Anybody?

			Linus

Re: SCO's infringing files list

[viro]

On Tue, Dec 23, 2003 at 04:34:41AM -0800, Linus Torvalds wrote:
 
> Trying to find the kernel list archives from that timeframe would likely
> clarify the issue. There were several lists back then: "linux-activists"  
> mailing list, and of course the "comp.os.linux" newsgroup (this was before
> it split into multiple newsgroups).
> 
> I've found some archives for linux-activists, but no newsgroup archives 
> going that far back.. Anybody?

http://groups.google.com/advanced_group_search

They'd done what DN had promised and never did - merged old usenet
archives into their database, all way back to '81.

The earliest they have on comp.os.linux is March 1992 and results of voting
on newgroup had been posted by tytso on Mar 25 1992.  There's a bogus
crosspost into (still not existing) c.o.l on Mar 21 and regular postings
starting on Mar 31.  IOW, archive goes all way back to the group creation.

alt.os.linux archives there start on Jan 19 1992 (newgrouped somewhere
around Jan 17, took several days to propagate).  Before that it's c.o.minix,
but by the time you are looking for migration from c.o.m should've been
over.

Re: SCO's infringing files list

[Giacomo A. Catenazzi]

Linus Torvalds wrote:
> On Tue, 23 Dec 2003, Giacomo A. Catenazzi wrote:

>>In 
>>http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c
>>
>>/* Extended support for using errno values.
>>    Written by Fred Fish.  fnf@cygnus.com
>>    This file is in the public domain.  --Per Bothner.  */
>>(...)
>>#if defined (ENOTTY)
>>   ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
>>#endif
> 
> 
> Something like that may well be the source of the string. Fred Fish was 
> active long before this timeframe (if it's the same Fred Fish - he used to 
> do freeware collections for the Amiga in the '80's).
> 
> But there were multiple libc's around (estdio, libc5, glibc..), and it 
> could be any of them.
> 
> Trying to find the kernel list archives from that timeframe would likely
> clarify the issue. There were several lists back then: "linux-activists"  
> mailing list, and of course the "comp.os.linux" newsgroup (this was before
> it split into multiple newsgroups).
> 
> I've found some archives for linux-activists, but no newsgroup archives 
> going that far back.. Anybody?

I found only a mail in linux-activists: It say """
4. lots of stuffs added to errno.h and string/errlist.c.
"""
It seems that the new errno.h is added in libc, but there are some 
references of kernel and the post date is in the same weeks of the new 
kernel errno.h, so possibly the linux errno.h is based uppon this library.
Maybe someone of the "old" guys will understand something better about 
this post.

ciao
	giacomo



From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
Subject: Re: gcc-2.2.2 patches for linux?
Date: 19 Jul 92 15:42:48 GMT

In article <54473@mentor.cc.purdue.edu> wilker@hopf.math.purdue.edu 
(Clarence Wilkers
on) writes:
 >I'd like to do cross compilation for linux on a sparc. Has anyone set this
 >up?
 >--


Please read all the previous release notes and docs. This release note
only covers the new stuffs.

This is gcc 2.2.2 for Linux. It is on banjo.concert.net under
/pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS. The FSF
has all the files Linux needs.

Please get the new binutils.tar.Z, which fixed some bugs in as and a
gprof with some patches from Rick Sladkey at jrs@world.std.com, if
you haven't got it.

I added some jumptable stubs to gcc. But I don't have the time to
implement it. In the future, you can use jump table with -jump in
CFLAGS.

Libg++.a is 2.2 beta.

This gcc will produce binaries only run safely under 0.96a patch level
4 or above.

The list of known bugs.

1. one 'cmp' in dbz test fails. Per is not planning on doing anything
    about it. your contribution is welcome.

The following bugs in libc.a are fixed.

1. hard and soft math libs are fixed. some of functions are totally
    rewritten.
2. acosh, asinh and atanh are added to libsoft.a and math.h.
3. open a file for read and write, then do fseek followed by fwrite
    works now.
4. now random () and srandom () are renamed to __random () and
    __srandom (), respectively.
5. the header files taken from glibc.a are fixed.
6. the sys call mount now takes 4 args.
7. getpagesize and getdtablesize work now.
8. netdb.h, resolv.h, sys/uio.h, netinet.h, arpa/inet.h and
    arpa/nameser.h are changed.
9. Some function declarations are added to sys/socket.h in
    0.96bp2inc.tar.Z.

The following functions are added to libc.a.

1. profil.
2. libg.a is there.
3. getdtablesize.
4. lots of stuffs added to errno.h and string/errlist.c.
5. some changes in string/siglist.c.
6. dtoa.
7. there is a new strtod, please check it out.
8. drem.
9. the inet library functions are in libinet.a. They are untested. Once
    they are tested ok, they will be moved to libc.a. All the inet
    library functions are there, except for res_xxxx, rcmd, rexec and
    ruserpass, which require more kernel support, like F_SETOWN, FASYNC,
    and a few network system calls.

    There should also be a set of files in /etc for inet functions. I
    hope Ross will provide them.

In this release, there is a libc_p.a compiled with "-pg" for profiling.

You should use "-g" for debugging and "-pg/-p" for profiling in CFLAGS
when you compile the source code.


There must be a few other bugs. Please let me know if you find any.

File list:

1. 2.2.2db.tar.Z (cpp, libg.a and libc_p.a)
2. 2.2.2lib.tar.Z (cc1, cc1plus)
3. 2.2.2misc.tar.Z (header files, drivers, libs, doc, ....)
4. shlib-2.2.2.tar.Z (making the shared libs for gcc 2.2.2)
5. libc-2.2.2.tar.Z (source code for the libs)
6. gcc-2.2.2.tar.Z (patches for compiling gcc 2.2.2)
7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)

H.J.
hlu@eecs.wsu.edu
06/27/92

Re: SCO's infringing files list

[Mitchell Blank Jr]

Giacomo A. Catenazzi wrote:
> I found only a mail in linux-activists: It say """
> 4. lots of stuffs added to errno.h and string/errlist.c.

Yeah, I just found that one too - its in digest485 from the tarball
http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux-activists/Volume2/Linux-V2-4XX.tar.z

| From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
| Subject: Re: gcc-2.2.2 patches for linux?
| Date: 19 Jul 92 15:42:48 GMT
|
[...]
| This is gcc 2.2.2 for Linux. It is on banjo.concert.net under
| /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS. The FSF
| has all the files Linux needs.

Note that this is back when gcc and libc were distributed together, both
by H J Lu.  The file list in the announcement includes:

| 1. 2.2.2db.tar.Z (cpp, libg.a and libc_p.a)
| 2. 2.2.2lib.tar.Z (cc1, cc1plus)
| 3. 2.2.2misc.tar.Z (header files, drivers, libs, doc, ....)
| 4. shlib-2.2.2.tar.Z (making the shared libs for gcc 2.2.2)
| 5. libc-2.2.2.tar.Z (source code for the libs)
| 6. gcc-2.2.2.tar.Z (patches for compiling gcc 2.2.2)
| 7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)

The last file seems to be a modified version of the 0.96bp2 header files
needed in order to work with the new gcc release (searching for that filename
turns up a message discussing it a little)  So I'm guessing that the
July 25, 1992 errno.h in the linux tree is a merge from this code.

Now, does anyone have a copy of "0.96bp2inc.tar.Z" lying around?

-Mitch

Re: SCO's infringing files list

[Mitchell Blank Jr]

I wrote:
> | 7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)
> 
> The last file seems to be a modified version of the 0.96bp2 header files
> needed in order to work with the new gcc release (searching for that filename
> turns up a message discussing it a little)

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.

There is some mention of a "GCC channel" where new linux GCC releases got
discussed:

|                       If you want to use the testing release, first
| join the GCC channel on the Linux mailing list, and then send a note to
| hlu@eecs.wsu.edu.

Does anyone know if there's an archive available for that ancient list?
Maybe we can find some discussion WRT errno.h there.

-Mitch

Re: SCO's infringing files list

[Linus Torvalds]

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 = "\t\t"+(n > 7);
                const char *expl = libc222_errlist[i];
                printf("#define\t%s%s%2d\t/* %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

Re: SCO's infringing files list

[Charles Cazabon]

Linus Torvalds <torvalds@osdl.org> wrote:
> 
> Bingo!
[...]
> 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"?

Well, it's been recompressed with gzip, but it's here (among other places):
ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz

I haven't checked the original GNU/MIT site it was apparently mirrored from,
but it might be there.

Charles
-- 
-----------------------------------------------------------------------
Charles Cazabon                            <linux@discworld.dyndns.org>
GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------

Re: SCO's infringing files list

[viro]

On Tue, Dec 23, 2003 at 12:40:24PM -0600, Charles Cazabon wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > Bingo!
> [...]
> > 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"?
> 
> Well, it's been recompressed with gzip, but it's here (among other places):
> ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz

Completely different animal.  glibc2 is at least 5 years later.

Re: SCO's infringing files list

[Mitchell Blank Jr]

Charles Cazabon wrote:
> Well, it's been recompressed with gzip, but it's here (among other places):
> ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz

No, we're looking for the pre-glibc-2 versions.  In the early days of linux
the "libc" version was kept in sync with the gcc it was meant to go with.
So although (IIRC) the early linux libc was forked from GNU's libc it had
its own version numbering.  It wasn't until years later that the big merge
back to glibc happened (1997 or so).

I don't think you'll find any of the old linux libc-2.x.x releases on GNU's
site.

-Mitch

Re: SCO's infringing files list

[Matti Aarnio]

On Tue, Dec 23, 2003 at 12:40:24PM -0600, Charles Cazabon wrote:
> [...]
> > 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"?
> 
> Well, it's been recompressed with gzip, but it's here (among other places):
> ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz

Nope.  That is something entirely different -- and 9 years latter..
Nor can I find these bits in FUNET.FI's ancient archive branches.

> I haven't checked the original GNU/MIT site it was apparently mirrored from,
> but it might be there.
> 
> Charles
> -- 
> -----------------------------------------------------------------------
> Charles Cazabon                            <linux@discworld.dyndns.org>
> GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/

Re: SCO's infringing files list

[Shawn]

Why is everyone looking in FTP sites? Doesn't anyone have those old CDs
with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a
box somewhere.

Is anyone from (or formerly from) cdrom.com (read|listen)ing?

On Tue, 2003-12-23 at 12:52, Matti Aarnio wrote:
> On Tue, Dec 23, 2003 at 12:40:24PM -0600, Charles Cazabon wrote:
> > [...]
> > > 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"?
> > 
> > Well, it's been recompressed with gzip, but it's here (among other places):
> > ftp://ftp.uni-kassel.de/Mirrors/prep.ai.mit.edu/pub/gnu/glibc/glibc-2.2.2.tar.gz
> 
> Nope.  That is something entirely different -- and 9 years latter..
> Nor can I find these bits in FUNET.FI's ancient archive branches.
> 
> > I haven't checked the original GNU/MIT site it was apparently mirrored from,
> > but it might be there.
> > 
> > Charles
> > -- 
> > -----------------------------------------------------------------------
> > Charles Cazabon                            <linux@discworld.dyndns.org>
> > GPL'ed software available at:     http://www.qcc.ca/~charlesc/software/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: SCO's infringing files list

[Stan Bubrouski]

On Tue, 2003-12-23 at 14:58, Shawn wrote:
> Why is everyone looking in FTP sites? Doesn't anyone have those old CDs
> with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a
> box somewhere.
> 
> Is anyone from (or formerly from) cdrom.com (read|listen)ing?

I found the original libc-222 sources on an old machine of mine, and I
do believe it originally came off of an old FTP a while back (too far
back for me to remember off hand).  Can be gotten at:

http://www.ccs.neu.edu/~stan/linux/libc-222.taz

That is the only 2.x version of libc I have found thus far, in the same
directory I found a bunch of old 4.x and 5.x libc versions as well, if
anyone wants a specific one let me know and I'll post it to the site or
e-mail it directly (I don't have enough web room to post them all atm). 
Not sure, but from the looks of the directory structure I must have got
them mirroring a site back in '97.  Not sure what site though.  I'm
trying to figure that out to see if its mirrored anywhere else.

Regards,

sb

Re: SCO's infringing files list

[John Shifflett]

> Why is everyone looking in FTP sites? Doesn't anyone have those old CDs
> with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a

There are probably many of us; I checked my old InfoMagic "Developer's
Resource" 4 CD set from 1995 and found a 'linux-activists' archive that
goes back to November of 1991.

	JS

Re: SCO's infringing files list

[Bill Davidsen]

500Shawn wrote:
> Why is everyone looking in FTP sites? Doesn't anyone have those old CDs
> with all the tsx-11/sunsite archives? I'm /sure/ someone has some in a
> box somewhere.

How about "Linux Quarterly Fall 1994" (now includes Slackware 
Professional 2.1). And sunsite archives. I've also got some CheapBytes 
"complete Linux" CDs from about the same time.


-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: SCO's infringing files list

[Steven Cole]

On Tue, 2003-12-23 at 10:25, Linus Torvalds wrote:
> 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 = "\t\t"+(n > 7);
>                 const char *expl = libc222_errlist[i];
>                 printf("#define\t%s%s%2d\t/* %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

The earliest tarballs here may be of interest:
http://www.pell.portland.or.us/~orc/Code/libc/

[steven@spc9 libc-linux]$ head -n 20 jumptable1/string/_errlist.c
#include <ansidecl.h>
#include <stddef.h>
#include <errno.h>

/* 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 */
        "Bad file number",                      /* EBADF */
        "No child processes",                   /* ECHILD */
        "Try again",                            /* EAGAIN */
        "Out of memory",                        /* ENOMEM */

That file dates from Nov 20 1992.

Steven

Re: SCO's infringing files list

[Mitchell Blank Jr]

Steven Cole wrote:
> /* This is a list of all known signal numbers.  */
> 
> CONST char *CONST _sys_errlist[] = {

Note the incorrect comment (since its a list of error numbers, not signal
numbers).  It looks like the comment was originally from siglist.c in the
same directory.

I wonder if there are any UNIX sources which have a similar typo.  I somewhat
doubt it.

-Mitch

Re: SCO's infringing files list

[Mitchell Blank Jr]

(Replying to myself again)

> Now, does anyone have a copy of "0.96bp2inc.tar.Z" lying around?

BTW, a few more details on this file - the linux GCC 2.2.2 release was
originally announced 28-Jun-1992.  The 0.96bp2inc.tar.Z file originally
lived on the then-primary linux ftp site banjo.concert.net in directory
pub/Linux/GCC.

banjo stopped being an FTP server a couple months later - however,
Jonathan Magid announced on 13-Aug-1992 that the entire banjo site
was being reincarnated at host reggae.oit.unc.edu in directory
ftp/pub/pc-stuff/Linux.  Here's a copy of the announcement:
  http://www.kclug.org/old_archives/linux-activists/1992/aug/1/0708.shtml

My understanding is that reggae.oit morphed at some point into
sunsite.unc.edu (which is now, of course, ibiblio.org)  Jonathan still
appears to be there, so I'm cc:ing him on this (apologies in advance
if its an intrusion, Jonathan) on the off-chance that there might still
be a 1992-era archive of the linux files once hosted by banjo.

The only other person likely to have access to a copy is H J Lu himself
(also cc:'ed although I'm 99% sure he's still on lkml :-)

-Mitch

Re: SCO's infringing files list

[Linus Torvalds]

On Tue, 23 Dec 2003, Mitchell Blank Jr wrote:
>
> (Replying to myself again)
> 
> > Now, does anyone have a copy of "0.96bp2inc.tar.Z" lying around?
> 
> BTW, a few more details on this file - the linux GCC 2.2.2 release was
> originally announced 28-Jun-1992.  The 0.96bp2inc.tar.Z file originally
> lived on the then-primary linux ftp site banjo.concert.net in directory
> pub/Linux/GCC.

Note that we really don't care about that "0.96bp2inc.tar.Z" file: that's 
just the kernel headers, and 0.96b-pl2 did _not_ contain the comments yet. 
But libc used to use the kernel headers for other things (for things like 
system call numbers etc).

It's almost certainly the "libc-2.2.2.tar.Z" file that we want - that's 
the one that is going to contain the sys_errlist[] lists etc. Note how 
this libc-2.2.2 announcement predates the merging of the kernel header by 
almost a month - the kernel header information came from libc, not the 
other way around.

> banjo stopped being an FTP server a couple months later - however,
> Jonathan Magid announced on 13-Aug-1992 that the entire banjo site
> was being reincarnated at host reggae.oit.unc.edu in directory
> ftp/pub/pc-stuff/Linux.  Here's a copy of the announcement:
>   http://www.kclug.org/old_archives/linux-activists/1992/aug/1/0708.shtml

Does anybody have old CD-ROM's lying around?

In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently
released just a few months later. It would quite possibly contain the
libc-2.2.2 sources... Adam Richter is still active, and I added him to the
cc..

Who else was doing CD's back then? SLS? If nobody has the thing on a
web-site any more, maybe they exist in physical format on somebodys
bookshelf? The only reason that the really historic kernel archives still
exist is that people saved them, and even so we're missing versions 0.02
and 0.03, but by the latter half of -92 there were already CD-ROMs being 
manufactured...

Of course, maybe the CD's are unreadable by now.

			Linus

Re: SCO's infringing files list

[Stan Bubrouski]

On Tue, 2003-12-23 at 12:56, Linus Torvalds wrote:
> In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently
> released just a few months later. It would quite possibly contain the
> libc-2.2.2 sources... Adam Richter is still active, and I added him to the
> cc..
> 
> Who else was doing CD's back then? SLS? If nobody has the thing on a
> web-site any more, maybe they exist in physical format on somebodys
> bookshelf? The only reason that the really historic kernel archives still
> exist is that people saved them, and even so we're missing versions 0.02
> and 0.03, but by the latter half of -92 there were already CD-ROMs being 
> manufactured...
> 
> Of course, maybe the CD's are unreadable by now.
> 

You mean this?
http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/libc.2.2.2.z

-sb


> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: SCO's infringing files list

[Harry McGregor]

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

                  Harry

Re: SCO's infringing files list

[Stan Bubrouski]

On Tue, 2003-12-23 at 13:14, Harry McGregor wrote:
> http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/
> 

I believe that is just a binary... :-/

-sb

>                   Harry
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: SCO's infringing files list

[Disconnect]

On Tue, 2003-12-23 at 13:14, Harry McGregor wrote:
> http://www.ibiblio.org/pub/Linux/libs/oldlibs/libc-2.2.2/

Yep. Thats the binary he's talked repeatedly about already having.  Got
sources?

-- 
Disconnect <lkml@sigkill.net>

Re: SCO's infringing files list

[Stan Bubrouski]

Ignore my last reply, sometimes I'm jsut an idiot.

-sb

On Tue, 2003-12-23 at 12:56, Linus Torvalds wrote:
> Does anybody have old CD-ROM's lying around?
> 
> In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently
> released just a few months later. It would quite possibly contain the
> libc-2.2.2 sources... Adam Richter is still active, and I added him to the
> cc..
> 
> Who else was doing CD's back then? SLS? If nobody has the thing on a
> web-site any more, maybe they exist in physical format on somebodys
> bookshelf? The only reason that the really historic kernel archives still
> exist is that people saved them, and even so we're missing versions 0.02
> and 0.03, but by the latter half of -92 there were already CD-ROMs being 
> manufactured...
> 
> Of course, maybe the CD's are unreadable by now.
> 
> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: SCO's infringing files list

[Stan Bubrouski]

On Tue, 2003-12-23 at 12:56, Linus Torvalds wrote:

> 
> Does anybody have old CD-ROM's lying around?
> 
> In particular, the Yggdrasil Linux/GNU/X alpha CD-ROM was apparently
> released just a few months later. It would quite possibly contain the
> libc-2.2.2 sources... Adam Richter is still active, and I added him to the
> cc..
> 
> Who else was doing CD's back then? SLS? If nobody has the thing on a

There are some old SLS versions lying around here:
http://grumbeer.dyndns.org/ftp/linux/dist/SLS/

and other places but they are all binary from what i can tell.  Anybody
have any idea where a source tree for SLS might be?  I'm finding it very
hard to track down this stuff (before my time).  Were there any distros
that included source by default or were free that we could look to? 
Anyone? Put on the way-back caps.

-sb

> web-site any more, maybe they exist in physical format on somebodys
> bookshelf? The only reason that the really historic kernel archives still
> exist is that people saved them, and even so we're missing versions 0.02
> and 0.03, but by the latter half of -92 there were already CD-ROMs being 
> manufactured...
> 
> Of course, maybe the CD's are unreadable by now.
> 
> 			Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: SCO's infringing files list

[Andries Brouwer]

On Tue, Dec 23, 2003 at 09:56:11AM -0800, Linus Torvalds wrote:

> It's almost certainly the "libc-2.2.2.tar.Z" file that we want

I just uploaded a copy to
ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz

Andries
Linux archaeologist

Re: SCO's infringing files list

[Stan Bubrouski]

On Tue, 2003-12-23 at 14:06, Andries Brouwer wrote:
> On Tue, Dec 23, 2003 at 09:56:11AM -0800, Linus Torvalds wrote:
> 
> > It's almost certainly the "libc-2.2.2.tar.Z" file that we want
> 
> I just uploaded a copy to
> ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz
> 

Excellent same file.  Where'd you come across it?  And do you have any
other 2.x libc lying around?  Looks like the collection on your site has
a couple I'm missing from 4.x series.  I have an old FTP archive on my
machine from back a ways, but its missing 4.2 4.1 and earlier libc
versions, do you have them anywhere as   Or better yet, the filenames of
the archives they might be in, as I might already have them and just
don't know it ;-)

-sb

> Andries
> Linux archaeologist
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: SCO's infringing files list

[Mitchell Blank Jr]

Andries Brouwer wrote:
> I just uploaded a copy to
> ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz

OK, so that takes us back to errlist.c modified 18-Jun-92:

% tar tvfz libc-222.taz | grep errlist
-rw-r--r-- hlu/other      5601 1992-06-18 21:58:54 ./libc-linux/string/errlist.c

And yes it includes the incorrect comment.

-Mitch

Re: SCO's infringing files list

[Linus Torvalds]

On Tue, 23 Dec 2003, Andries Brouwer wrote:
> On Tue, Dec 23, 2003 at 09:56:11AM -0800, Linus Torvalds wrote:
> 
> > It's almost certainly the "libc-2.2.2.tar.Z" file that we want
> 
> I just uploaded a copy to
> ftp://ftp.win.tue.nl/pub/linux-local/libc.archive/libc/libc-222.taz

Yup, and I can confirm two things:

 - the strings match 100% (well, duh, we already saw that from the binary)
 - it doesn't even have an "errno.h"

that, together with the timing, pretty much proves that the kernel header
was indeed just auto-generated from sys_errlist[] of that timeframe, with 
a program very much like the one I already posted.

Now, the libc file just says 

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

(which is obviously just a cut-and-paste from siglist.c n the same 
directory). But it shouldn't much matter, since I don't think SCO really 
is going to try to claim copyright ownership of the result of standard C 
library interactions like using "sys_errlist[]".

(I take that back - _of_course_ they are going to try to claim ownership. 
After all, they already claimed ownership of code I provably wrote).

			Linus

[OT] Re: SCO's infringing files list

[Thomas Zehetbauer]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

You should however realize that SCO has succeeded in diverting a large
amount of attention from the further development of Linux to their
pointless claims. Although I have to admit that I do myself find their
statements quite amusing we should watch out to avoid spending too much
time with their claims.

If there is a conspiracy going on against Linux they have not only found
a major weakness in the development process but also a company and
unwary investors to exploit it. While their claims would only affect
some rather unimportant people (CEO, legal department) in a traditional
company they have succeeded to distract many of the core developers from
their usual focus.

Just my .02c - comments welcome!

Regards
Tom

-- 
  T h o m a s   Z e h e t b a u e r   ( TZ251 )
  PGP encrypted mail preferred - KeyID 96FFCB89
       mail pgp-key-request@hostmaster.org

UNIX is user-friendly ... it's just selective about who it's friends are

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 481 bytes --]

Re: [OT] Re: SCO's infringing files list

[Stan Bubrouski]

On Tue, 2003-12-23 at 18:56, Thomas Zehetbauer wrote:
> You should however realize that SCO has succeeded in diverting a large
> amount of attention from the further development of Linux to their
> pointless claims. Although I have to admit that I do myself find their
> statements quite amusing we should watch out to avoid spending too much
> time with their claims.
> 

Well maybe, but people like me who aren't actual kernel developers are
doing our part to help track this stuff down.  Groklaw is helping,
basically the entire community is contributing.  We as a community only
know so much however, we can find files but only the original developers
know who did what really.

> If there is a conspiracy going on against Linux they have not only found
> a major weakness in the development process but also a company and
> unwary investors to exploit it. While their claims would only affect
> some rather unimportant people (CEO, legal department) in a traditional
> company they have succeeded to distract many of the core developers from
> their usual focus.
> 

Yes they can try to exploit end users the same way they have exploited
the press, the only problem is its not working.  Linux users know this
is total BS, but the press our the ones who spread SCO's lies.  SCO
knows the trial isn't for over a year and so they are using the press to
wage their war.  The success of Linux isn't in the press, it's in the
code, and that isn't lost on anyone I don't think.  Cheer up, 2.6 was
just released, I don't think anything has slowed down, except this list
is a little bit quiet due to the holidays, but thats nothing new :)

Merry Christmas!

sb

> Just my .02c - comments welcome!
> 
> Regards
> Tom

Re: SCO's infringing files list

[venom]

checked libc4 a.out and libc5, it seems it does not come from them....

Luigi


On Tue, 23 Dec 2003, Giacomo A. Catenazzi wrote:

> Date: Tue, 23 Dec 2003 16:44:39 +0100
> From: Giacomo A. Catenazzi <cate@pixelized.ch>
> To: Linus Torvalds <torvalds@osdl.org>
> Cc: Giacomo A. Catenazzi <cate@debian.org>, Florian Weimer <fw@deneb.enyo.de>,
>      jw schultz <jw@pegasys.ws>,
>      "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
>      Eric S. Raymond <esr@thyrsus.com>
> Subject: Re: SCO's infringing files list
>
>
>
> Linus Torvalds wrote:
> > On Tue, 23 Dec 2003, Giacomo A. Catenazzi wrote:
>
> >>In
> >>http://www.opensource.apple.com/darwinsource/DevToolsMay2002/gcc-937.2/libiberty/strerror.c
> >>
> >>/* Extended support for using errno values.
> >>    Written by Fred Fish.  fnf@cygnus.com
> >>    This file is in the public domain.  --Per Bothner.  */
> >>(...)
> >>#if defined (ENOTTY)
> >>   ENTRY(ENOTTY, "ENOTTY", "Not a typewriter"),
> >>#endif
> >
> >
> > Something like that may well be the source of the string. Fred Fish was
> > active long before this timeframe (if it's the same Fred Fish - he used to
> > do freeware collections for the Amiga in the '80's).
> >
> > But there were multiple libc's around (estdio, libc5, glibc..), and it
> > could be any of them.
> >
> > Trying to find the kernel list archives from that timeframe would likely
> > clarify the issue. There were several lists back then: "linux-activists"
> > mailing list, and of course the "comp.os.linux" newsgroup (this was before
> > it split into multiple newsgroups).
> >
> > I've found some archives for linux-activists, but no newsgroup archives
> > going that far back.. Anybody?
>
> I found only a mail in linux-activists: It say """
> 4. lots of stuffs added to errno.h and string/errlist.c.
> """
> It seems that the new errno.h is added in libc, but there are some
> references of kernel and the post date is in the same weeks of the new
> kernel errno.h, so possibly the linux errno.h is based uppon this library.
> Maybe someone of the "old" guys will understand something better about
> this post.
>
> ciao
> 	giacomo
>
>
>
> From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
> Subject: Re: gcc-2.2.2 patches for linux?
> Date: 19 Jul 92 15:42:48 GMT
>
> In article <54473@mentor.cc.purdue.edu> wilker@hopf.math.purdue.edu
> (Clarence Wilkers
> on) writes:
>  >I'd like to do cross compilation for linux on a sparc. Has anyone set this
>  >up?
>  >--
>
>
> Please read all the previous release notes and docs. This release note
> only covers the new stuffs.
>
> This is gcc 2.2.2 for Linux. It is on banjo.concert.net under
> /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS. The FSF
> has all the files Linux needs.
>
> Please get the new binutils.tar.Z, which fixed some bugs in as and a
> gprof with some patches from Rick Sladkey at jrs@world.std.com, if
> you haven't got it.
>
> I added some jumptable stubs to gcc. But I don't have the time to
> implement it. In the future, you can use jump table with -jump in
> CFLAGS.
>
> Libg++.a is 2.2 beta.
>
> This gcc will produce binaries only run safely under 0.96a patch level
> 4 or above.
>
> The list of known bugs.
>
> 1. one 'cmp' in dbz test fails. Per is not planning on doing anything
>     about it. your contribution is welcome.
>
> The following bugs in libc.a are fixed.
>
> 1. hard and soft math libs are fixed. some of functions are totally
>     rewritten.
> 2. acosh, asinh and atanh are added to libsoft.a and math.h.
> 3. open a file for read and write, then do fseek followed by fwrite
>     works now.
> 4. now random () and srandom () are renamed to __random () and
>     __srandom (), respectively.
> 5. the header files taken from glibc.a are fixed.
> 6. the sys call mount now takes 4 args.
> 7. getpagesize and getdtablesize work now.
> 8. netdb.h, resolv.h, sys/uio.h, netinet.h, arpa/inet.h and
>     arpa/nameser.h are changed.
> 9. Some function declarations are added to sys/socket.h in
>     0.96bp2inc.tar.Z.
>
> The following functions are added to libc.a.
>
> 1. profil.
> 2. libg.a is there.
> 3. getdtablesize.
> 4. lots of stuffs added to errno.h and string/errlist.c.
> 5. some changes in string/siglist.c.
> 6. dtoa.
> 7. there is a new strtod, please check it out.
> 8. drem.
> 9. the inet library functions are in libinet.a. They are untested. Once
>     they are tested ok, they will be moved to libc.a. All the inet
>     library functions are there, except for res_xxxx, rcmd, rexec and
>     ruserpass, which require more kernel support, like F_SETOWN, FASYNC,
>     and a few network system calls.
>
>     There should also be a set of files in /etc for inet functions. I
>     hope Ross will provide them.
>
> In this release, there is a libc_p.a compiled with "-pg" for profiling.
>
> You should use "-g" for debugging and "-pg/-p" for profiling in CFLAGS
> when you compile the source code.
>
>
> There must be a few other bugs. Please let me know if you find any.
>
> File list:
>
> 1. 2.2.2db.tar.Z (cpp, libg.a and libc_p.a)
> 2. 2.2.2lib.tar.Z (cc1, cc1plus)
> 3. 2.2.2misc.tar.Z (header files, drivers, libs, doc, ....)
> 4. shlib-2.2.2.tar.Z (making the shared libs for gcc 2.2.2)
> 5. libc-2.2.2.tar.Z (source code for the libs)
> 6. gcc-2.2.2.tar.Z (patches for compiling gcc 2.2.2)
> 7. 0.96bp2inc.tar.Z (the kernel header files for 0.96b patch level 2)
>
> H.J.
> hlu@eecs.wsu.edu
> 06/27/92
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: SCO's infringing files list

[Mitchell Blank Jr]

Linus Torvalds wrote:
> The errno change was apparently done on or around July 25, 1992. That's
> the date on the "errno.h" file in the linux-0.97 archive, and it is
> consistent with the above release dates.
> 
> If anybody has newgroup/mailing list archives from around that time, it
> would be very nice to see what that finds..

Well, from the linux-activists messages for that period would be in:

  http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux-activists/Volume2/Linux-V2-5XX.tar.z

Specifically, the files "digest51[789] digest52[012]" are the neighborhood
around july 25th.  I did a quick grep for "errno" and a few strings from
the errno.h file and didn't see anything relevant pop up, though.

-Mitch

Re: SCO's infringing files list

[Andries Brouwer]

On Tue, Dec 23, 2003 at 04:34:41AM -0800, Linus Torvalds wrote:

> The errno change was apparently done on or around July 25, 1992. That's
> the date on the "errno.h" file in the linux-0.97 archive, and it is
> consistent with the above release dates.
> 
> If anybody has newgroup/mailing list archives from around that time, it
> would be very nice to see what that finds..

> Btw: there is some incidental "evidence" that that original 0.97 version
> of <linux/errno.h> is automatically generated: the thing looks to have
> very regular whitespace. It looks like it was generated with
> 
> 	#define\t%s\t\t%2d\t/* %s */
> 
> and then tab-corrected for the symbolic name lengths.
> 
> I've found some archives for linux-activists, but no newsgroup archives 
> going that far back.. Anybody?

Probably we have the same archives. I see the announcement

 From: hlu@yoda.eecs.wsu.edu (H.J. Lu)
 Subject: Re: gcc-2.2.2 patches for linux?
 Date: 19 Jul 1992 15:42:48 GMT

 This is gcc 2.2.2 for Linux. It is on banjo.concert.net under
 /pub/Linux/GCC. Gcc 2.3 will support Linux, according to RMS.
 ...
 The following functions are added to libc.a.
 ...
 4. lots of stuffs added to errno.h and string/errlist.c.

Andries

Re: SCO's infringing files list

[Erik Andersen]

On Mon Dec 22, 2003 at 03:19:04PM -0600, Tom Felker wrote:
> Where did the 0.97 to present version come from?

For errno.h, according to this:
    http://www.geocrawler.com/archives/3/360/1997/11/0/1999771/
I got Linus to add ENOMEDIUM and EMEDIUMTYPE into the kernel for
2.0.32, as part of my work on (what was to become) the Uniform
cdrom driver, based on original work from David van Leeuwen.
    http://www.ussg.iu.edu/hypermail/linux/kernel/9704.0/0105.html
I then helped push these defines into glibc and libc5.

So at least those two defines are clearly not SCO derived...

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: SCO's infringing files list

[Jesper Juhl]

One thing I noticed.

I'm looking at include/signal.h from linux-0.01 and the definition of the
signal() function, the prototype in include/signal.h is

void (*signal(int _sig, void (*_func)(int)))(int);

I then take a look in my copy of UNIX Network Programming by W. Richard
Stevens from 1990, and notice that he on page 46 says this :

"...
A process specifies how it wants a signal handled by calling the signal
system call.

#include <signal.h>

int (*signal (int sig, void (*func)(int)))(int);

..."


The return type here is "int" while Linus originally made the return type
"void". If Linus had copied signal.h from UNIX the return type would have
been "int"...

Re: SCO's infringing files list

[Luiz Fernando Capitulino]

Hi Jesper,

Em Seg, 2003-12-22 às 21:01, Jesper Juhl escreveu:
> One thing I noticed.
> 
> I'm looking at include/signal.h from linux-0.01 and the definition of the
> signal() function, the prototype in include/signal.h is
> 
> void (*signal(int _sig, void (*_func)(int)))(int);
>
> I then take a look in my copy of UNIX Network Programming by W. Richard
> Stevens from 1990, and notice that he on page 46 says this :
> 
> "...
> A process specifies how it wants a signal handled by calling the signal
> system call.
> 
> #include <signal.h>
> 
> int (*signal (int sig, void (*func)(int)))(int);
> 
> ..."
> 
> 
> The return type here is "int" while Linus originally made the return type
> "void". If Linus had copied signal.h from UNIX the return type would have
> been "int"...

 Seems to me the Linus version comes from Minix. Its return type is
void too:

http://www.minix-vmd.org/source/std/1.5/include/signal.h

-- 
Luiz Fernando N. Capitulino
<lcapitulino@prefeitura.sp.gov.br>
<http://www.telecentros.sp.gov.br>

RE: SCO's infringing files list

[David Schwartz]

	These files seem to mostly include information from standards documents and
most likely contain insufficient original creative content to justify
copyright protection. The particular order in which one lists the defines or
the numbers one assigns to them don't seem to be protectable to me, there's
no expression in them.

	I had a similar issue in a code review. In this case, the relevant RFC
actually named the constants and gave their numerical values. The numerical
values are used in the protocol and it's logical for multiple independent
groups to both choose to use the same names used in the RFC. So our code had
one header file -- a list of '#define's with the same names and numbers as
someone else's code (and the same as the RFC, of course). And guess what, we
both put them in numerical order too!

	Not bothering to look at the RFC, the code reviewer concluded that the
identical symbol names must have meant one of us took code from the other.
Duh.

	DS