decoration decoration
Stories

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

Groklaw Gear

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


To read comments to this article, go here
Turning our attention back to SCO v. IBM, a nugget about errno.h and the GPL
Saturday, July 26 2008 @ 04:20 PM EDT

Now that the Novell sideshow appears to be finished, subject to any appeals either side might bring (or even requests for reconsideration), I think it's time to turn our attention back to the main tent, and that would be SCO v. IBM, which will be ramping up in due time.

With that in mind, I found something that relates to two of SCO's claims, first that it can sue over header files and second that it never deliberately released any code under the GPL. It's a request for help on a message board back in 1999 from a user trying to compile something called R, which is a language and environment for statistical computing and graphics, a GNU project. It runs on Windows and BSD and UNIX and Linux, and he was trying to get it to work on Caldera OpenLinux 2.3. The individual posts the problem encountered, which seems to involve a missing errno.h for linux file, and guess where the solution turns up? On one of Caldera's CDs that the person hadn't installed yet:

The kernel-headers were not installed on my machine, but there is a package on the Open Linux 2.3 CD. I believe they weren't installed simply because I didn't choose to have all the development tools/libraries added when I installed linux. I didn't realize how soon I'd be compiling things.

2. The missing package that led to my posting to this list. It can be found on the COL install CD and is called linux-kernel-include.rpm.

I'll show you both of the messages in full, and explain why I think this proves that Caldera did distribute under the GPL, making up a special package which included header files, and it distributed errno.h and one presumes the others on purpose, knowingly.

Here's the original message, asking for help:

[R] make errors while compiling

Kieran Healy (kjhealy@princeton.edu)
Sat, 11 Dec 1999 00:50:28 -0500

Dear R users -

I am a first-time R user trying to compile v.0.90.0 under Caldera OpenLinux 2.3, on a Dell PII400/128. I've encountered a problem with the make file.

First, I run configure, which appears to complete properly. (I had to download an updated gcc library from caldera for this to happen though.) At the end of its run, config reports:

> R is now configured for i686-unknown-linux
>
> Source directory: .
> Installation directory: /usr/local
> C compiler: gcc -mieee-fp -g -O2
> FORTRAN compiler: g77 -g -O2
> Gnome support: no

Then I run make. It terminates after a few lines as follows:

[ -- some initial lines snipped -- ]
making Rsock.d from Rsock.c
In file included from /usr/include/bits/posix1_lim.h:126,
from /usr/include/limits.h:30,
from
/usr/lib/gcc-lib/i386-linux/egcs-2.91.66/include/limits.h:117,
from
/usr/lib/gcc-lib/i386-linux/egcs-2.91.66/include/syslimits.h:7,
from
/usr/lib/gcc-lib/i386-linux/egcs-2.91.66/include/limits.h:11,
from Rsock.c:28:
/usr/include/bits/local_lim.h:27: linux/limits.h: No such file or
directory
In file included from /usr/include/errno.h:36,
from Rsock.c:32:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
In file included from /usr/include/signal.h:294,
from Rsock.c:156:
/usr/include/bits/sigcontext.h:28: asm/sigcontext.h: No such file or
directory
make[3]: *** [Rsock.d] Error 1
make[3]: Leaving directory `/root/R-0.90.0/src/appl'
make[2]: *** [R] Error 2
make[2]: Leaving directory `/root/R-0.90.0/src/appl'
make[1]: *** [R] Error 1
make[1]: Leaving directory `/root/R-0.90.0/src'
make: *** [R] Error 1

[ -- end -- ]
The files make appears to be complaining about do exist on my system. In each case make seems to find the file (eg, /usr/include/bits/errno.h) but then complains seems to refer to a different directory -- linux/errno.h --- and says `No such file'. If linux/ and asm/ are meant to be directories with these files inside, they don't exist on my system. I've tried several clean installs and get the same result each time.

RPM says I'm using the following C and Fortran packages:
egcs-2.91.66-5
egcs-c++-2.91.66-5
egcs-objc-2.91.66-5
glib-devel-static-1.2.3-2
glibc-devel-static-2.1.1-1
glibc-devel-2.1.1-1
glibc-localedata-2.1.1-1
g77-2.91.66-6

I don't have much experience compiling files of this sort, so I can't interpret the error messages properly. I'd be very grateful for advice on what I'm doing wrong, and how to remedy it.

Thanks,

Kieran Healy

-- Kieran Healy email: kjhealy at princeton.edu
Department of Sociology
Princeton University
Princeton, NJ 08544-1010

A couple of people give advice and then the same person reports:

[R] Success compiling R on Caldera OL 2.3

Hello -

thanks to Prof. Ripley and Peter Dalgaard for their helpful responses. I have now successfully compiled R on my machine. The kernel-headers were not installed on my machine, but there is a package on the Open Linux 2.3 CD. I believe they weren't installed simply because I didn't choose to have all the development tools/libraries added when I installed linux. I didn't realize how soon I'd be compiling things.

2. The missing package that led to my posting to this list. It can be found on the COL install CD and is called linux-kernel-include.rpm.

Thanks again for quickly pointing me in the right direction. I'm looking forward to using R.

Kieran

Now, the part that makes it clear that Caldera had to know about those header files is in the advice given. Here's Prof. Ripley:

Prof Brian D Ripley (ripley at stats.ox.ac.uk)
Sat, 11 Dec 1999 07:47:22 +0000 (GMT)...

On Sat, 11 Dec 1999, Kieran Healy wrote:
> I am a first-time R user trying to compile v.0.90.0 under Caldera
> OpenLinux 2.3, on a Dell PII400/128. I've encountered a problem with the
> make file.

Well, not with the make file but with your system. On our RedHat Linux boxes, both asm/sigcontext.h and linux/limits.h are in the rpm kernel-headers-*, so I suggest you try installing that. However, again on our systems, glibc-devel requires kernel-headers. So either Caldera have got their dependencies wrong (and we have encountered missing files on Caldera systems before) or you did not allow dependencies to be installed. Try

rpm -q --requires glibc-devel
to see if kernel-headers is a dependency. I vaguely recall there are ways to check for any missing required packages on RPM-based systems, but as I have never had need of them, I can't recall the details.

Here's what I glean from this, keeping in mind that they were not missing, just placed elsewhere. Caldera didn't just take Red Hat's distro and redistribute it. It did things *differently*, so when it included errno.h in OpenLinux 2.3, I believe it had to have been deliberate and a knowing choice.

Now, I don't believe SCO has any claim to headers files like errno.h anyway, for many and detailed reasons we've published already, but here's what SCO claimed in its "Dear Unix Licensee" letter of December 19, 2003:

Certain copyrighted application binary interfaces (“ABI Code”) have been copied verbatim from our copyrighted UNIX code base and contributed to Linux for distribution under the General Public License (“GPL”) without proper authorization and without copyright attribution. While some application programming interfaces (“API Code”) have been made available over the years through POSIX and other open standards, the UNIX ABI Code has only been made available under copyright restrictions. AT&T made these binary interfaces available in order to support application development to UNIX operating systems and to assist UNIX licensees in the development process. The UNIX ABIs were never intended or authorized for unrestricted use or distribution under the GPL in Linux. As the copyright holder, SCO has never granted such permission. Nevertheless, many of the ABIs contained in Linux, and improperly distributed under the GPL, are direct copies of our UNIX copyrighted software code.

SCO's letter also dated December 19, 2003 to Linux users [PDF] used similar language and listed headers too. I think our nugget for today demonstrates holes in this SCO chunk of cheese, but the question of what code SCO was claiming it owned is vital here, because we need to know if it was claiming pre-1995 code, which it doesn't own, or later code it itself wrote. If AT&T made the release, it had to be prior to SCO having any ownership. That's obvious right there, just from the chain of ownership history. And anyway, you can find AT&T (or more exactly USL) making binary interfaces available in the mid-1990s. We know from the Jay Petersen presentation about SCOsource in 2003 that ELF had not been updated since 1990. Here's slide 9:

So that informs me that when SCO made the above claim to header files, I believe it had to have been talking about pre-1995 files that it turns out, as Utah's Honorable Judge Dale Kimball has ruled, it doesn't own after all. It's way too old for SCO to make any claim to it.

Incidentally, you can find the contents of Caldera's OpenLinux 2.4 here. And you'll notice this entry:

ld.so - 1.9.11 - MRBDH - The Linux dynamic loader ld.so provides the very basic routines to access dynamic ELF libraries for any dynamically linked program.

Here's an explanation of ld.so:

ld.so is the dynamic library loader. Each binary using shared libraries used to have about 3K of start-up code to find and load the shared libraries. Now that code has been put in a special shared library, /lib/ld.so, where all binaries can look for it, so that it wastes less disk space, and can be upgraded more easily. ld.so can be obtained from http://tsx-11.mit.edu/pub/linux/packages/GCC/ and mirror sites. The latest version at the time of writing is ld.so.1.9.5.tar.gz. /lib/ld-linux.so.1 is the same thing for ELF ("What's all this about ELF? ") and comes in the same package as the a.out loader.

So we don't have to guess about SCO distributing it. But since SCO are so persistent, and just in case they dream up some off-the-wall claim based on headers from code they do own...

... I thought this nugget might be a useful addition to the large mural Groklaw is painting of SCO's everlovingly endless phony baloney.


  View Printable Version


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

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