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.


Contact PJ

Click here to email PJ. You won't find me on Facebook Donate Paypal


User Functions

Username:

Password:

Don't have an account yet? Sign up as a New User

No Legal Advice

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

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Monday, March 01 2004 @ 05:30 AM EST

Here is UNIX Heritage Society's Warren Toomey's second article on the ABI files, as promised. The first, as you recall looked at errno.h. Now, it's time, he writes, "to turn our attention to SCO's assertion that signal.h was one of the files involved in the "line-for-line copying of UNIX System V code" which SCO alleges "improperly appears in Linux''.

To determine if their accusation is well-founded or not, we need to understand what signal.h is, what's in it, and a bit of its history.

It's important to point out that there are two versions of signal.h in most versions of UNIX ( /usr/include/signal.h and /usr/include/sys/signal.h), and as yet -- to the best of our collective knowlege -- SCO Group has not specified which, if either, is the file they claim has been improperly copied. The same is true of errno.h.

We have yet to see SCO list any "UNIX Derived Files" publicly, for that matter. The files SCO mentions in their Revised Supplemental Responses to IBM's 1st and 2nd Set of Interrogatories are all from AIX, Dynix and Linux, although on page 59 it references an Exhibit A that SCO says lists them. However, Exhibit A is not attached to the publicly available Revised Supplemental Responses, at least not yet. SCO has referenced UNIX files being attached to letters sent to their "dear Unix licensees" ("A complete listing of the UNIX Derived Files is attached"), but so far we have not heard of anyone actually getting the attachment with the letter. In Red Hat's most recent filing, they include the letter to Lehman Brothers, which also references the attachment, but again, there is no such attachment in the public court filing.

Has anyone who got a letter from SCO received this attachment listing "UNIX Derived Files"?

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

Signal.h
~ by Warren Toomey

Introduction

Following on from my report into errno.h in Linux, it's time to turn our attention to SCO's assertion that signal.h was one of the files involved in the "line-for-line copying of UNIX System V code [which] improperly appears in Linux'' and that "persons as yet unknown copied these files into Linux, erasing the USL copyright attribution in the process''.

In Unix and Unix-like systems, the underlying operating system can send a message to a running program to inform it of some exceptional event: a signal. The program's execution is diverted to a signal handler which deals with the event, before returning the program to what it was originally doing.

The sort of events that can occur are numerous: access to an 'out of bounds' area of memory, a divide by zero operation, a signal to stop executing from the user, etc. For (nearly) each signal type on the system, a running program can decide to ignore the signal, catch the signal and deal with it, or simply let the default Unix behaviour happen for that signal type. Most signals if uncaught result in the program being terminated, and the SIGKILL signal can never be caught: it is the "terminate with extreme prejudice'' signal in Unix.

To have a valid assertion that "line-for-line copying of UNIX System V code . . . improperly appears in Linux'' for signal.h, SCO needs to demonstrate that the signal names, their numeric values, any associated program comments and other function definitions could only have been directly copied from System V to Linux, and from nowhere else. Our job here is to track down the origins of signal.h in Linux.

What's in Signal.h?

What's in a typical signal.h file on most Unix or Unix-like systems? First of all, there is a set of defined signal names, their values, and possibly a C comment describing the signal. Systems which comply with the POSIX standard need to define about 28 signal names and associated numeric values; the values are not defined by the POSIX standard, but nearly every Unix and Unix-like system uses the same numbering scheme.

The earliest version of the signal name/numbering scheme still in existence is the nsys/param.h file from the 3rd Edition of UNIX in August 1973, with 12 defined signals. As Unix grew, so too did the number of signals, and by the 7th Edition of UNIX and the 32V distribution in 1979, the file now called signal.h had 15 signals.

By the end of the 1970s, there were already Unix clones like Idris and Coherent, and of course they also had to enumerate the set of signals. Not surprisingly, they followed the same numbering convention as Unix, as is shown by this file from Idris in 1978, where nearly all of the names and numbers are derived from 6th Edition UNIX.

This sort of code "cloning'' is exactly the thing that seems to make SCO see red. However, at the time AT&T asked Dennis Ritchie (one of the developers of Unix) to visit Coherent's makers [first link] and determine if the Mark Williams Company relied on Unix code when they wrote Coherent, Dennis determined that he "couldn't find anything that was copied'', and "what they generated was [...] reproducible from the [Unix] manual''. It must be remembered that the manual pages for Unix were published and publicly available; in fact, each new version of Unix was known by the edition of the printed manuals.

Dennis goes on to indicate that AT&T "backed off, possibly after other thinking and investigation [... and] so far as I know, after that MWC and Coherent were free to offer their system and allow it to succeed or fail in the market''. This decision and others like it, together with the publicly available enumeration of the signal values, allowed the Unix signal numbers to be used in many Unix clones and non-Unix systems such as:

The list is probably endless; hyperlinks to other examples of the Unix numbering in non-Unix systems can be posted as replies to this article.[1]

We've digressed from the topic of "What's in signal.h?'' to observing that the contents of the original Unix file was copied with AT&T's knowledge as early as 1978. Let's get back to what is in a typical signal.h file.

Along with the list of signal types, there is a list of operations that a running program can do when a signal arrives. Typically:

  • SIG_IGN (usually 0): ignore the signal
  • SIG_DFL (usually 1): use the default system behaviour, and
  • have the program handle the signal.
There is no numeric definition for the program handling the signal itself. Instead, signal.h defines a prototype for the signal() function. This system function takes two arguments: the signal number to catch, and the name of a program-specified function that will catch it. This program-specific function must receive an integer (the number of the signal that has arrived) but not return any value. These days, example definitions of the program-specific function and the signal() function might look like:

   typedef void __sighandler_t __P((int));
   sig_t signal(int sig, sig_t func);

Earlier versions of signal.h often rolled both definitions into one line, giving an unreadable definition like:

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

The behaviour of signals and their handlers in Unix has changed dramatically over time, and now the whole signal system is mind-bogglingly complex. The POSIX standard lists many, many more type definitions and function definitions that must be found in modern signal.h files.

Signal.h in Linux 0.01

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/signal.h. We have:

  • the usual #ifndef _SIGNAL_H, #define _SIGNAL_H ... #endif /* _SIGNAL_H */ combination to stop this file from being loaded into the compiler more than once;
  • an #include to bring in definitions of common C types;
  • definitions of two new C types:

    typedef int sig_atomic_t;
    typedef unsigned int sigset_t;          /* 32 bits */
    
    
  • the list of 22 signal names and values, plus a definition that NSIG (the number of signals) equals 32;
  • definitions for SIG_IGN and SIG_DFL:

    #define SIG_DFL   ((void (*)(int))0)   /* default signal handling */
    #define SIG_IGN   ((void (*)(int))1)   /* ignore signal */
    
    
  • a definition of a structure called sigaction, which is used to set a handler for a specific signal:

    struct sigaction {
         void (*sa_handler)(int);
         sigset_t sa_mask;
         int sa_flags;
    
    };
    
    
  • the definition of the names and values that the sa_flags field can take:

    #define SIG_BLOCK          0    /* for blocking signals */ 
    #define SIG_UNBLOCK        1    /* for unblocking signals */ 
    #define SIG_SETMASK        2    /* for setting the signal mask */
    
    
  • finally, the definition of a bunch of C library functions that perform signal-related operations:

    void (*signal(int _sig, void (*_func)(int)))(int);
    int raise(int sig);
    int kill(pid_t pid, int sig);
    int sigaddset(sigset_t *mask, int signo);
    int sigdelset(sigset_t *mask, int signo);
    int sigemptyset(sigset_t *mask);
    int sigfillset(sigset_t *mask);
    int sigismember(sigset_t *mask, int signo); /* 1 - is, 0 - not, -1 error
    */
    int sigpending(sigset_t *set);
    int sigprocmask(int how, sigset_t *set, sigset_t *oldset);
    int sigsuspend(sigset_t *sigmask);
    int sigaction(int sig, struct sigaction *act, struct sigaction *oldact);
    
    

Linux 0.01 vs Minix 1.5.10

If you're still awake at this point, then you are doing well. What sources of information did Linus use when he wrote this file? We saw that with errno.h, the most likely source of information was Minix 1.5. The evidence below suggests that Minix 1.5.10's signal.h was the source of inspiration for Linux 0.01 signal.h:

  • the same protective #ifndef ..., #define ..., #endif around the file;
  • the same definition of sig_atomic_t and nearly the same definition of sigset_t, except that the latter is promoted to 32 bits in size with a comment on this promotion in Linux 0.01;
  • the same definition of 22 signal names and numbers;
  • the same definition of SIG_DFL and SIG_IGN; and
  • the same definition of the sigaction structure.
There are some differences though. The Minix 1.5.10 file defines the signal functions differently to Linux 0.01; in particular, the parameter names are different (_set vs. set, _oset becomes oldset etc.). The parameter names are really for decoration here, and serve no purpose to the compiler, so perhaps Linus was not so keen on the Minix parameter names.

One important difference is the different definitions of the signal() function:

void (*signal()) (); in Minix 1.5.10

void (*signal(int _sig, void (*_func)(int)))(int); in Linux 0.01

One possible clue here is Linus' comment in the file that he is "trying to keep headers POSIX''. The POSIX standard defines the signal() function thus:

void (*signal(int, void (*)(int)))(int);
and Linus has followed the POSIX standard and also decorated his definition with parameter names.

Linux 0.01 vs System V R4

Let's now compare the Linux 0.01 signal.h file to the corresponding file /usr/include/sys/signal.h from the 1990 version of System V R4.0 for i386:

  • the same protective #ifndef ..., #define ..., #endif around the file, although the macro used is _SYS_SIGNAL_H not _SIGNAL_H;
  • no #include'd files;
  • sigset_t is defined as a structure containing an array of 4 unsigned longs called sigbits;
  • sig_atomic_t is not defined here, but it is defined in the /usr/ucbinclude/sys/signal.h file: obviously AT&T got it from the BSD distributions;
  • there are 31 signals numbered 1 to 31, with some different names to Linux 0.01:

    NumberLinuxSystem V
    7SIGUNUSEDSIGEMT
    10SIGUSR1SIGBUS
    12SIGUSR2SIGSYS
    16SIGSTKFLTSIGUSR1
    17SIGCHLDSIGUSR2
    18SIGCONTSIGCHLD
    19SIGSTOPSIGPWR
    20SIGTSTPSIGWINCH
    21SIGTTINSIGURG
    22SIGTTOUSIGIO

  • SIG_IGN and SIG_DFL are defined as per Linux but with the outside parentheses missing and no comments;
  • sigaction has an extra field: int sa_resv[2];
  • SIG_BLOCK, SIG_UNBLOCK, SIG_SETMASK: same values, no comments;
  • most of the C functions defined in Linux are defined in System V as C macros:

    #define sigmask(n)              ((unsigned long)1 sigbits[0])
    #define sigktou(ks,us)          ((us)->sigbits[0] = *(ks),  
                                     (us)->sigbits[1] = 0,  
                                     (us)->sigbits[2] = 0,  
                                     (us)->sigbits[3] = 0)
    #endif /* !defined(_POSIX_SOURCE) */ 
    
    
I think it's pretty obvious that Linus did not have access to nor use System V source code to generate his 0.01 signal.h file.

Since Linux 0.01, the signal.h file has changed and expanded somewhat, but even the signal.h file from the Linux 2.4.22 distribution still bears little resemblance to the System V signal.h file; even a cursory inspection shows that the Minix 1.5.10 signal numbers are still used here.

Postscript: errno.h Proliferates

At the beginning I mentioned that, as early as 1978, the signal names and values from AT&T's original signal.h file had been used in other systems. The same is true for errno.h. Here is an example list that I put together in about 30 minutes of searching on Google:

  • pe7sys.h from the port of C-Kermit to the Idris system on the Perkin-Elmer 7000. Copyright attribution to Whitesmiths Ltd. in 1978.
  • errno.h from the Microsoft Quick C compiler. Copyright attribution to Microsoft Corporation.
  • tclErrno.h from the Tcl source. This has copyright attributions to the Regents of the University of California and Sun Microsystems, Inc.
  • need_errno.h from a package called RandomDan. This has copyright attributions to Microsoft Corporation and may have been derived from a Microsoft C compiler.
  • errno.h from FreeDOS. Copyright attribution to Borland International.
  • errno.h from the LIVSIX package. Copyright attribution to Motorola and others.
  • arch.h from the lwIP package. Copyright attribution to the Swedish Institute of Computer Science.
AT&T did not put copyright notices on the "ABI files'' from 3rd Edition UNIX in 1973 up to and including the first release of System V in 1983. It makes you wonder, if Whitesmiths were putting copyright notices on their files in 1978, who really can claim copyright on the content of these files?


[1] These links are merely to demonstrate that the signal names and numbers have been used elsewhere. Copyright notices in the linked files should be observed. Copyrighted materials may not be used without the permission of the author.


  


Signal.h -- Part 2 of Warren Toomey's look at the ABI Files | 244 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: Greebo on Monday, March 01 2004 @ 06:01 AM EST
Another Excellent article. All praise to Warren Toomey.

So neither errno.h or signal.h came from system 5, and as PJ pointed out,
although SCO have claimed to send attachments in letters detailing "UNIX
derived files", no-one has actually seen them yet.

So, this doesn't really sound like a con job, does it?!



---
-----------------------------------------
Recent Linux Convert and Scared Cat Owner

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: grouch on Monday, March 01 2004 @ 06:13 AM EST
A bit of trivia:

The archive of linux -0.01, when uncompressed, shows a timestamp of "Sep 17 1991" for most files and directories, with the earliest file being linux/include/asm/memory.h at "Jun 15 1991".

In case it helps anyone's research (non-authoritative)
kernel-releases.html - html table of releases from announcement on Aug 25, 1991 to linux-2.2.26 on Feb 25, 2004.
kernel-releases - plain text of above, using tabs

[ Reply to This | # ]

  • d'oh! - Authored by: grouch on Monday, March 01 2004 @ 06:20 AM EST
Putting the lie to SCO's claim Re: Signal.h
Authored by: martimus on Monday, March 01 2004 @ 06:21 AM EST

At every turn, the evidence against SCO is compelling, clear and devastating to their claims. They cannot believe what they say is true with respect to any of the file copying claims they are making, with the possible exception of their claims against IBM for their perverse derivative claims in JFS et al.

I hope the Delaware court is looking at the evidence and is prepared to act in the manner that this evidence dictates, i.e. the desired (by Red Hat) injunction.

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: Anonymous on Monday, March 01 2004 @ 06:35 AM EST
Just want to say great work Warren, and to note that with this quality of
rebuttal, plus what the IBM folks can come up with themselves, this should stand
as a terrible warning to people that think they can throw random mud and try to
get it through by waving their hands.

I really hope we see this series centrally referenced in the court case.

[ Reply to This | # ]

If you want a good laugh...
Authored by: poncewattle on Monday, March 01 2004 @ 06:43 AM EST
Check out this "evidence" in favor of SCO's position on the Yahoo investing board.

A snipet:

My source tells me one of the original UNIX programmers was tasked with interleaving a sophisticated copy protection algorithm throughout the source code. The algorithm is fractal in nature so that the same signature appears whether you process a set of files, a single file or a single function."

This troll expert started a huge thread about it. Someone eventually took this phrase and determined where it originated:

My source tells me the programmer, a man by the name of Rambaldi, signed his work with a telltale string "<O>" however this too was encrypted so as not to give prospective filchers an unintended advantage

Turns out the guy is some 15th Century philosopher. Always fun to read a good troll on a lazy Sunday!

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: jmc on Monday, March 01 2004 @ 07:34 AM EST
Warren has done such thorough work as have so many people not forgetting
"the Great Goddess of Groklaw who never sleeps".

There are times when I think all this superb midnight-oil burning is almost
wasted on a two-bit outfit like SCO who surely won't see the year out.

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: Anonymous on Monday, March 01 2004 @ 07:38 AM EST
I believe SCO's claims to copyrights ownership of header files
is bogus in any case from a basic point of law viewpoint.

For example, I wonder if enumerations are copyrightable in
any case. There is no creative content in a series of numbers
associated with a series of names. Names or single words are
not copyrightable either. Neither is C syntax. Any comments
and indeed names that may be in the code don't affect it's
function, and are there merely for reference. Quoting
references and short quotations from copyrighted works is
permitted and is not an infringement of copyright - without this
it would not be possible write news articles or commentaries
on other publications for example.

[ Reply to This | # ]

Humans have memory too...
Authored by: CnocNaGortini on Monday, March 01 2004 @ 08:00 AM EST
A mapping between numbers and names could go from a file into human memory, and
from there into a file... when I was a grad student, I could only remember the
signal numbers, rather than the supposedly mnemonic names (I don't remember the
kill command taking names as an option back then, but I may just not have RTFM);
and I'm sure that that wasn't exceptional; in the late 80s / early 90s, I would
think that quite a few C programmers would have been capable of writing down a
usable signal.h from memory!

[ Reply to This | # ]

Interesting quote from the Yahoo scox message board
Authored by: Anonymous on Monday, March 01 2004 @ 08:04 AM EST
QUOTE
However, when asked what happened when his company was served with a request to
pay a SCO licence for Linux, panellist Ric Francis, Safeway's CIO, said: "I
told them to stick it. At the end of the day it is never going to fly. It's the
last dying breath of a company that is never going to make money."
ENDQUOTE

from:
http://www.siliconagendasetters.com/analysis2.html

[ Reply to This | # ]

tclErrno.h - details
Authored by: Kevin on Monday, March 01 2004 @ 08:04 AM EST
At last, something of which I have detailed knowledge!
tclErrno.h from the Tcl source. This has copyright attributions to the Regents of the University of California and Sun Microsystems, Inc.

The earliest two copyright dates in this source predate Tcl itself, whose development began in 1987. Indeed, inspection will show that the file was extracted (with attribution and preservation of the copyright notice) from two iterations of 4BSD. Since the alleged copyright holder in both cases was the Regents of the University of California, and presumably, Tcl as a whole was a work made for hire (John Ousterhout, Tcl's inventor, was a UCB professor at the time), I would presume that Tcl made use of those files with the consent of the University.

The later copyright by Sun Microsystems reflects John's move there in 1994. He brought Tcl with him, and continued to develop and release it under a BSD-like license negotiated jointly among him, Sun and UCB.

Only a few changes have been made to tclErrno.h since 1994. A few changes to boilerplate commentary were made to reflect a change of revision control from SCCS to RCS. EFTYPE, which Tcl does not require, was removed. The missing EOVERFLOW was added. TAB characters were replaced with spaces.

So this file's provenance can be traced directly to the Fourth Berkeley Software Distribution, and Warren's analysis can follow its history prior to that point.

I am not a lawyer. I am, however, a member of the Tcl Core Team.

---
73 de ke9tv/2, Kevin (P.S. My surname is not McBride!)

[ Reply to This | # ]

I think it's more important to realise...
Authored by: Anonymous on Monday, March 01 2004 @ 08:15 AM EST
...that whether or not we copied signal.h is irrelevant, because it's so minute and unimportant compared to the actual kernel code base.

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: ptarra on Monday, March 01 2004 @ 08:32 AM EST
This series of articles are really instructing. I enjoy
them very much as a "computer scientist amateur".

However there's something I don't fully understand. AFAIK,
SCO says that Linux kernels before 2.4.something are none
infringing, right? So, if the file hasn't changed or if
the changes are minimal from 2.4.something to
2.4.something+1 that's all set.

I find very interesting to learn about the origins of the
files, but... SCO admits this files are not infringing in
the origin. Am I missing something?

Regards

[ Reply to This | # ]

Signal numbers and scripts
Authored by: jamesw on Monday, March 01 2004 @ 08:38 AM EST
Some readers may not know that signals are frequently used from the command line, or from scripts, to communicate with running programs.

This is done with the kill command, which can take signal names or their equivalent numbers. Certain numbers have become well known, and they are often used instead of the name.

There is only one way to link number, name, and action for these well-known signals, or scripts are going to break.

IANAL, but this looks like a classic copyright defence.

I suspect that one could also draw in the user-interface angle: the Lotus case in the early 80s established that the way a user interacts with a UI was not copyrightable, and "kill -9 1" is a command any half-decent Unix administrator should know, and know NOT TO TYPE!

(It kills init, an essential part of any Unix).

[ Reply to This | # ]

OT: Everyone's Internet buys an IP license from SCO
Authored by: Anonymous on Monday, March 01 2004 @ 08:45 AM EST
This sucks -- no doubt sco is trying to pump their stock
again...

I wonder how many people will pull their hosting from
Everyone's ?

Cheers,

[ Reply to This | # ]

Latest SCO Press Release
Authored by: Windsurfer on Monday, March 01 2004 @ 09:03 AM EST
SCO signs up another sucker

[ Reply to This | # ]

Other signal.h and errno.h
Authored by: Thomas Downing on Monday, March 01 2004 @ 09:28 AM EST

In response to the invitation to post other non-Unix like OS's that have signal.h -

The wind OS from WindRiver (generally refered to as VXWorks) also has a signal.h and errno.h. This is a result of a POSIX compatibility layer offered as part of VXWorks.

A look at target/h/signal.h for x86 reveals that it is copyright 1984-1994 Wind River Systems, Inc. It does not apear to be a derivative of System V.

---
Thomas Downing
Principal Member Technical Staff
IPC Information Systems, Inc.

[ Reply to This | # ]

Suckers and also a GPL question
Authored by: Anonymous on Monday, March 01 2004 @ 09:38 AM EST
If SCO continues to succeed in signing up suckers for the IP licensing
program, can this affect the court cases at all?

Does this set a precedent of some kind that they can use in court?

Also, is there any way to find out what this company paid for this? It's
possible that behind the scenes The Darl is giving *huge* discounts to any
sucker willing to bite just to be able to say they sold one.

I personally expect more suckers to sign up. If you say "I own the IP to
<blank> and you better pay up" to the whole world, at least some
people will
be too cowardly or ignorant to stand up to you and someone is going to bite.

I think if this does not affect the court cases then it's a good thing. The
suckers can turn around and sue if the claims collapse. It also opens them up
to possible GPL infringement suits.

--------

Also a GPL question:

When Fyodor announced that SCO could no longer distribute nmap, some
moron stepped in and said that they would fork nmap and tell SCO that it
was OK for them to distribute the fork.

Can he do that?

If a group of Linux kernel programmers brought suit against SCO for selling
extra license terms for their technology, could someone just fork the Linux
codebase and do the same thing?

Is the GPL vulnerable in this way? Can GPL infringement suits be derailed by
someone simply forking the code?

Seems to me like a GPL-into-public-domain loophole has been found.

[ Reply to This | # ]

Trying to charge licenses based on include files is just plain stupid
Authored by: BubbaCode on Monday, March 01 2004 @ 09:38 AM EST
I am very familar with errno.h and signal.h, and even IF (and its a big if) SCO
claims to these files are true, a simple list of defines is hardly worth $100+
per CPU let alone $5 Billion from IBM.

These files are like "Klenex". Sure there is a Klenex brand but every
tissue is just called Klenex as a short hand because its so common.

So far this is just plain silly.

[ Reply to This | # ]

SCO Signs Intellectual Property License Agreement with Leading Dedicated Server Provider
Authored by: Richard Reynolds on Monday, March 01 2004 @ 10:01 AM EST
http://biz.yahoo.com/prnews/040301/lam082_1.html

Link

Dunno if anyone has posted this yet. If not it makes sad reading and there was so much good news today.

Lets hope EV1Servers.Net know what they have let themselves in for.

[ Reply to This | # ]

OT: New article about Groklaw
Authored by: Anonymous on Monday, March 01 2004 @ 10:05 AM EST
The LinuxInsider has a new article by David Halperin about Groklaw, titled "Writing Linux History: Groklaw's Role in the SCO Controversy"

http://www.linuxinside r.com/perl/story/32990.html

Dave H

[ Reply to This | # ]

OT: Stowell on Groklaw and PJ
Authored by: Anonymous on Monday, March 01 2004 @ 10:15 AM EST
http://www.linuxinsider.com/perl/story/32990.html

Conversions like that one help explain why SCO defenders take a dim view of
Groklaw. Blake Stowell, the company's director of public relations, says:
"I think the unfortunate thing about Groklaw is that many people reference
the site as a supposed 'credible resource' and take a lot of what is posted
there as the absolute truth. I find that there is so much misinformation on
Groklaw that is misconstrued and twisted that it's probably one step above a lot
of the ranting and dribble that takes place on Slashdot."

...

It may be that kind of intransigence that leads SCO's Blake Stowell to hint at
darker motives. "Doesn't anyone find it the least bit ironic," he
asks, "that Pamela Jones lives ... less than 10 miles from IBM's worldwide
headquarters, and that Groklaw is hosted, free, by a nonprofit outfit called
iBiblio, which runs on $250,000 worth of Linux-based computers donated by IBM
and a $2 million donation from a foundation set up by Robert Young, founder of
Red Hat?"

"Call me crazy," adds Stowell, "but I somehow think that Pamela
Jones isn't just a paralegal with nothing better to do with her life than host a
Web site called Groklaw that is dedicated to bashing SCO. I think there is a lot
more to her background and intentions than she is willing to reveal publicly. I
believe that Big Blue looms large behind Pamela Jones."

[ Reply to This | # ]

OT: SCO's new IP customer -- uses Red Hat
Authored by: Anonymous on Monday, March 01 2004 @ 10:21 AM EST
I see people are talking about SCO's new IP press release.

The new licensee uses Red Hat Linux

Check the front page of the ev1servers.net site (maybe somebody ought to get a
print out)

http://www.ev1servers.net/english/index.asp

[ Reply to This | # ]

Re: Signal.h & watermarks....
Authored by: NicholasDonovan on Monday, March 01 2004 @ 10:33 AM EST
Ahh... No. My company writes OS optimization code. The codebase for Linux is
too spreadout to do any deliberate watermarking of the type this person is
speculating.

IMHO SCO has no case and they know it. Young Darl's ego won't let it go though.


It must really suck to have missed your bonus call eh Darl?

This person who made this up obviously has stock in SCO or something?

Poor Guy ;-)


Cheers,


Nick





---
Not an Attorney.
Views expressed are my personal opinions and not necessarily those of my
employer or its affiliates.

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: StaticXCC on Monday, March 01 2004 @ 11:27 AM EST
http://news.com.com/2100-7344_3-5167308.html?tag=nefd_top

don't know if anybody noticed, but an hour ago, cnet posted an article that says
a company called EV1Servers.net bought linux licenses for roughly 20,000 linux
servers. personally? I think they got ripped off.

[ Reply to This | # ]

OT - SCO Signs Licenses with EV1
Authored by: Anonymous on Monday, March 01 2004 @ 11:37 AM EST
http://news.com.com/2100-7344_3-5167308.html?tag=nefd_top

"EV1Servers.net, a Houston-based company that hosts Web sites for clients
and a division of Everyones Internet, signed a deal with SCO for running
thousands of Linux servers without facing legal consequences from SCO.
EV1Servers.net didn't immediately respond to a request for comment."

So I guess that means that they have publicly broken the GPL agreement!

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: red floyd on Monday, March 01 2004 @ 11:43 AM EST
The signal names SIGTTIN and SIGTTOU show the Linux signal.h to be BSD derived
as well. These signals were for background job control, and existed as far back
as 1982 (Now where can I find my old 4.2BSD -- not NetBSD/FreeBSD/OpenBSD --
manuals to provide hardcopy confirmation?).

---
The only reason we retain the rights we have is because people *JUST LIKE US*
died to preserve those rights.

[ Reply to This | # ]

What?
Authored by: JustFree on Monday, March 01 2004 @ 12:01 PM EST
It looks as though someone has not been doing their research. It seem that SCO
has convinced "EV1Servers.net" to purchase an SCO Unix/Linux license.
Even with the mounting evidence that SCO is dead wrong in there assertion.

http://zdnet.com.com/2100-1104_2-5167308.html

http://finance.lycos.com/qc/news/story.aspx?symbols=NASDAQ:SCOX&story=200403
011331_PRN__LAM082

[ Reply to This | # ]

  • What? - Authored by: phrostie on Monday, March 01 2004 @ 12:34 PM EST
Infuriating to me was...
Authored by: Anonymous on Monday, March 01 2004 @ 12:19 PM EST
...Chris Sontag's remarks at Harvard when Darl and him were discussing the
header files. Despite Darl McBridge acknowledging they knew that Linus had
created some of the files themselves Chris Sontag stepped forward and says,
"But I still have problems with those files!"

Why? Because you're an idiot? Dear God somewhere, somewhen, I hope securities
fraud charges are pressed against these yahoos and they spend a great deal of
time learning how to create things from scratch inside a jail cell.

[ Reply to This | # ]

"Linux Insider" is anti-Linux
Authored by: Anonymous on Monday, March 01 2004 @ 12:19 PM EST
The publication is deliberately misnamed. So, you can assume that its content
will be equally deceptive.

[ Reply to This | # ]

Signal.h -- current
Authored by: Anonymous on Monday, March 01 2004 @ 12:31 PM EST
There seems to be sufficient evidence that at the outset the original signal.h
file was created by Linux with reference to openly available materials.

But what is the state of the current signal.h. Can we track the history of the
file? Has it been changed dramatically, or at some point been rewritten?

[ Reply to This | # ]

Trolling Pattern
Authored by: bruce_s on Monday, March 01 2004 @ 12:36 PM EST
Over the last few weeks there has been a lot of trolling
accusing Groklaw of losing focus and PJ being biased in
removing pro SCOX arguements.
It it interesting that Blake Stowell now raised the
accusation of PJ and Groklaw being "backed" by IBM. I find
that a bit too much of a coincidence?
Though a couple of months ago ESR mentioned on the
LinuxShow that he was also accused of being backed by IBM.

Bruce S.

[ Reply to This | # ]

OT: SCO - end user law suits, are, er, coming
Authored by: Anonymous on Monday, March 01 2004 @ 12:38 PM EST
http://www.newsfactor.com/story.xhtml?story_title=SCO_Lawsuit_Balloons_to____Bil
lion&story_id=23267

SCO announced in mid-November that it would launch legal action against
individual Linux users within 90 days, but the mid-February deadline passed with
no publicly announced action.

However, SCO has not abandoned its strategy. "Quite the opposite,"
says spokesperson Blake Stowell. "We're still looking at that," he
told NewsFactor, adding that SCO will make making an announcement very soon

[ Reply to This | # ]

SCO's PJ/IBM connection.
Authored by: photocrimes on Monday, March 01 2004 @ 12:42 PM EST
Well first, just a couple of things. How can anyone that is in technology NOT be
touched by IBM in one way or the other, I used to work for them for Christ sake!
I guess I'm now part of the conspiracy.

As for who this site is hosted with, did it ever strike Blake as odd that every
Linux hosted ISP wasn't beating down the door to help Groklaw out when the site
became overloaded with hits when PJ had it hosted with the other place?

I mean come on now, almost every major ISP out there utilizes Linux in one way
or the other.

But this brings me back to my point. Say Blake is right. Say PJ is an IBM mole,
IBM funded the site, the ISP, etc... heck maybe RedHat even chip'd in!

Does this somehow make SCO less guilty? Unless SCO can prove that Groklaw is
posting lies about them, and I doubt they can, why does it make a difference who
exposes them?

And don't forget SCO, you call this a "SCO bashing" site, yet seem to
ignore the fact that the bashers wouldn't even be given the chance to exist if
you hadn't given them a reason to hate you.

You create the "bashers" they don't just pop up out of nowhere.

---
//A picture is worth a thousand words//

[ Reply to This | # ]

SCO has publicly listed some alleged "UNIX Derived Files"
Authored by: Anonymous on Monday, March 01 2004 @ 12:48 PM EST

PJ writes:

We have yet to see SCO list any "UNIX Derived Files" publicly

I don't understand why you say this. SCO certainly hasn't proven that anything in Linux is derived from SCO-owned code without permission, but in their publicly released December 19 letter to Linux users, they did list seventy-one files in Linux 2.4.21 that they claim are "part of the UNIX Derived Files". See page two of sco.com/scosource/ abi_files_letter_20031219.pdf.

[ Reply to This | # ]

License
Authored by: Anonymous on Monday, March 01 2004 @ 12:56 PM EST
Some people talk about that the SCO license is voilates GPL license on linux.But
I think we sould be carefull. Note that the contract is vague and not verry
concrete. And that is not without a reason. I think that they try to claim that
they don't license GPL'ed code, but code that is illegal contributed and after
a lawsuit declared illigal licensed GPL.

[ Reply to This | # ]

OT: Something funny about the SCO press release?
Authored by: Anonymous on Monday, March 01 2004 @ 12:58 PM EST
http://biz.yahoo.com/prnews/040301/lam082_1.html

LINDON, Utah, March 1 /PRNewswire-FirstCall/ -- The SCO Group, Inc. ("SCO") (Nasdaq: SCOX - News), the owner of the UNIX® operating system and a leading provider of UNIX-based solutions, today announced an intellectual property licensing agreement with EV1Servers.Net, a dedicated hosting division of Houston-based Everyones Internet (EV1.Net). Under the terms of the agreement, SCO will provide EV1Servers.Net with a site license that allows the use of SCO IP in binary form on all Linux servers managed by EV1Servers.Net in each of its hosting facilities.


VERSUS:

http://news .com.com/2100-7344_3-5167308.html

SCO spokesman Blake Stowell declined to say how much EV1Servers.net paid but said the arrangement covered the "vast majority" of about 20,000 servers, and therefore got a high-volume discount on the $699 per single-CPU server that SCO asks.

Stowell said a "handful" of the world's 1,000 biggest companies have signed such licenses, but all have required confidentiality agreements. EV1Servers.net is the first that allowed its name to be used.
I'm not sure whether there is something funny, all vs vast majority (although I guess maybe vast majority means vast majority of servers at EV1Servers.net run Linux (and a minority run Windows etc), and these are covered

[ Reply to This | # ]

Here comes Waggoner Edstrom
Authored by: capitalist_pig on Monday, March 01 2004 @ 12:59 PM EST

Ok guys... here's the scoop.

Waggoner Edstrom is on the case. A comprehensive rhetorical attack on free software is being launched.

Check out this Slashdot article that appeared today.

My guess would be that the anti-OSS lobby is going to take a two-pronged approach. For the business side, they are going to put forward the pseudo-capitalist rhetoric of the McBride brothers. For the developer and end-user side, they are going to take a populist slant.

I'm actually surprised that we have not seen a populist attack on open source yet. Here it comes guys, so get ready. They are going to argue that:

- Open source destroys the value of programmers' labor
- Programmers who code OSS are putting other programmers out of work
- Programmers should stop coding OSS and start thinking from a traditional career value perspective (they will present this as an either-or choice)
- The OSS ideologues (Stallman et al.) want all software to be free (as in beer) and you to be out of work

The gimmick here is that they're trying to radicalize the debate and to portray both sides as slippery slopes. This is a way of herding people and excluding the middle.

The middle of course is that OSS represents a way for the free market to escape from the lock-in entrapments of commercial operating systems by commoditizing the basic OS and working environment of computing. In turn, this provides an open platform on which any kind of solution (commercial, free, hybrid, etc.) can be developed without the encumberance of proprietary lock-in to a single platform.

This is the reality and the excluded middle that they don't want you to see: FOSS as a free-market response to lock-in and a mechanism for constructing an open platform on which to build new levels of business and technology.

Also take a look at this excellent GrokLaw post. Read it carefully.

[ Reply to This | # ]

OT: Robert Marsh (CEO of E1servers.net) interview
Authored by: Anonymous on Monday, March 01 2004 @ 01:08 PM EST
http://news.netcraft.com/archives/2004/02/03/interview_ev1servers_ceo_robert_mar
sh.html

Q. You recently made a long-term commitment to Red Hat Enterprise as EV1Servers'
standard Linux OS going forward, and have also begun offering FreeBSD. What
factors guided your decisions on the "OS road map" for EV1Servers for
2004 and beyond?

A.Our number one consideration was long-term stability. For the majority of our
users, web servers are business tools, not unlike phone systems or copy
machines. They expect the equipment to work smoothly, and have no interest in
devoting significant time and attention to frequent updates. We felt that RHE's
12-18 month release cycle and 5-year support timeframe would best meet their
needs.

We also took into account our customers' feedback. While most were strongly
supportive of our selection of RHE, we also received a significant number of
requests for FreeBSD as an alternative. And that's what we now offer.

[ Reply to This | # ]

SCO is on the verge of winning where it matters
Authored by: capitalist_pig on Monday, March 01 2004 @ 01:23 PM EST
(This is a continuation of what I wanted to say above, but I decided to split it
up since it's a somewhat seperate topic.)

SCO may be on the verge of winning where it matters.

Here is how things might play out:

1) SCO gets some signups to their license deal from clueless morons and
ideological supporters. Given that their license-for-nothing is now available
for sale, it's virtually guaranteed that someone is going to bite. This gives
their case the appearance of validity.
2) The next step for them is to launch a flurry of lawsuits RIAA-style. Some of
the defendants will fights. These will be delayed in court (they don't want
these to actually go to trial). But, some will settle out of fear, weakness, or
ignorance.
3) SCO uses the fact that some have settled to intimidate the remaining
defendants and to try to establish some sort of precedent.

It's kinda like cold reading... you know the trick that psychics do? Watch
"Crossing Over with John Edward" sometime. The psychic throws out
hints into the audience... fishing... fishing... until someone bites. Once one
person bites, the psychic proceeds to use the tactics of cold reading
(suggestion, picking up on cues, asking questions that sound like answers, etc.)
to make it look convincing. Others begin to bite too at this point due to
herding behavior, and pretty soon you have a whole room full of believers.

Now, you might say, won't they eventually lose in the courtroom and the whole
thing come tumbling down? Maybe. But, in the meantime they will have
accomplished the ultimate goal.

The ultimate goal is not to win in some real and legal sense but to simply shoot
up the town. The goal is to intimidate major customers from using Linux for
anything important, and to herd people back to proprietary lock-in solutions.

Even if they lose eventually, a major legal shoot-em-up like this could damage
the credibility of OSS irreparably.

McBride's ancestors were cowboys, remember?

They might even ride off into the sunset after raping and pillaging the
townsfolk and never be heard from again. They could change their name and
business and sink under the waves, using their booty to buy their way into
another industry or sector of the market.

[ Reply to This | # ]

OT SCOG's New FUD and Licensee - See new article
Authored by: jdg on Monday, March 01 2004 @ 01:33 PM EST
PJ has just posted a new article on the FUD and SCOG's new licensee; post there
when appropriate.

---
SCO is trying to appropriate the "commons"; don't let them

[ Reply to This | # ]

header double include protection
Authored by: Anonymous on Monday, March 01 2004 @ 03:17 PM EST
* the same protective #ifndef ..., #define ..., #endif around the file;

That's really not very indicative they are related since just about every header
file has such protection.

[ Reply to This | # ]

signal.h - another example
Authored by: haegarth on Monday, March 01 2004 @ 03:25 PM EST
When I saw the reference to a Microsoft C compiler I rememberred that OS/2 in
it's early years had been develloped using such a compiler, so I searched my
harddisk for such a file.
Et voila: in C:OS2TK45hlibc I found a file with that name.
Since there's an IBM copyright notice in it, I won't produce it in full here of
course, but the relevant part looks like this:

...snip...
/* signal types */
#define SIGILL 1 /* illegal instruction - invalid function image
*/
#define SIGSEGV 2 /* invalid access to memory
*/
#define SIGFPE 3 /* floating point exception
*/
#define SIGTERM 4 /* OS/2 SIGTERM (killprocess) signal
*/
#define SIGABRT 5 /* abort() signal
*/
#define SIGINT 6 /* OS/2 SIGINTR signal
*/
#define SIGUSR1 7 /* user exception in range 0xa0000000 -
0xbfffffff */
#define SIGUSR2 8 /* user exception in range 0xc0000000 -
0xdfffffff */
#define SIGUSR3 9 /* user exception in range 0xe0000000 -
0xffffffff */
#define SIGBREAK 10 /* OS/2 Ctrl-Break sequence
*/

...snap...

Seems like SCO doesn't get a case out of this one, either.

Conclusion: if something like signal.h can even be found in a non-unixish OS
like OS/2, there's hardly a point in saying that any OS containing something
like this must be a derivative of... you know what.
No, I haven't forgot about SCO whining over JFS, but that's another story.

---
Where do you want to SCO today?

[ Reply to This | # ]

Signal.h -- Part 2 of Warren Toomey's look at the ABI Files
Authored by: Nick Bridge on Tuesday, March 02 2004 @ 12:18 AM EST
Perhaps even more interestingly, AIX doesn't used Sys V signal.h either!

Accordiing to this, AIX signal.h had diverted long before Sys V

[ Reply to This | # ]

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

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