A reader scanned in a page from the preface to his copy of John Lions' book, "A Commentary on the UNIX Operating System," and sent it to me for our Unix Books methods and concepts collection, which continues to grow. I think it's worth highlighting here too, if only to help us understand why IBM's lawyer, David Marriott, held up a copy of the Lions book to show the judge at a recent hearing during argument about methods and concepts. Whatever they are. I also wanted to put it here so the Unix Books project can link to it.
The language of the preface, and later, as you'll see, the copyright page, leads me to believe that oldSCO did not always maintain confidentiality in methods and concepts in Unix and that oldSCO appears to have known in 1996, which would be shortly after the Novell to Santa Cruz asset purchase agreement in the fall of 1995, that it didn't get the copyrights in Unix.
Take a look at the wording in the prefatory notes, to begin with, and you'll see that oldSCO not only did not block the book being published, it welcomed it. And take a look at why:
When this book was first published, I was astonished by how much pleasure I got from reading what should have been a dry piece of technical work. The UNIX operating system kernel code was itself an elegant work, and even today it remains worthy of study. John added a line-by-line analysis that was equally elegant. The source code and the annotations were perfectly suited to each other, and I haven't seen anything to equal this achievement since. A generation of operating systems developers used this work as a key learning tool, and I wonder just how much it influenced the ultimate UNIX domination of technical workstations, internet servers, and business-critical computing. At the time, the circulation was limited, because it was an annotation of licensed proprietary source code. I'm very pleased that this work can now be made available to the public. It is part of our technical history, and we can still learn from it today. --
Mike Tilson is President, UniForum Association and Chief Information Officer, The Santa Cruz Operation, Inc. (SCO).
That is another way of saying that the methods and concepts of Unix were used to educate the world's computer programmers, that they were encouraged to use it, to learn its methods and concepts, and to use them in the real world as they developed software. Today newSCO would have us believe that methods and concepts were carefully controlled at all times, subject to NDAs throughout history, but you can see from this preface that isn't so.
That last part, about the circulation being limited, was only partly true. It was certainly more limited than it would have been had it remained as it began, open source. But even with efforts to try to limit it (AT&T first gave permission and then changed its mind), copies of the book were widely distributed. As you will see in the continuation of the Prefatory Notes, Dr. Peter Salus called the Lions book "the UNIX systems' samizdat of the '70s and '80s." That means the book was passed from hand to hand, without ever having been officially published at the time. You may say folks shouldn't have done that, and without bothering to argue, let me just point out that from a methods and concepts standpoint, it doesn't really matter who let the dogs out. The only question with a secret is: is it still a secret? As Judge Debevoise phrased it in his famous Opinion in USL v BSDi, "Can any part of 32V possibly be
considered a trade secret, given that much of it is industry
standard and known to a generation of users and programmers?"
SCO's CEO, Darl McBride specifically told eWeek back in 2004 that their claims didn't include anything in this book as far as copyright infringement is concerned:
McBride: Before all of this is said and done, you'll see people saying that SCO already published a lot of this stuff in books but that these books contained copyright-protected materials.
Q:What book are you talking about? Lions' book?
McBride: No, that's ancient stuff. We're talking about recent stuff posted as a result of the BSD [Berkeley Software Design Inc.] settlement. There are things out there that help people understand how to program to System V application binary interfaces [ABIs], to help them hook up to the OS. It was out there to help people write applications. It wasn't published to help someone knock off the OS and create a free version of System V.
I guess back then he didn't realize they'd end up with pretty much nothing but methods and concepts to work with, if that, so he may not have grasped that his statement to eWeek would prove unhelpful later in a methods and concepts context. Because if their position is that they and their predecessors in interest were always careful to control methods and concepts and maintain their confidentiality, and I think that is their position, then this book, among others, stands in the way.
It also bears mentioning again that when he made that statement in April of 2004, the BSDi settlement was still a secret. Groklaw member dburns got legal permission to publish it in November of 2004, and we haven't heard anything further about that settlement from SCO, after the world was able to see for itself that there was little if anything in it that would benefit SCO.
When I compare the settlement with the Debevoise ruling, I see something else of interest in the methods and concepts category. The settlement was between the parties only, never filed with the court, and neither side acknowledged any rights the other had, but they agreed that going forward their behavior would be guided by the settlement terms. USL said this about what it had:
1. USL contends it is the owner of the intellectual property rights in portions of certain computer operating system software (the "UNIX System").
Portions? Why would it say portions? Likely because Debevoise had already told them that they'd lost the copyrights to most of it by not attaching copyright notices back when the law said you had to or you'd lose your copyright. If USL only had IP rights in portions of UNIX, what could it sell to Novell?
Anyway, in the settlement, USL listed a few files as "Restricted Files" and defined that category as files contained in Net2 which "USL contends contain materials from the UNIX System and/or use or disclose methods and concepts in the UNIX System and whose further distribution is restricted pursuant to this Settlement Agreement."
Berkeley was restricted from further distribution by the settlement, but you and I didn't sign that agreement. Net2 was what the BSDi litigation was essentially all about, but Debevoise noted that Net2 had already been freely downloaded by the public tens of thousands of times from UUNET before the litigation began, which from a methods and concepts perspective is disastrous:
An early Net2 licensee was UUNET, an electronic
information exchange for people interested in UNIX. (Adams Dep. at
149, Kennedy Aff. Ex. 12.) UUNET added Net2 to its standard
archives, enabling any subscriber to UUNET to freely and
anonymously copy Net2 to their own computer system. When asked the
number of people who had copied Net2 from UUNET, Mr. Bostic replied
that "I've been told it's in the tens of thousands." (Bostic Dep.
at 81, Id.). UUNET is available to hundreds of thousands of users
worldwide, including users in New Jersey. (Rorke Aff. ¶¶ 1-4.)
One organization that obtained Net2 from UUNET was BSDI.
(Adams Dep. at 149, Kennedy Aff. Ex. 12.) BSDI, which is not
licensed by AT&T to use UNIX, used Net2 to create its sole product,
the operating system BSD/386 Source. (Ans. & Countercl. at
¶¶ 5-6.) BSDI is now close to bringing BSD/386 to market, having
distributed preliminary "alpha," "beta," and "gamma" versions of
BSD/386 as well as promotional literature. This literature states
that BSD/386 Source "contains no AT&T licensed code" and "does not
require a license from AT&T." (1st Am. Compl. Ex. I.)
USL begged to differ and that's why it brought the lawsuit, but the judge noted that Net2 was out there, and with it, we today would note, the methods and concepts. There is no way to put them back, and that led the judge to end with these words:
A further consideration is that 32V's overall
organization may not even be protectable in the first place.
Berkeley's license to use 32V protects 32V derivatives only to the
extent that they contain certain proprietary information. If
Berkeley excises the proprietary information (as it attempted to do
with Net2), Berkeley is free to distribute derivatives without
restriction. Berkeley has utilized this freedom in the past to
distribute a number of non-proprietary systems and portions of
systems, all apparently without objections from AT&T. These
distributions, to some degree, must have disclosed the overall
organization of 32V. Thus, Berkeley's activities under the
licensing agreement, and AT&T's acceptance of those activities, are
evidence that Berkeley and AT&T interpreted the agreement to allow
the disclosure of at least some of 32V's organization.
In summary, I find that I am unable to ascertain whether
any aspect of Net2 or BSD/386, be it an individual line of code or
the overall system organization, deserves protection as Plaintiff's
trade secret. Since Plaintiff has failed to provide enough
evidence to establish a "reasonable probability" that Net2 or
BSD/386 contain trade secrets, I find that Plaintiff has failed to
demonstrate a likelihood of success on the merits of its claim for
misappropriation of trade secrets. No preliminary injunction will
SCO perhaps takes heart from this clause in the settlement:
c. USL agrees that it shall take no action against any person who utilizes any methods and concepts in the Restricted Files which as of this date have become available to the general public by acts not attributable to the University, its employees or students. Nothing in this provision shall limit USL's rights against a third party arising out of a breach of any license agreement with USL or AT&T.
That's perhaps why SCO tells us the IBM case is essentially a contract case. But IBM's license agreement, even if we ignore all the amendments and side agreements to it, states in clear English that if confidential material ceases to be confidential, IBM is free of any confidentiality requirements in the license:
7.06 (a) LICENSEE agrees that it shall hold all parts of the SOFTWARE PRODUCTS subject to this Agreement in confidence for AT&T. LICENSEE further agrees that it shall not make any disclosure of any or all of such SOFTWARE PRODUCTS (including methods or concepts utilized therein) to anyone, except to employees of LICENSEE to whom such disclosure is necessary to the use for which rights are granted hereunder. LICENSEE shall appropriately notify each employee to whom any such disclosure is made that such disclosure is made in confidence and shall be kept in confidence by such employee. If information relating to a SOFTWARE PRODUCT subject to this Agreement at any time becomes available without restriction to the general public by acts not attributable to LICENSEE or its employees, LICENSEE'S obligations under this section shall not apply to such information after such time.
To refine our thought, then, in the context of SCO v. IBM, it doesn't matter who let the dogs out, so long as it wasn't IBM. That's where the Unix Books project comes in, and I think McBride's remarks to eWeek give us an X on the map of what to dig for in particular, as do the filings in the litigation.
Here's the scan of the prefatory notes to the Lions book, so you can verify and also read the Salus remarks:
Here's part of what Jon "maddog" Hall, President, Linux International, wrote about the Lions book's distribution underground in his message to the media about the auction of a signed copy of the book now on eBay:
"John Lions" was a professor of computer science at the University of New South Wales, in Australia.
John believed that you could greatly improve a student's programming skills by allowing them to study the programming habits of really good coders, and with that thought in mind he proceeded to annotate the source code for Unix 6th Edition, to hand this out to his students. He had asked, and received, permission from the AT&T lawyers to do this, but in the end they rescinded their permission, and the book was never published.
However, a couple of preliminary copies got out, and were photocopied. Then those were photocopied, and those copies were photocopied. For a time it was a badge of honor to have a copy of the book "only five generations of photocopy" removed from the original. Some were so far down the generational tree that they could barely be read. I can not remember what generation my copy was, but it was pretty faint.
So, as you can see, UNIX has been influencing developers around the world since the '70s. John Lions was right. Programmers, like all scientists, do become better at their craft by studying the methods and concepts and ideas and implementations of others. It's why, I think, Linux progresses so rapidly and Vista, in contrast, is having so much trouble getting off the launching pad. What SCO would like to do is to block that scientific progress. McBride wrote to Congress once about the perceived danger of Open Source as a business model, but I think what SCO is proposing is what's dangerous. Outside the US, of course, no one pays any attention to SCO, and FOSS development will continue to progress no matter what happens. But if SCO, in some Alice in Wonderland upside down world were to prevail with this methods and concepts argument, it could set the US back in a way that could seriously damage the country's ability to compete.
Some may say, "If SCO had to give permission for this book to be published, then doesn't that prove that they held the copyright?" It's a legitimate question, and one I had myself. So I asked to see the copyright page. Look at the very odd wording:
Do you see a SCO copyright notice on that page? Me neither.
Does that wording look to you like SCO's lawyers even *thought* they held the copyrights to Unix? It says "portions" of the book were being published with SCO's permission, and then this very telling sentence follows:
extent SCO has an intellectual property interest in the material contained herein, SCO grants a license to publish..."
I think that wording tells us as clearly as if they shouted it from the rooftops that the SCO lawyers knew they didn't have the copyrights on UNIX except for any code they wrote themselves post-purchase, and they were consequently being very careful not to claim copyright in the source code in that book, because they knew they didn't have the legal right to do so. I see a copyright notice by the publisher. I see a copyright by John Lions, dated 1977. But there is no SCO copyright. The lawyers granted a license "to the extent" they had "an intellectual property interest," of an unspecified nature, because they didn't define what that interest might or might not be.
Isn't that interesting? My personal impression is that they knew they didn't have the copyrights but preferred not to tell anyone who thought they did, so they used weasel words. If they had the copyrights, this would have been the time to say so. And they didn't say so.
You can still buy this book on Lulu.com (and other places, not to mention some free downloads, if you know where to look) and on the Lulu.com page, it says this:
Lions' integration of UNIX source code with commentary is still used today as an operating systems textbook (e.g. at MIT inFall 2004!). As a self-study UNIX conceptual tutorial, it has informed and inspired computer professionals and advanced operating system students for almost thirty years.
Ah, that magic word: a UNIX conceptual tutorial.