I started thinking about methods and concepts. Sometimes it's good to think simply. By that I mean, to think like a child, in the emperor-has-no-clothes sense.
Of course, there may not be any methods and concepts claims left in this case, after the current IBM motion to limit SCO to the few claims they were sufficiently specific about is done, thanks to Professor Randall Davis. But what if there were?
If I understand SCO's hints, SCO is asserting the right to control what IBM can do with its own code, on the basis of a contract which SCO claims covers derivative works and methods and concepts, unless someone else has revealed the method and concept first. That's probably why their expert, Marc Rochkind, was arguing that he didn't need to present code, only name technologies. That seems to indicate that they think the idea of how to do something is protectable, that IBM is contractually not allowed to reveal that idea or method of solving a computer problem to anyone. Again, that would have to be unless it's in the wild already and put there by someone else. That's why IBM's David Marriott showed the judge at the last hearing a copy of a book. Chris Brown, our eyewitness at the hearing, reported how Marriott used this book:
SCO claims that we've disclosed UNIX SysV release 4 internals, Marriott continued. He held up a book ("The Magic Garden Explained, The Internals of Unix System V, Release 4") copyrighted 1994. He said Unix internals have been in public for over a decade.
So, what else is out there?
Books about Unix
There are a lot of books about Unix. Here's just a small list reader Reginald Beardsley sent me of the books on his own bookshelf:
It might be helpful to archive the following list of
books on Unix methods & concepts somewhere on Groklaw.
I doubt that it's complete, but it's what I actually
own. This is just book length expositions on the
subject and doesn't include the numerous general
operating systems books or the myriad of technical
papers on various aspects of Unix.
The Design of the Unix Operating System
Bach, M. J.
The Design and Implementation of the 4.3 BSD Unix
Leffler, S.J.,McKusick, M.K., Karels,M.J., &
The Design and Implementation of the 4.4 BSD Unix
McKusick, M.K., Bostic, K.,Karels,M.J., & Quarterman,
The Design and Implementation of the FreeBSD Operating
McKusick, M.K., Neville-Neil, G.V.
Unix Systems for Modern Architectures
Mauro, J.,McDougall, R.
2001 Prentice-Hall (NB: 2nd ed in press)
Unix System Architecture
The Magic Garden Explained
Goodheart, B. & Cox, J.
As Beardsley says, "In the face of a vast body of open literature
describing the methods and concepts found in Unix it's
hard to argue that the emails from IBM staff were
discussing privileged information protected by
contract. The obvious counter argument to SCO's is
that the individual's employment by IBM is merely
incidental and that anyone, at any company, with
similar skills could have provided the same
information and guidance based on common knowledge."
That's just one man's personal collection. Feel free to add any other books and technical manuals you have in yours, by the way, including journal articles and Usenix conference papers, and I can add them to this list. What is most helpful are books about Unix System V release 4, not so much the earlier Unix versions, but we might as well make the list as complete as we can, since it speaks to whether SCO and its alleged predecessors-in-interest consistently and zealously acted to protect methods and concepts.
[ UPDATE: Someone just sent me a link to the search engine for the Library of Congress. I think we can find some fine additions to add to our collection there. Perhaps some might like to search by date, by SystemV4 or Unix or whatever you think would be useful.]
Did SCO and its alleged predecessors-in-interest consistently protect methods and concepts?
You'll note that one of the books listed was about Solaris, which is now open sourced. And another was about BSD. Now, thinking like a child, very simply, one could ask,
if it were true, as SCO alleges, that AT&T and all the later owners of Unix consistently and zealously protected methods and concepts, how did those two get blessed? It's not useful to say that they had a different license, I don't think, because once the method and concept is released, it is out there and anyone can use it. And if someone reproduces a method and concept which is the same in BSD or in Solaris and in SCO's Unix, how could you know if the method and concept came from BSD or AT&T or Solaris? Obviously, you couldn't. That's the thing about ideas. Once revealed, there is no taking them back. And you can't own them any more in the methods and concepts sense SCO is talking about. All this is based on what I think SCO is talking about. They haven't fully revealed their ...um...claim's methods and concepts.
And on the subject of whether or not AT&T consistently and zealously protected methods and concepts, as SCO alleges, you might enjoy reading this excerpt from "20 Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable" by Marshall Kirk McKusick, originally published in Open Sources: Voices from the Open Source Revolution, 1st Edition, January 1999, published by O'Reilly. When I read it, I ask myself, if SCO's theory about methods and concepts were true, how could there ever have been a BSD? How can there be an open sourced Solaris? And if there is a BSD and there is an open sourced Solaris, how can UNIX methods and concepts be controlled by SCO under any theory you wish to advance? Here's just a taste:
The final release from Bell Laboratories was 32/V; thereafter all Unix releases from AT&T, initially System III and later System V, were managed by a different group that emphasized stable commercial releases. With the commercialization of Unix, the researchers at Bell Laboratories were no longer able to act as a clearing-house for the ongoing Unix research. As the research community continued to modify the Unix system, it found that it needed an organization that could produce research releases. Because of its early involvement in Unix and its history of releasing Unix-based tools, Berkeley quickly stepped into the role previously provided by the Labs.....
The popularity of 4.2BSD was impressive; within eighteen months more than 1,000 site licenses had been issued. Thus, more copies of 4.2BSD had been shipped than of all the previous Berkeley software distributions combined. Most of the Unix vendors shipped a 4.2BSD system rather than the commercial System V from AT&T. The reason was that System V had neither networking nor the Berkley Fast filesystem. The BSD release of Unix only held its dominant commercial position for a few years before returning to its roots. As networking and other 4.2BSD improvements were integrated into the system V release, the vendors usually switched back to it. However, later BSD developments continued to be incorporated into System V....
The polished 4.3BSD system was finally released in June 1986. As expected, it quelled many of the performance complaints, much as the 4.1BSD release quelled many of the complaints about 4BSD. Although most of the vendors had started the switch back to System V, large parts of 4.3BSD were carried over into their systems, particularly the networking subsystem....
During one of our weekly group meetings at the CSRG, Keith Bostic brought up the subject of the popularity of the freely-redistributable networking release and inquired about the possibility of doing an expanded release that included more of the BSD code. Mike Karels and I pointed out to Bostic that releasing large parts of the system was a huge task, but we agreed that if he could sort out how to deal with reimplementing the hundreds of utilities and the massive C library then we would tackle the kernel. Privately, Karels and I felt that would be the end of the discussion.
Undeterred, Bostic pioneered the technique of doing a mass net-based development effort. He solicited folks to rewrite the Unix utilities from scratch based solely on their published descriptions. Their only compensation would be to have their name listed among the Berkeley contributors next to the name of the utility that they rewrote. The contributions started slowly and were mostly for the trivial utilities. But as the list of completed utilities grew and Bostic continued to hold forth for contributions at public events such as Usenix, the rate of contributions continued to grow. Soon the list crossed one hundred utilities and within 18 months nearly all the important utilities and libraries had been rewritten.
Proudly, Bostic marched into Mike Karels' and my office, list in hand, wanting to know how we were doing on the kernel. Resigned to our task, Karels, Bostic, and I spent the next several months going over the entire distribution, file by file, removing code that had originated in the 32/V release. When the dust settled, we discovered that there were only six remaining kernel files that were still contaminated and which could not be trivially rewritten. ....
Closing the gap from the Networking Release 2 distribution to a fully functioning system did not take long. Within six months of the release, Bill Jolitz had written replacements for the six missing files. He promptly released a fully compiled and bootable system for the 386-based PC architecture which he called 386/BSD. Jolitz's 386/BSD distribution was done almost entirely on the Net. He simply put it up for anonymous FTP and let anyone who wanted it download it for free. Within weeks he had a huge following.
SCO may say that they aren't talking about the early releases, but really, they are, when they offer the argument that AT&T consistently and zealously protected methods and concepts. Of course, the narrative tells the tale of the lawsuit regarding 4.4BSD and the settlement, which you can find on our Contracts page along with all the licenses discussed here, with the result that there was a "blessed" BSD from that point onward. If AT&T/USL really were serious about protecting methods and concepts, how could that ever be? Obviously, they didn't always assert control over methods and concepts in Unix, did they? By the way, in this connection, you might find this snip of interest, from the OSI Position Paper on the SCO vs. IBM Complaint, by Eric Raymond and Rob Landley:
Not only was old SCO far from unique as an Intel Unix vendor, but SMP Unix implementations date as far back as 1985. The Sequent Corporation produced machines featuring 2 to 30 80386 processors at that date. These machines ran DYNIX, a variant of Berkeley Unix.
Note it says Dynix is a variant of Berkeley Unix, not SCO's version. There's a nice chart on that page as well, showing the relationship between the various versions of Unix and Linux that star in this legal production. As for SCO's claims to the high-end stuff, they write this:
A major reason that the historical Bell Labs code base became nomadic among USL, Novell, and old SCO after 1990 is that it was already at that time senescent relative to newer Unixes like Solaris, Irix, HP-UX, Ultrix, and others. The Vax and 3B series minicomputers for which the late versions of the Bell Labs codebase were designed were years obsolete by 1995; the internal architecture of those variants of Unix is now primarily of historical interest. We noted previously that SCO/Caldera and old SCO made the “ancient Unix” Version 7 source code available for free, which rather disposes of the theory that the original Unix code had any residual IP value in the marketplace of today. (SCO belatedly terminated this offering on May 19th 2003, apparently realizing how badly it damaged their trade-secret claims.)
Furthermore, as previously noted, many Unix developers possess copies of SVr1 through SVr4 versions of the historical Bell Labs source code. We can therefore state that of the component technologies for enterprise scaling, the Bell Labs codebase includes a journaling file system (in the form of the VxFS Veritas journaling file system) and LVM (in the form of VxVM). But SMP for Intel processors only entered the line in 1995 with UnixWare 2. PCI hot-swapping came in only in 1998 with Unixware 7.
Ironically, UnixWare did not get usable SMP on Intel until after Linux. The UnixWare implementation was unstable  until mid-1997; Linux got working SMP in 1996 with the release of 2.0.
As for 64-bit support, Linux had this in 1994, five years before IBM became involved in Linux development. Neither of SCO's products has this capability yet in 2003.
In fact, not one of the key enterprise-scalability technologies was present in the ancestral Unix code before UnixWare got a JFS in 1992. SCO's complaint alludes to this: in paragraphs 46 to 48 they observe that it required three years of development (1995-1998) to ‘harden’ UnixWare for enterprise use. On SCO's own representation, the Bell Labs minicomputer-centered codebase of 1989-1995 is hardly more relevant to today's enterprise scalability challenges on today's PCs than the inner workings of a WWII-era jeep would be to the design of this year's Formula One racing cars.
SCO/Caldera's claim to own the scalability techniques certainly cannot be supported from the feature list of its own SCO OpenServer, a genetic Unix. The latest version advertises SMP up to only 4 processors (a level which SCO's complaint dismisses as inadequate), no LVM, no NUMA, and no hot-swapping. That is, SCO/Caldera is alleging that IBM misappropriated from SCO technologies which do not appear in SCO's own product.
SCO's reply would perhaps be that they control derivative works, so they get to control the methods and concepts in derivative works. Ah, but even if we posit that this were true, the question then becomes, derivative works tracing back to what? Raymond and Landley again:
On public evidence, not one of the five key technologies for enterprise scalability in Linux can plausibly be traced to historical Bell Labs code through IBM. These key technologies are:
symmetric multi-processing (SMP)
As we've seen, Linux SMP was worked up by Alan Cox and others using equipment provided by Caldera itself.
journaling file systems
IBM's Journaling File System (JFS) was contributed by IBM deriving from IBM's OS/2 and AIX operating systems, not from earlier Unix efforts.
Furthermore, Linux features three other journaling filesystems, contributed by Red Hat, Namesys, and SGI. Any of these three would be sufficient for enterprise scalability, and in fact the Red Hat EXT3 journaling system (and not IBM JFS) is the one in most common use.
logical volume management (LVM)
It is a matter of record that IBM's approach to LVM was rejected by Linus Torvalds in favor of a different approach. Accordingly, even if we were to stipulate that IBM had access to old SCO's LVM technology, any attempted misappropriation came to naught.
non-uniform memory access (NUMA)
IBM's NUMA work derives from the NUMA-Q technology of the former Sequent corporation and others such as SGI, NEC and Fujitsu, not the historical Bell Labs codebase or any SCO development effort (neither of which included NUMA). The extent to which the NUMA page credits non-IBM organizations should be noted.
Hot-swapping capability on PCs is dependent on special hardware capabilities. When the hardware supports it, hot-swapping tends to be natively and independently enabled by all modern Unixes (though not by the ancestral Bell Labs code).
SCO/Caldera's claim that IBM misappropriated SCO technologies for enterprise scalability should be evaluated in light of the following two facts: (a) The Bell Labs codebase contains neither LVM, nor hot-swapping; and (b) the SCO OpenServer codebase contains neither JFS, LVM, nor NUMA.
Generations have studied Unix in school
Let's credit SCO's perpetual control argument for the sake of this discussion, though. Let's agree just for this discussion (because I certainly don't agree) that SCO has a contractual right to force licensees to keep confidential all its methods and concepts, unless they are publicly revealed by others. If you go back in time to the early days, to the early educational licenses, you do find "methods and concepts" mentioned as protected, but note what Dennis Ritchie states on his page on old licenses and prices:
Prof. Karl Kleine at Fachhochschule Jena in Germany found and scanned some documents relating to the distribution of early versions of Unix, and kindly made them available.
The first (in PDF form) is the license issued to Katholieke Universiteit in Nijmegen, The Netherlands, in December 1974. They were one of the early educational users, and probably the same license was used for all the educational organizations at that time. Despite the name of the file, from the date of the contract, the license probably refers to the Fifth Edition system; the Sixth Edition manual is dated May, 1975. It's quite possible, however, that it was the 6th Edition that was actually delivered.
The license is full of boilerplate, but probably the important operative clause is that of 4.05, which effectively allows free use within the university, provided the users do not disclose outside the organization. Section 2.01 grants use "for educational and academic purposes only;" 4.05 requires the licensee not to disclose the software "or methods and concepts utilized therein," to anyone except employees or students as necessary for purposes granted. I believe that the wording allowed John Lions to teach his Unix course and prepare his famous Unix commentary, but that the terms were tightened up later to be more restrictive by the time of the Seventh Edition. However, I understand that the restriction against disclosing methods or concepts (as distinct from actual source code) caused ill-ease to some university lawyers. This restriction was indeed a bit peculiar: the concepts had already been published, for example in the C. ACM paper.
So not only were the methods and concepts released even before this license issued in 1974, indicating the horse was already out of the barn, according to Mr. Ritchie, this was a license to a university, to teach their students the very methods and concepts that SCO would like us now to view as super secrets that they can control. Practically every programmer on earth studied UNIX in school. They were able to do so because AT&T licensed UNIX to schools precisely so they would teach it. How do you get that knowledge out of their heads? To turn around now and claim infringement of methods and concepts that you aggressively promoted be taught in colleges and universities around the world is ridiculous, particularly if your proof is some email where one programmer explains how to do something. How to do something is what programmers learn in school when they study Unix. Again, this addresses SCO's argument that "they" consistently and zealously protected methods and concepts.
When oldSCO and Caldera employees contributed code to Linux, what happens to those methods and concepts?
And there's another issue, which I wrote about in August of 2005:
For one thing, they've already acknowledged in open court that there are no trade secrets in Unix, just in UnixWare. But here, regarding UnixWare, they face another problem: SCO needs to ask themselves the following question. When Santa Cruz wrote code and donated it to Linux, and they did, did they carefully separate their UNIX and Linux coders? If not, where might any similarities in methods and concepts come from? You'll remember, if you've been with Groklaw long enough, that Santa Cruz UnixWare kernel engineer Tigran Aivazian told Groklaw that he was also making contributions to Linux with approval from his boss:
"Yes, my very humble contributions to the Linux kernel (BFS filesystem and IA32 microcode update driver) done during my work as an escalations (UnixWare kernel) engineer at SCO were approved by our then-director Wendy Jones (who now works for Sun I think) and by higher management as well (I have bad memory on names, so I can't remember exactly, I think it was on Doug's level or so).
"For example in the case of BFS filesystem the matter was as follows. I did NOT use any of the UnixWare (or other) proprietary code for the implementation, of course. However, despite this fact, I still (for courtesy and generally being cautious) requested permission from Wendy (Development director) before the release under GPL and she confirmed that SCO has no claims to this work whatsoever and has no objections to its release under GPL, because it is not connected to UnixWare source code in any way."
There's just one example of oldSCO's relaxed practices. There was evidently no Chinese wall at Santa Cruz separating UNIX and Linux coders, yet now SCO Group is suing IBM and trying desperately to prove that its Linux coders were exposed to UNIX and thus any similarities would be actionable under the contract. See any problems with that logic, given Tigran's testimony? Me too.
Tigran isn't the only ex-SCO employee to state that there was no Chinese wall between Linux and Unix coders at oldSCO, and Tigran says his SMP contribution to the Linux kernel while employed by oldSCO was OK'd by oldSCO. How can you sue anyone for any SMP methods and concepts after that? It's out there. And if there was no Chinese wall, did oldSCO do its part in protecting methods and concepts? If not, how is that IBM's problem? One-time Caldera employee Christoph Hellwig contributed code to the kernel also. So, no matter how you slice it, SCO seems to be out in the cold on this tangent.
What if they mean methods and concepts under copyright law?
But, what if they have in mind to use copyright instead, using their novel but enunciated Vanilla Ice riffs theory? At that point, as we know, they run into the Novell pit bull lawyers, who are stating with firmness and conviction that they own the copyrights, not SCO Group, and that in any case, that this whole copyright ball of wax has to go to arbitration under the terms of the UnitedLinux agreements, which they say prevent SCO from suing anybody over copyrights in any technology in UL. Which is everything on the table.
Then there's the GPL. Because SCO released the materials under the GPL in UnitedLinux (and many distributions earlier), there is no taking it back. It is out there in public, all the methods and concepts. The horse is out of the barn. Or more accurately, all the horses left the barn a long time ago.
Dr. Peter Salus on SCO's copyright claims in SCO v Novell
But let's say, none of that happened. Copyrights are SCO's and that is their basis for controlling the distribution of methods and concepts. Then what?
In SCO's copyright claims in their Second Amended Complaint in the SCO v. Novell litigation, attached as Exhibit A to the Declaration of Kenneth Brakebill, SCO's Copyright Infringement claim reads in part like this:
111. SCO is the sole and exclusive owner of the copyrights in UNIX, UnixWare, and the associated supporting materials.
112. As shown on Exhibit A, SCO and its predecessors properly registered, at a minimum, copyrights in UNIX, UnixWare, and the associated supporting materials describing the UNIX system.
113. Pursuant to 17 U.S.C. § 410(c), SCO's certificates of copyright registrations constitute prima facie evidence of the validity of the copyrights and the facts stated in the certificates. SCO's registrations of its copyrights in UNIX and UnixWare are entitled to that statutory presumption.
114. SCO and its predecessors created and developed the intellectual property covered by the copyrights as original works of authorship, and as such, those materials automatically became subject to copyright protection under 17 U.S.C. § 102(a) when they were fixed in a tangible medium of expression.
115. Copyright protection under 17 U.S.C. § 106 extends to derivative works, which are defined in 17 U.S.C. § 101 to include works based on the original work and any other form in which the original work may be recast, transformed, modified, or adapted.
116. Novell has infringed and continues to infringe SCO's copyrights by copying, reproducing, modifying, sublicensing, and/or distributing Linux products containing unauthorized contributions of SCO's copyrighted intellectual property.
The list on Exhibit A begins like this:
UNIX Version 6 - TXu-511-236
UNIX V32 - TXu-516-704
UNIX Version 7 - TXU-516-705
SCO uses the Exhibit A list to justify their list on Exhibit B of items of alleged unauthorized copying:
Novell's unauthorized copying in its use and distribution of SuSE Linux includes but is not limited to the appropriation of the following data structures and algorithms contained in or derived from SCO's copyrighted material:
1. SuSE's implementation of the "Read/Copy/Update" algorithm
2. SuSE's implementation of NUMA Aware Locks
3. SuSE's implementation of the distributed lock manager
4. SuSE's implementation of reference counters
5. SuSE's implementation of asynchronous I/O
6. SuSE's implementation of the kmalloc data structure
7. SuSE's implementation of the console subsystem
8. SuSE's implementation of IRQs
9. SuSE's implementation of shared memory locking
10. SuSE's implementation of semaphores
11. SuSE's implementation of virtual memory
12. SuSE's implementation of IPC's
13. SuSE's implementation of load balancing
14. SuSE's implementation of PIDs
15. SuSE's implementation of numerous kernel internals and APIs
16. SuSE's implementation of ELF
17. SuSE's implementation of STREAMS
18. SuSE's implementation of dynamic linking
19. SuSE's implementation of kernel pre-emption
20. SuSE's implementation of memory mapping
21. SuSE's implementation of ESR
22. SuSE's implementation of buffer structures
23. SuSE's implementation of process blocking
24. SuSE's implementation of numerous header files
Leaving aside the fact that Novell is accusing SCO of fraud on the Copyright Office in its 10th Affirmative Defense,
we find SCO laying claim to copyrights in Unix and Unixware, including the early Unix versions. Dr. Peter Salus noticed that too, and here's what he writes in reaction:
The details of Exhibit A of "SCO's Second Amended Complaint" may seem
a bit bizarre. That's because they are. While the outline of
the early history of UNIX is in Chapters 2 and 3 of my book
["Salus Book" in the left margin of this site], a little
chronology may be helpful.
Exhibit A is the detail for SCO's "Fourth Claim for Relief,"
specifically "backup" for paragraph 112:
112. As shown on Exhibit A, SCO and its predecessors properly
registered, at a minimum, copyrights in UNIX, UnixWare, and
the associated supporting materials describing the UNIX system.
I'm not going to go into whether The SCO Group is the legal
"successor" to AT&T, but do want to clarify exactly what SCO
is laying claim to here.
Lines 2-4 of Exhibit A lay claim to "UNIX Version 6," "UNIX V32,"
and "UNIX Version 7."
From 1971 through 1979, AT&T Bell Labs produced documents reflecting
"snapshots" of the UNIX operating system. In general, they were
labeled "First Edition, ... Seventh Edition," referring to the text.
Sixth Edition, or "Version 6" appeared in May 1975. Bell Labs
authorized reproduction for sale by the USENIX Association a year
later. The Labs also approved of the reproduction of the code [!]
by John Lions at the University of New South Wales in Australia,
and of the publication of his "Commentary" on the code. The Lions
permission was later rescinded, but not before several hundred
copies had escaped to the US, Europe and Japan, where they became
the underground book for nearly two decades.
Though my copy of 6th Ed. carries a statement that "it has been
made available under licence from the Western Electric
Company," it nowhere carries a copyright by Bell Labs nor Western
Electric, but every column of code ends with "Copyright:
J. Lions, 1976."
The 1996 reprint by Peer-to-Peer Communications was with
the permission of both AT&T and of [original] SCO. The
copyright of John Lions was acknowledged.
Seventh Edition (=V7) appeared in January 1979. It is the
first UNIX to be called "The UNIX(TM) TIME-SHARING SYSTEM."
Chapter 17 of my Quarter Century of UNIX is devoted
to it. My copy bears the rubric: "Copyright 1979, Bell
Telephone Laboratories, Incorporated."
UNIX/32V was a late 1978 derivative of what would be released
as Seventh Ed. Released in June 1979, it was actually a
direct port of Seventh Ed. to the 32-bit VAX architecture.
It lacked paging. (swapping was added by Bill Joy at
Berkeley to enable Franz Lisp. Virtual memory was added at
Berkeley for the release of Bell Labs' System III.)
All of these pre-1986 systems were dealt with in the USL
v BSDI suit and the Novell - UCB consent decree.
So, unless SCO can come up with something I just haven't thought of, no matter how I think about methods and concepts, all I see is the horses left the barn long ago. Maybe it would be merciful if IBM wins its motion to toss the methods and concepts list out and this particular SCO effort is given a quiet but decent burial.