decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
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
The BSD Smokescreen by Dr Stupid
Thursday, February 19 2004 @ 04:33 AM EST

Here is an article by Dr Stupid on the subject of the copyright notices in the BSDi settlement files. After doing some research, he comes to the conclusion that whatever is in the sealed USL/BSDi settlement, it appears to be irrelevant to the Linux ABI files, because they do not appear to have been copied or derived from those in BSD. Here is his report, with his research.

Dr Stupid is a senior software engineer and describes himself also the 'licensing and IP man' at his UK firm, and he has been professionally involved in drawing up EULAs and licences for various products.


The BSD Smokescreen

~ by Dr. Stupid

SCO's mentioning the USL vs BSDi settlement in connection with their threatened actions against Linux end users gives the last section of an OSnews interview published earlier in the year fresh relevance. It gives a hint why SCO may feel the settlement gives them ammunition but it also helps to put that claim in perspective.

The interviewer asked some FreeBSD developers about SCO's allegations. This, you will remember, was back in April, when SCO had made vague noises that led some to think they might intend to go after the BSDs (and Apple in particular.) The status of the 4.4 BSD-Lite codebase, on which all the current open-source BSDs are built, is highly relevant to Linux, because in the past, the Linux kernel has drawn on code from the BSD-Lite kernel -- although there is very little overlap now between the Linux kernel and BSD-Lite.

Some pertinent quotes from the article:

"[There is BSD code derived] from Unix 6th and 7th edition, as well as 32V. Only the copyrights were similar to those used in System V source files. The code in question was merely blessed by USL and acknowledged as originating there by the Regents."

"There never was any System V code in any BSD. Ever."

The article includes a link to the original press release about the settlement. A quote from that press release gives a clue as to the terms of the settlement:

"The settlement restricts further use and distribution of certain files in the Second Networking Release and requires that certain files in 4.4 BSD-Lite include a USL copyright notice. In addition to providing several enhancements, the new 4.4 BSD-Lite Release will replace most of the restricted files and incorporates all the agreed-upon modifications and notices. Thus, 4.4 BSD-Lite will not require a license from nor payment of royalties to USL. The University strongly recommends that 4.4 BSD-Lite be substituted for Net2." [emphasis mine.]

The FreeBSD developers expanded on this:

"All files in the Mac OS or FreeBSD source trees that have USL copyrights are specifically covered under an agreement to settle the 1992 lawsuit between the University of California Regents and Novel [sic] (the folks that purchased USL while the lawsuit was going on). That agreement specifically stated that Novel, [sic] and its successors, would not sue anybody who based their systems on 4.4lite. FreeBSD is based on 4.4lite, and is therefore immunized against such legal action based on copyright claims. UCB, for their part, removed certain files, rewrote others and added the copyright notices to still others. FreeBSD has no code that infringes upon the SCO group's intellectual property." [again, emphasis mine.]

This interview states aspects of the settlement in a very clear and succinct way, and it makes some things clear. All USL code in BSD is derived from pre-SysV code. Therefore, any BSD code re-used in Linux is *not* SysV code, but based on so-called "Ancient Unix", which was released under a BSD-style licence by Caldera after the sealed settlement SCO relies on. That means that any action SCO could take over BSD code in Linux would be restricted to complaints about missing copyright notices (if there are any). A simple corrective action seems obvious.

Darl McBride spoke of copyright stripping in his Harvard talk but had hinted at the missing copyright notices angle some time ago in his comment regarding the piece of code reused from ancient unix by SGI, the infamous ate_utils.c:

"However, nothing can change the fact that a Linux developer on the payroll of Silicon Graphics stripped copyright attributions from copyrighted System V code that was licensed to Silicon Graphics under strict conditions of use, and then contributed that source code into Linux as though it was clean code owned and controlled by SGI." [emphasis mine.]

Most interestingly (for me at least) there is a hint about why SCO talks of rights with regards to the settlement.

"That agreement specifically stated that Novel, [sic] and its successors, would not sue anybody who based their systems on 4.4lite."

That statement could be taken to read (and SCO might assert) that Novell (and thus their successors in interest, which SCO claims to be) reserved the right to sue someone who violated the USL copyrights in systems not based on 4.4-Lite. In other words, it is conceivable that SCO may assert that it's acceptable to use this code in BSD, but not in Linux.
The reporters at Newsforge came to a similar conclusion in this article:

"Today we are leaning more to the view that SCO is going to claim that the 1994 settlement does not allow the use of Unix code in Linux, even if it was part of 4.4 BSD Lite."

SCO said something along these lines in their ABI letter:

"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."

Novell, who have an advantage over most of us in knowing precisely what was in the settlement, may well have a different interpretation from SCO.

In fact, code does not have to be released under the GPL to be included in Linux, merely a GPL-*compatible* license. The BSD4.4-Lite license, especially after UCB waived its advertising requirement, is GPL-compatible. So these header files could have been legally included in Linux without any further grant of permission from either UCB or USL's successor in interest. But as we shall see, this is a moot point since the headers are not and never were copied into Linux.

We can get further insight into the terms of the sealed settlement -- at least as far as they affected BSD -- from the release of BSD 4.4-Lite. This release had all encumbered files removed; any remaining code that had been written by USL was given permission to remain in BSD. One condition of the settlement (see above) was that a USL copyright notice had to be attached to those files which contained USL-written code.

BSD4.4-Lite is still available from various online archives (search for "4.4BSD-Lite.tar.gz" on Google.) Having obtained a tarball of the original BSD4.4-Lite sources, I located all the kernel source files with this USL copyright notice: 81 files out of about 2200.

Here is the copyright notice used in the files:

 * Copyright (c) 1991, 1993
 *      The Regents of the University of California.  All rights reserved.
 * (c) UNIX System Laboratories, Inc.
 * All or some portions of this file are derived from material licensed
 * to the University of California by American Telephone and Telegraph
 * Co. or Unix System Laboratories, Inc. and are reproduced herein with
 * the permission of UNIX System Laboratories, Inc.
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. All advertising materials mentioning features or use of this software
 *    must display the following acknowledgement:
 *      This product includes software developed by the University of
 *      California, Berkeley and its contributors.
 * 4. Neither the name of the University nor the names of its contributors
 *    may be used to endorse or promote products derived from this software
 *    without specific prior written permission.

Two things are immediately apparent:

1) There are no special additional restrictions on the redistribution of USL-derived BSD files, beyond the usual BSD-license stipulations.

2) In this version, the so-called "obnoxious advertising clause" is present; but note that even in the USL-derived files, the advertising clause doesn't mention USL by name, just UCB. That is, even a compliant use of the file (I'm ignoring for the moment the waiver that the FSF negotiated with UCB) would not feature USL in its advertising by name. You can draw your own conclusions as to whether USL would be in fact damaged by a non-compliant use.

Some of the files are extremely trivial, and it's hard to see how they could contain genuinely copyrightable material. In others, code has been deleted - presumably as part of the settlement terms. For example, in kern_acct.c the function acct_process() has a body with just the comment "Body deleted".

I take this to mean that the original body was removed as part of the settlement and just the "stub" left behind so that the kernel could still be compiled and used.

It seems fair to assume that USL's successors in interest could only pursue copyright suits with respect to these 81 files, since the remaining files in BSD bear no USL copyright. So the next question would logically be, Is there any code in these 81 files which also appears in the Linux kernel?

In October 2003, "Trepalium" did a Comparator run of BSDlite vs Kernel 2.6.
Original Groklaw Post

He found no line-for-line matches between Linux and the USL BSD-Lite code in the ABI area. On what basis, then, could there be allegations that Linux copied this code verbatim?

As a example of this, consider the acct.h file. Here is the body of the BSD-Lite version :

 * Accounting structures; these use a comp_t type which is a 3 bits base 8
 * exponent, 13 bit fraction ``floating point'' number.  Units are 1/AHZ
 * seconds.
typedef u_short comp_t;

struct acct {
    char    ac_comm[10];    /* command name */
    comp_t    ac_utime;    /* user time */
    comp_t    ac_stime;    /* system time */
    comp_t    ac_etime;    /* elapsed time */
    time_t    ac_btime;    /* starting time */
    uid_t    ac_uid;        /* user id */
    gid_t    ac_gid;        /* group id */
    short    ac_mem;        /* average memory usage */
    comp_t    ac_io;        /* count of IO blocks */
    dev_t    ac_tty;        /* controlling tty */
#define    AFORK    0x01            /* forked but not execed */
#define    ASU    0x02            /* used super-user permissions */
#define    ACOMPAT    0x04            /* used compatibility mode */
#define    ACORE    0x08            /* dumped core */
#define    AXSIG    0x10            /* killed by a signal */
    char    ac_flag;    /* accounting flags */

And here is the Linux counterpart:

 *  comp_t is a 16-bit "floating" point number with a 3-bit base 8
 *  exponent and a 13-bit fraction. See linux/kernel/acct.c for the
 *  specific encoding system used.

typedef __u16   comp_t;

 *   accounting file record
 *   This structure contains all of the information written out to the
 *   process accounting file whenever a process exits.

#define ACCT_COMM       16

struct acct
        char            ac_flag;                /* Accounting Flags */
 *      No binary format break with 2.0 - but when we hit 32bit uid we'll
 *      have to bite one
        __u16           ac_uid;                 /* Accounting Real User ID */
        __u16           ac_gid;                 /* Accounting Real Group ID */
        __u16           ac_tty;                 /* Accounting Control Terminal */
        __u32           ac_btime;               /* Accounting Process Creation Time */
        comp_t          ac_utime;               /* Accounting User Time */
        comp_t          ac_stime;               /* Accounting System Time */
        comp_t          ac_etime;               /* Accounting Elapsed Time */
        comp_t          ac_mem;                 /* Accounting Average Memory Usage */
        comp_t          ac_io;                  /* Accounting Chars Transferred */
        comp_t          ac_rw;                  /* Accounting Blocks Read or Written */
        comp_t          ac_minflt;              /* Accounting Minor Pagefaults */
        comp_t          ac_majflt;              /* Accounting Major Pagefaults */
        comp_t          ac_swaps;               /* Accounting Number of Swaps */
        __u32           ac_exitcode;            /* Accounting Exitcode */
        char            ac_comm[ACCT_COMM + 1]; /* Accounting Command Name */
        char            ac_pad[10];             /* Accounting Padding Bytes */

 *  accounting flags
                                /* bit set when the process ... */
#define AFORK           0x01    /* ... executed fork, but did not exec */
#define ASU             0x02    /* ... used super-user privileges */
#define ACOMPAT         0x04    /* ... used compatibility mode (VAX only not used) */
#define ACORE           0x08    /* ... dumped core */
#define AXSIG           0x10    /* ... was killed by a signal */

Now, there are similar symbol names (like AFORK and ac_uid) but they are needed for API (not ABI) compatibility. It is clear to me even on casual inspection, therefore, that the Linux file was not copied verbatim from BSD-Lite.

It is also worth pointing out that  there is no a.out.h file in BSD-Lite. There is an equivalent file, sys/tahoe/include/exec.h, which defines the same data structures as are defined in Linux's a.out.h file - but it has no USL copyright notice, only UCB.

What about the files that UCB agreed to remove from BSD-Lite? Although we can't see the settlement (yet), it is possible to obtain a shortlist by comparing the Net/2 version of BSD (which started the suit) and BSD-Lite to make an educated guess about the removed files.

Of those candidate files, only two seem to be even relevant as far as name and function is concerned: shm.c and shm.h. However, the Linux shm files and BSD shm files are very different. Moreover, people with access to both SysV and Linux confirmed for me that the shm files are different there, too. So again, there seems to be nothing to support an allegation that these files were copied into Linux.

The conclusion I have reached, then, is that whatever rights were granted to USL by the 1992 settlement over certain files in BSD, those rights appear to be irrelevant to the Linux ABI files listed by SCO. It also seems worth mentioning that the Linux coders were not a party to the sealed settlement, in any case.

  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 )