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


Groklaw Gear

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

You won't find me on Facebook


Donate Paypal

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

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

On Methods and Concepts and Horses Out of the Barn - Updated
Sunday, April 30 2006 @ 11:22 PM EDT

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.
    1986 Prentice-Hall
  • The Design and Implementation of the 4.3 BSD Unix Operating System
    Leffler, S.J.,McKusick, M.K., Karels,M.J., & Quarterman, J.S.
    1989 Addison-Wesley
  • The Design and Implementation of the 4.4 BSD Unix Operating System
    McKusick, M.K., Bostic, K.,Karels,M.J., & Quarterman, J.S.
    1996 Addison-Wesley
  • The Design and Implementation of the FreeBSD Operating System
    McKusick, M.K., Neville-Neil, G.V.
    2005 Addison-Wesley
  • Unix Systems for Modern Architectures
    Schimmel, C.
    1994 Addison-Wesley
  • Solaris Internals
    Mauro, J.,McDougall, R.
    2001 Prentice-Hall (NB: 2nd ed in press)
  • Unix Internals
    Vahalia, U.
    1996 Prentice-Hall
  • Unix System Architecture
    Andleigh, P.K.
    1990 Prentice-Hall
  • The Magic Garden Explained
    Goodheart, B. & Cox, J.
    1994 Prentice-Hall

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'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 [41] until mid-1997; Linux got working SMP in 1996 with the release of 2.0[42].

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[43] 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[54], 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, here 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.


On Methods and Concepts and Horses Out of the Barn - Updated | 601 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
OT here
Authored by: SpaceLifeForm on Monday, May 01 2006 @ 12:05 AM EDT
Please use HTML where applicable.


You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Interesting you should say that ...
Authored by: Anonymous on Monday, May 01 2006 @ 12:10 AM EDT
This is a re-post of my comment on the previous story. As you succinctly put
it, the onus is on SCO to prove that the horse wasn't already out of the barn.
They haven't even tried.

Recycled Post Begins Here.

As Davis points out, they are talking at cross purposes. To prove that IBM
employees have disclosed methods and concepts, it is merely necessary to point
out emails in which they have done so. Rochkind has done that. (Don't flame me

However, he has two problems:

1 - Judge Wells was quite specific about what she was willing to accept. She
wanted to see great specificity. No problem. This just gives SCO something they
can base an appeal on. The breach of the contract was that the method or
concept was disclosed. Period. It shouldn't be necessary to show that someone
then used that method or concept.

2 - Even if we accept that SCO should be able to claim that methods and concepts
were disclosed based just on the evidence of emails, it is reasonable that they
should be able to prove that those methods and concepts were protected by the
contract. In that regard, they have to show two things: A - The method or
concept disclosed was unique to the product covered by the contract. The logic
behind this is simple. If the contract prevented disclosure of any method or
concept used in the product, then IBM would be forbidden to talk about any kind
of programming to anyone. Obviously ridiculous. B - An IBM employee was the
first to disclose that method or concept. AT&T agreed that IBM could talk
about methods and concepts that had already been revealed.

Marc Rochkind made no attempt to prove A or B above for any of SCO's claims. He
has proven that IBM employees did discuss methods and concepts used in the
protected product. He has the emails. Unfortunately for him, that's not enough.
He hasn't presented any evidence that any of the emails actually breached the

I think (IANAL of course) that Judge Wells can still pitch out these claims even
if she does grant SCO that it isn't necessary to show that the methods and
concepts made it into Linux. (OK now you can flame me if necessary.)

[ Reply to This | # ]

Authored by: artp on Monday, May 01 2006 @ 12:20 AM EDT
For the benefit of all.

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 12:36 AM EDT
I have always believed this is about claiming others' property as their own. The
object is to set a precedent, thereby allowing a certain segment of the
investment community to reap the rewards of others' ideas and labor, at very
little cost to themselves. If they can make this bird fly then it opens the
doors for many similiar claims.

By defeating IBM, they will have knocked out the financial and legal giant of
the industry. Everyone else will not be able to withstand the onslaught, without
massive volunteer effort over an extended period of time. Microsoft may already
have protected itself as part of the settlement agreement. We do not know is
stated in that document.

There are many proprietary companies as well as the various open-source and
free-software projects that could be victimized by future lawsuits. Methods and
concepts in derivative works, are very vague. What would qualify? Just about
anything that is able to execute on more than one system. After all the Unix
Operating System and the programs developed to run under its control was the
first successful to function on more than one computer system.

It seems to me that one of the officers of SCO made the statement "C++, we
own that too." If they win, will they attempt to pursue that also.

I think SCO may have had a better chance to win $5 billion in Las Vegas or Monte
Carlo. Russian Roulette would give them better odds at surviving.

[ Reply to This | # ]

Methods, Concepts and Copyright
Authored by: MrCharon on Monday, May 01 2006 @ 01:03 AM EDT
Are Methods and Concepts covered under copyright? My understand is they are not
directly covered.


[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: dmarker on Monday, May 01 2006 @ 01:18 AM EDT

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

Just read the above excerpt & my 1st thought was that the 80386 came out
later than 1985, in any commercial quantities. But it was a long time ago &
I may be forgetting. However, I believe it could have been designed in that

Any one else with a good long memory ?


[ Reply to This | # ]

Conference Papers
Authored by: rand on Monday, May 01 2006 @ 01:53 AM EDT
Ok, here's one that not only revealed many of the "secret" inner workings of UNIX, it also has a special surprise (sorry it's so long, but it's worth it, I promise! )

This is the record for TX-5-787-679 found at the U.S. Copyright Office. The Special Code 1/C means that this is a computer program. This is one of the registrations SCOG submitted in order to bring this case. You can see the original form at Docs/IBM/Doc-100-A-H.pdf

Registration Number: TX-5-787-679
Title: UnixWare 7.1.3.
Description: Software package.
Note: Printout also deposited.
Claimant: [Author and claimant] SCO Group, Inc.
Created: 2002
Published: 5Dec02
Registered: 11Jun03
Previous Related Version: Prev. reg. 1987, TXu 300-346.
Claim Limit: NEW MATTER: rev. computer program.
Special Codes: 1/C

Here's the problem: if you register a derived work with the Copyright Office, you are supposed to indicate that fact on your form, along with some kind of citation of the existing work. For instance, some of the System V registrations that SCO Group and Novell are fighting about include "Prev. reg. 1992, TXu 510-028", which indicates they are derived from Unix 5th Edition, written Richey and Thompson for AT&T and registered by USL (the lower-case "u" indicates that it was unpublished at the time of the registration). We can assume that SCO Group understands this responsibility, as it plays such an important part in their current Complaints.

In this case, UnixWare 7.1.3 is derived from an earlier work registered as TXu 300-346:
Registration Number: TXu-300-346
Title: UNIX system software readings.
Description: 182 p.
Claimant: [Author and claimant] T & T Unix Pacific Company, Ltd.
Created: 1987
Registered: 14Aug87
Special Codes: 1/B/D

[NOTE: Yes, there appears to be a typo ("T & T" instead of "AT&T") in the original.]
Have you seen it yet?

First, 182 pages seems pretty small for any version of the UNIX operating system.

Next, AT&T Unix Pacific was a sales organization, not a programming group. They were one of several distribution and support groups that disappeared over time, after being passed along from AT&T to USL and later, Novell (AT&T's USO Renamed USL).

And, if you follow the Special Codes link above you'll discover that this is ("1") a nondramatic literary work or computer program and ("B") a "Nondramatic textual work, including volumes, leaflets, pamphlets, folders, sheets, nonbook textual materials, papers prepared for oral delivery" . ("D" means a copy was sent to the copyright warehouse.)

What is this? A computer pamphlet? Maybe a speech about computers? What's going on here?

With more Googling and searching at the Library of Congress you can find the pertinent LOC records. This is the literary work on file at the Library of Congress that corresponds with TXu-300-346. Look it over very carefully.
LC Control Number: 87071070
Type of Material: Book (Print, Microform, Electronic, etc.)
Main Title: UNIX System software readings/ AT&T Unix Pacific Co., Ltd
Published/Created: Englewood Cliffs, N.J. : Prentice Hall, c1988.
Related Names: AT& T Unix Pacific Co.
UNIX System Software Technology Seminar (1986 : Tokyo, Japan)
Description: v, 182 p. : ill. ; 23 cm.
ISBN: 0139383581 (pbk.)
Notes: Proceedings of UNIX System Technology Seminar, held on July 1 and 2, 1986, in Tokyo, Japan.
Subjects: UNIX (Computer file)--Congresses.
LC Classification: QA76.76.O63 U5535 1988
Dewey Class No.: 005.4/3 19

Yep, according to this, Unixware 7.1.3 is a rewrite of a conference report. Paperback, no less.

Brian Kernighan, who, along with Dennis Ritchie, wrote The C Programming Language, was there in Tokyo and presented the keynote speech, Beyond Unix (#59 on his bibliography).

There's one other surprise here. UNIX System Software Readings is actually listed in Attachment E to the Novell-SCO Assett Purchase Agreement. It's here on Groklaw, sandwiched in with a bunch of old Unix manuals listed in the Attachment. That line is almost unreadable in the original PDF, so I missed it at first. Is it possible Darl et al couldn't read it either, and thought it says "Unix System Software" and thought it meant all UNIX system software?

The wise man is not embarrassed or angered by lies, only disappointed. (IANAL and so forth and so on)

[ Reply to This | # ]

Forgetting the $ echo newsletter
Authored by: brian on Monday, May 01 2006 @ 02:30 AM EDT
Another obstacle for SCO to overcome is the $ echo
newsletter that "clarifies" AT&T's position on code
developed by the licensees. Code developed by the licensee
belongs to the licensee is a paraphrase of what it says.
SCO has to also show that IBM didn't develop that code but
it was in the ORIGINAL codebase. That newsletter clears
any code IBM developed on its own.


#ifndef IANAL
#define IANAL

[ Reply to This | # ]

Streams publications
Authored by: Anonymous on Monday, May 01 2006 @ 02:34 AM EDT
AT&T Bell Labratories Technical Journal
"A Stream Input-Output System"
Dennis Ritchie, 1984 Vol. 63, pp. 1577-1593 Oct. 1984

Proceedings of the 1989 Summer USENIX Conference, Baltimore MD
"Out-of-Band Communications in STREAMS"
S. Ragos, 1989

"UNIX System V Release 3.2 - STREAMS Primer"
Prentice Hall, 1989

"UNIX Streams Release 3.2 - STREAMS Programmer's Guide"
Prentice Hall, 1989

Proceedings of the 1986 Summer USENIX Conference, Alanta, GA
"A Framework for Networking in System V"
D. Olander, G. McGrath, R. Israel, 1986
note->This is the orginal paper to describe the implmentation of STREAMS and
TLI in System V.

"Unix Network Programming"
W. Richard Stevens, 1990
Prentice Hall Software Series

note->The Prentice Hall Software Series had Brian W. Kerningham as an advisor
for the series.

[ Reply to This | # ]

All that discovery
Authored by: kawabago on Monday, May 01 2006 @ 02:49 AM EDT
And all they come up with is methods & concepts that are ubiquitous in the
community. Sure would be nice to charge SCO with Unreasonable Search &

[ Reply to This | # ]

What about Rochkind's books
Authored by: thorpie on Monday, May 01 2006 @ 03:02 AM EDT

I am extremely curious about what is contained in Rochkind's books. I mean with titles such as 'Advanced Unix Programming" one would hope that there would be something useful, which generally means is not commonly known. This seems to be what SCO and Rochkind are claiming to be their protected Methods and Concepts.

Of course if Rochkind's book doesn't contain anything not commonly known you would wonder why he bothered publishing it?

Just a cursory scan of some items listed in Exhibit B as being included improperly in Novell's version of SUSE and the contents of Mr Rochkind book shows some matches, such as:

  • 7.8 - On Semaphores;
  • 4.9 - Steams I/O;
  • 2.12 - User Buffered I/O
  • numerous mentions of locks.

Then again it may be that he didn't know anything about these subjects until he found out about them through Novell's and IBM's release of the information! In which case I am certain such an upstandingly correct person would have obtained Novell's and IBM's permission to mention and use their Methods and Concepts.

The memories of a man in his old age are the deeds of a man in his prime - Floyd, Pink

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: geoff lane on Monday, May 01 2006 @ 03:26 AM EDT
The Bell System Technical Journal, July-Aug 1978, Vol 57, No 6, Part2 is all about "Unix Time-Sharing System"

It contains a number of papers describing the design of Unix. ie.

The UNIX Time-sharing System.


The UNIX shell

Portability of C programming language and the
UNIX System

UNIX on a Microsprocessor.

The UNIX Operating system as a base for

A couple of other books that concentrate on Unix programming philosophy...

The UNIX Philosophy by Mike Gancarz ISBN 1-55558-123-4

The Art of UNIX Progamming by Eric S. Raymond ISBN 0-13-142901-9

I'm not a Windows user, consequently I'm not
afraid of receiving email from total strangers.

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: mtew on Monday, May 01 2006 @ 04:08 AM EDT
While the POSIX standards are requirements and specifications rather than
implementations, don't they cover most if not all of the concepts underlying
UNIX? I'd not be surprised if a method or two for implementing the various
requirements were included as examples or sugestions as well.


[ Reply to This | # ]

concerning algorithms
Authored by: seraph_jeffery on Monday, May 01 2006 @ 05:20 AM EDT
I must apologize, because I cannot remember where I read this, but some judge
(some place) recently ruled that mathematical and computational algorithms
cannot be copyrighted or patented. If you are first to publish, then the
academic community will give you credit for your work, but whether or not
there's money to be gained is doubtful. Now, in programming, every subroutine
really is just an implementation of an algorithm of some sort. It should be
possible to copyright a particular implementation, but not the fact that the
algorithm was implemented. That's the difference here between some vague
"methods and concepts" vs. "finding code." That is, in my
humble opinion...

[ Reply to This | # ]

Original methods and concepts by SCO?
Authored by: Chris Lingard on Monday, May 01 2006 @ 06:13 AM EDT

There were many systems that pre dated UNIX, so the methods and concepts are unlikely to be wholly original. About the only one that I can speak knowledgeable about is the British Ferranti Argus 700 system; but there will be many other examples.

This system was developed in Manchester, England in the late 1970s. If was for the new 16 bit machine, the Ferranti Argus 700.

There were many features equivalent with modern methods and concepts. It had paging, memory was incredibly expensive so programs and data could be rolled in and out of memory, (similar to swapping). The complex peripherals, were channels; they accessed common memory to the cpu, (often referred to hard wired), and once the program had set up the data, the channel was activated by a "go channel" command. These were controlled by interrupts, that had multi level priorities. It had a timer queue, such that programs could be activated at known intervals; and it had networking.

Whatever secret method or concepts SCO had introduced into their system, it is very likely that it is not original. There was about 25 years history predating UNIX. Also, there would be SCO design team documentation for these methods and concepts; and there is no history of any such research done at Caldera or SCO.

[ Reply to This | # ]

Can this be dismissed in summary judgement?
Authored by: Anonymous on Monday, May 01 2006 @ 06:18 AM EDT
I've previously expressed the opinion (which keeps getting deleted, for some
reason) that SCO have in fact been in full retreat during discovery - right back
to a carefully prepared trap. By sandbagging IBM and Judge Wells at the 11th
hour with new methods and concepts claims, they've tricked IBM into preparing to
defend against those claims, rather than take the riskier last minute gamble to
try to have the grounds for complaint thrown out entirely.

Even if IBM gets some or all of the contested claims dismissed - for inadequate
specificity, remember - the methods and concepts cat is out of the bag, and SCO
will just bring it back again and again during trial. Remember, once this gets
in front of a jury, it'll be largely academic who's right and who's wrong, it'll
be (in the plan according to SCO) about hand wringing and mawkish "Poor
little local SCO picked on by big out of State bullies" entreaties.

However, is it actually too late for IBM to deal with the methods and concepts
claims in the way that you've just outlined, and move for summary judgement to
have them ruled on and dismissed? I know that discovery is closed, but I'm not
sure whether IBM have enough on the record to go for dismissal of all methods
and concepts claims, or whether they even can at this stage.

So, where next for IBM? A swathe of summary judgement motions, or straight to

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Steve Martin on Monday, May 01 2006 @ 06:57 AM EDT

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 how could there be an open-source license for 16-bit and 32V UNIX?

"When I say something, I put my name next to it." -- Isaac Jaffee, "Sports Night"

[ Reply to This | # ]

SEC filings do not lie either - Santa Cruz Operations admits in SEC filings the opposite of SCOx
Authored by: Anonymous on Monday, May 01 2006 @ 07:01 AM EDT
Santa Cruz Operations ADMITS to others competing due to open standards etc in SEC Filings!

Yep - not until Caldera took over did we hear about "owning UNIX".

The SEC filings are the next thing to sitting in the stand and giving testamony in court.  You can not lie to the SEC.

Sample of SEC filing:

ALSO - newSCO SEC UNIX language is not found in ANY Santa Cruz Operation SEC filings!
Authored by: PJ on Sunday, October 31 2004 @ 08:40 AM EST
What an intriguing comment. Since you have done the research, obviously, why
don't you either post the links or send to me. If not, I'll follow though, and
I'm sure others will too, but if you have a collection of facts already, why not

PJ's comment from 10-31-2004 and posts that followed with SEC language quoted by oldSCO (Santa Cruz Operation )

Below is a sample from examples... Again, ALL, 100%, of the the SEC filings made by newSCO's predicessor, Santa Cruz Operation, are always refering to UNIX as being out there in the open and that competition was something that they had to deal with.  They never ever say that they "OWN UNIX", they always say pretty much the opposite!

"[Begin Quote from Groklaw Post about oldSCO SEC 1996 filing]

"Because customers are increasingly reluctant to be restricted to a single
computer vendor, the Company has designed its software products to support
industry-accepted open systems standards. Open systems are those systems which
conform to established industry standards such as XPG-4, Spec 1170, DCE and
OSF/Motif(R) from The Open Group, POSIX(R) from IEEE, and Federal Information
Processing Standard (FIPS) from the National Institute of Standards (NIST). SCO
continuously works with standards organizations such as The Open Group to
assure continued conformance to open systems standards. Industry standards may be
established by organizations composed of vendors, by government agencies, by
academic institutions, or by market acceptance. Industry standards typically
are based on specifications which allow competing implementations. Because these
standards are open, competitors can readily access the technology to include in
their products. Industry standards offer the customer a cost-effective computing
solution by providing a high degree of compatibility and interoperability among
hardware, software, network and peripheral products.


[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 07:34 AM EDT
Never played with any of the earlier Sequent offerings, but I can confirm that
around 1988 they were SMP 386 boxes. And they _flew_. Well, for the time,
anyway. We had a couple in my department at the London Stock Exchange, one of
them powered the TOPIC system. Lovely bits of kit. Fairly blew me away that if
you were running out of horsepower you could just "bang another processor
board in".


[ Reply to This | # ]

Interesting book not in your list.
Authored by: Anonymous on Monday, May 01 2006 @ 08:26 AM EDT
Dear PJ,
I own a book which is quite interesting. I think it should be in your list.

"UNIX Internals A practical approach" by Steve D. Pate

Published in 1996, it has a foreword by Gary Daniels, then oldSCO's Vice
President (Platform Products Division), whose last sentence is: "By
providing the means for users to gain practical insight into the UNIX kernel
without access to source code, this book presents a new and innovative approach
which I am sure will appeal to all UNIX enthusiasts."

The preface introduction starts with: "This book describes the internals of
SCO OpenServer Release 5, the version of the UNIX operating system supplied by
The Santa Cruz Operation."

And indeed the book is very detailed: never showing source code, the Author
swims through the flow of control of OpenServer using debuggers and describing
data structures. Methods and concepts. And gems like a detailed description of
ELF in chapter 6, too.

Have a nice day.


[ Reply to This | # ]

You don't even need the books
Authored by: Jude on Monday, May 01 2006 @ 08:42 AM EDT
A lot of Unix methods and concepts can be deduced from nothing more than a
working Unix system.

Every Unix-like system I have ever seen has had a /usr/include/sys directory
that was chock-full of header files that defined kernel data structures and
related constants. These systems also provided /dev/mem and /dev/kmem
pseudo-devices that permitted any process with suitable privilege to access
memory and inspect real examples of these structures being used.

I did this a lot myself, and the only difficulties I ever encountered were the
nuisance of dealing with pointers from a foreign address space and the fact that
the structures could change while I was looking at them. It only took me a few
minutes to understand these problems, and less than an hour to devise ways of
dealing with them. I was then able to examine the inner workings of my kernel
at will.

I was pretty much of a novice when I first started doing this. I succeeded
despite my limited skills at the time. All that was needed was enough curiosity
to spend some time writing fairly simple code. I assume many other people were
able to do the same things.

Unix was like a clock with a transparent case: Anyone could easily see how the
thing worked. I'd be laughing at SCO's attempts to claim the workings were
secret if they were not doing so in a courtroom.

[ Reply to This | # ]

My personal all-time favorites
Authored by: inode_buddha on Monday, May 01 2006 @ 09:46 AM EDT
"UNIX Power Tools", by Jerry Peek, Tim O'Reilly, and Mike Loukides. O'Reilly, ISBN 1-56592-260-3.

"Introduction to Operating Systems" by Ann McIver McHoes (lots of Lovelace, Djikstra, and Knuth quotes/examples)

SAMS "UNIX System Administration"

SAMS "Teach Yourself C In 21 Days"

SAMS "Teach Yourself TCP/IP In 24 Hours"

SAMS "Linux Programming Unleashed"

"Real World Linux Security" by Bob Toxen (great read!)

These books date from the 1980's or 1990's, esp. the first editions. I consider them to be essential to truly be a *nix/Linux power user in this day and age. Also (just for PJ) the entire contents of the man pages and the entire contents of the Linux Documentation Project (the "HOWTO's" and "Guides" are my favorites, I keep local copies. You too can download them in tar.gz format, or whatever you prefer such as Postscript or html.)....

And let's not forget, the UNIX Guru Universe, USENIX and SAGE, and a great collection of links.

My point is this: There is *tonnes* of material out there and available to anyone at little or no cost other than time and bandwidth. Further to the point, one could replicate any sort of halfway decent *nix system with the above-menioned materials, all of which are public knowledge. Not easy, but it *could* be done. Alternatively, you can spend a few dollars and buy or print it all in book format. I did just that. Even the hardware manufacturers [Intel] publish these things.

So really, what's the big deal?

Copyright info in bio

"When we speak of free software,
we are referring to freedom, not price"
-- Richard M. Stallman

[ Reply to This | # ]

  • Incudes ... - Authored by: Anonymous on Monday, May 01 2006 @ 11:35 AM EDT
My favourite quote....
Authored by: tiger99 on Monday, May 01 2006 @ 10:58 AM EDT
"As for 64-bit support, Linux had this in 1994....."

Therein lies what this is in part about. In many ways, Linux is so far in advance that SCO Unix in all its forms is just a bad joke. Installation and configuration tools are another area, one of many.

PJ's work is invariably of a high standard, but today's article is an absloute masterpiece.

[ Reply to This | # ]

Old computer books
Authored by: mikeprotts on Monday, May 01 2006 @ 11:17 AM EDT
I have a copy of "The Encyclopedia of Coumputer Science and
Engineering" Second edition (c) 1983 Van Nostrand Reinhold Company Inc.
ISBN 0-442-24496-7.

This is a large encyclopedia (bought second hand from a library) and is over
1600 pages. It includes some details on Unix, and in the section on operatin
systems, "A Model of Multitask Systems" describing how an operating
system works. I think there would be sufficient detail to create a full OS
based on this description.

I also have a copy of "UNIX The book" (c) 1982 MF Banahan and A
Rutter, reprint 1990 ISBN 0 905104 21 8.

This is mainly aimed at the user, but with details for the techie types and
programmers. It includes details of the standard library calls, system calls
and the error and signal numbers and names (taken from errno.h and signal.h).


[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 12:00 PM EDT
you forgot the Rochkind book. he discusses IPC on p10, introducing semaphores
and shm. he goes into detail on semaphores on p185. BTW, it was copyright

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 12:03 PM EDT
"Unix Internals" Shaw, M. C. and Shaw S. S. 1987, McGraw-Hill, Inc.

It includes system calls and signals.

[ Reply to This | # ]

This history is irrelevant
Authored by: DMF on Monday, May 01 2006 @ 12:12 PM EDT
The historical excursion may be interesting, but it is not germane to the case. The only way TSG can make claims to control 'methods and concepts' is through whatever contracts they have with IBM. They have asserted no patents, copyright doesn't cover m&c, and they have dropped all trade secret claims.

M&c being in the wild does not matter if the contract is read to restrict it. Unless there is specific language, there can be no specific exception, e.g. for publicly known m&c. (And if there were specific langauge, you can bet all you have that IBM would never have signed the contract.) If the contract is found to restrict m&c, then IBM is bound to protect it whether or not it is available elsewhere.

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 01:36 PM EDT
for Methods and Concepts... "Failure to state a claim upon which relief can
be granted" bzzzzt

for Copyright ... "lack of substantive proof of ownership, lack of
specificity, failure to apply the Abstraction, Filtration, and Comparison
tests." bzzzzt

A stock Pump and Dump scheme... priceless.


[ Reply to This | # ]

UNIX book: Lions
Authored by: rsmith on Monday, May 01 2006 @ 02:07 PM EDT

One of the earlier books is "A commetary on the sixth edition UNIX operating system" from 1977, by Dan Lions.

This was a textbook from the University of New South Wales, but it was widely illegally copied. It was posted on Usenet in 1994. Every UNIX hacker worthy of the name at that time had a Nth-generation copy of the Lions book.

It seems that AT&T never bothered very much to halt the spread of this book. It would have been useless anyway, especially after the book got loose on Usenet.

Later Caldera gave permission for it to be distributed, along with some ancient UNIX source code (V1 -V7 & 32V). I have a copy of the book, the 32V source code and a license for the code.

Unfortunately the pages with the old material (including the permission to redistribute the book) seem to have been taken down from SCOG's website.

Intellectual Property is an oxymoron.

[ Reply to This | # ]

It's about the meaning of "derivative".
Authored by: Jaywalk on Monday, May 01 2006 @ 02:10 PM EDT
SCO's reply would perhaps be that they control derivative works, so they get to control the methods and concepts in derivative works. ... 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.
This argument ignores SCO's twisted definition of "derivative". To SCO, once code has been added to a UNIX variant -- in this case, AIX -- it is now "derivative" UNIX and must be kept secret. So it was the code IBM wrote that IBM was supposed to be kept secret. That's not what "derivative" means -- either in law or plain English -- so it's a bit like an M.C. Escher drawing; by constantly referring to "UNIX" and leaving off whether you're talking about System V or AIX you can make it appear like code which started in one place actually started in another. As long as you keep focusing on one part of the drawing or another, it appears to make sense.

However, also like an Escher drawing, it doesn't bear close inspection of the whole. IBM threw a monkey wrench into the plan by demanding that a line be drawn from System V through AIX to Linux. But the line actually starts in AIX, so SCO fell back to the "methods and concepts" line to obscure that fact. Note that the Rochkind chart appears to start some of the lines with an email from a UNIX person to someone working on Linux. That obscures whether the code started in System V or AIX. Since the code is never quoted, there is no way to tell.

Of course, that meant that SCO's description of the transfer of code was -- as Davis points out -- pretty sketchy on the code. But SCO's only other choice was to explain to the judge that they were actually claiming ownership of something they didn't write and didn't buy. Code they didn't even have in their possession until they got it from IBM. Imagine how that little gem would have been received.

===== Murphy's Law is recursive. =====

[ Reply to This | # ]

Another Book by W. Richard Stevens
Authored by: Anonymous on Monday, May 01 2006 @ 02:28 PM EDT
TCP/IP Illustrated, Volume 2: The Implementation
Gary R. Wright, W. Richard Stevens
ISBN 0-201-63354-X
second edition, 1995

On more than 1100 pages, it contains the complete source code for the TCP/IP network stack of 4.4BSD-Lite Distribution (heavily commented), together with an excellent index.

from the preface:

A special thanks to the consulting editor, Brian Kernighan, for his rapid, thorough, and helpful reviews throughout the course of the project, and his continued encouragement and support.

Addison-Wesley sells a boxed edition of the whole series that comes with a poster showing the most important data structures and relations between them.

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: math geezer on Monday, May 01 2006 @ 02:44 PM EDT
One pair of things not yet mentioned are:
UNIX Review and
UNIX World
Both were "popular" magazines that discussed Methods and Concepts as
well as containing source code.
These are "available" on the web, and someone produced CD's of back
issues- I think it was the then new owner of Dr.Dobbs' Magazine (IDG?).
Even old Byte magazine had M&C and during XENIX popularity, Windows Tech
Journal had articles on M&C.
There was also a ROOT magazine, I forget what that morphed into.

[ Reply to This | # ]

Books Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 04:25 PM EDT
After SOC victory's win
they will sue Prentice-Hall

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 04:45 PM EDT
Shouldn't any list of books that would make it difficult to claim Unix M&C
are protectable contain;

"Structured Computer Organization", by Andrew Tanenbaum, (c) 1984,
ISBN 0-13-854605. This book talks about a lot of fundamental methods and
concepts, it talks about Multics *and* UNIX.

I know that the list is bound to be long, but any competent college text book on
Operating system design and implementation will contain discussions of the
methods and concepts in UNIX, whether they discuss UNIX in particular or not,
many methods are used in UNIX that certainly did not originate within UNIX.

Any good college text, or published research paper in computer science from the
last 30 years, that talks about high performance computing, multi-processing,
parallel processing, memory structures, networking, storage subsystems, real
time software, drivers, etc... will cover the concepts used in UNIX. In fact I
would beta lot of money that there is little or nothing in any modern operating
system that is not based on a method or concept discussed or researched in an
academic paper or text. Specific implementations may be proprietary, but the
concepts themselves are out ther, they have been for years and/or decades. This
is nonsense.

[ Reply to This | # ]

A really helpful list of UNIX internals book - online - provided by SCO!
Authored by: Anonymous on Monday, May 01 2006 @ 04:57 PM EDT
Apparently there is a long list of UNIX book recommendations online.

Some highlights:

Bach, Maurice J.
The Design of the UNIX Operating System. Englewood Cliffs, NJ: Prentice-Hall, 1986. A technical discussion of the internals of the UNIX System V operating system, written shortly before System V, Release 3. Somewhat outdated, but still very useful.

Dowd, Kevin.
High Performance Computing. Sebastopol, CA: O'Reilly & Associates, 1993. Discusses the basics of modern workstation architecture, understanding and writing performance benchmarks, and methods for improving performance of critical applications.

[my comment - I wonder if this covers profiling?]

And here's another A HREF="" TARGET="_blank">SCO recommendation:

Emphasis added:
There are two approaches to understanding UNIX, besides understanding it as a user. The first approach is the system level approach, which attempts to explain the system in terms of the services it provides to applications, and covers the API (Application Program Interface) of the operating system in some depth. This is most useful to programmers wishing to develop applications that can take full advantage of the UNIX environment.

A useful example of this type of book is Advanced UNIX Programming (Marc Rochkind; Prentice-Hall, 1985). This book presupposes a familiarity with the C programming language. On that basis, it conducts the reader on a guided tour of the intricacy of UNIX system programming, with a chapter by chapter overview of the function calls available to user programs. There are many other books of this type; this one was one of the first detailed explanations of UNIX system programming.

The second approach to understanding the UNIX system is the internals approach, which provides the reader with a detailed explanation of how the internal subsystems of the UNIX operating system were designed, and how they carry out their functions. This course of study almost certainly requires a basic knowledge of operating systems theory and computer science before it can be made use of, but provides the suitably equipped reader with a total understanding of what the UNIX operating system was designed to achieve, and how it succeeds.

The classic text following this approach is The Design of the UNIX Operating System (Maurice J. Bach; Prentice Hall, 1986). Bach provides a detailed exposition of the design elements of the UNIX system kernel, including information on how processes are scheduled, how memory is managed, and how the API is presented to the applications run on the system.


[ Reply to This | # ]

The real reason why methods and concepts are claimed by SCOG?
Authored by: Anonymous on Monday, May 01 2006 @ 06:54 PM EDT
Could it be SCOG knows they can't name file, line, and version without having it
ripped to shreds within minutes?

It has already been done once, even when they attempted to "Greek" the

Their shameful changes of direction and violation of court orders is enough to
make one's stomach churn, not only for the implications for this case, but for
the entire concept of "justice" in the USA. Gaming the courts,
verging on perjury? All in a day's FUD.

[ Reply to This | # ]

List of UNIX books
Authored by: rsi on Monday, May 01 2006 @ 07:03 PM EDT
May I request that the ISBN numbers be listed with the books in the list? 


I think that this would help in searching for any of the books or publications on the list.

[ Reply to This | # ]

Reply to PJ's request for further books
Authored by: tyche on Monday, May 01 2006 @ 07:48 PM EDT
Two books I used to help me understand UNIX when my employer dumped two Sun
Sparc Workstation 1+'s on my department (with no training):

1. Using UNIX
Que Corporation
1990:Que Corporation
"Covers AT&T System V, SCO System V/386, IBM AIX, and Berkley Unix

2. UNIX/System V Release 4/An Introduction/(For New and Experienced Users)
Rosen, Henneth H., Rosinski, Richard R., Farber, James M.
1990:American Telephone and Telegraph Company
Published by: Osborne McGraw-Hill
"A comprehensive guide to the new operating system that unifies UNIX System
V, the BSD System, the SunOS, and the Xenix System"

When I got through reading these and the _5_FEET_ of manuals that came with the
machines, I was able to accomplish things that the college trained system
administrator couldn't seem to accomplish for us. Including: Writing a script
to backup our drawings to a tape drive; Deleting a super-user password when they
tried to lock me out of being able to back up the systems; Writing a
configuration file for a new printer (the sys-admin actually couldn't find but
one minor thing wrong with the script, an omission that I hadn't realized needed
to be added. It took him as long to figure out the script/configuration file
and correct it as it did me to create it.). I also re-formatted (low level) one
of the hard drives and re-installed the system to stop it crashing (he had
overlapped the cylinders) and even got X-Windows working (Which he had been
unable to accomplish).

I don't know how deep they actually got in to the internals, but they were
definitely useful to someone who had never experienced UNIX before.


"Under what circumstances is it moral for a group to do that which is not moral
for a member of that group to do alone?"
"The Moon Is A Harsh Mistress",R.A.H

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 08:30 PM EDT
Horses out of the barn? I think you are starting to beat dead horses here. It
was already known from the beginning that SCO's case was weak and vague. They
knew it and everyone else in the industry did as well. No mountains of code, no
lost suitcases, no line-by-line infringement. For SCO to put their company on
the line like this for something so paltry is quite unbelievable. All anyone
can do now is wait for this scam to move glacially slow through the court

Wasted time. Wasted money. Wasted opportunity. Wasted business.

SCO could have been a very profitable enterprise with the right leadership --
instead it will be dust in a short time. Sad, just sad.

[ Reply to This | # ]

The true value of Groklaw extends to other fields....
Authored by: tiger99 on Monday, May 01 2006 @ 08:51 PM EDT
Today's little gem is that we are now very close to having a definitive list of every Unix textbook that has ever been published. And, following links, I now have a pdf of the Lions book, which I have wanted a copy of ever since it was first published.

It is quite amazing what useful stuff emerges as side issues to the SCO legal cases. And none of it is damaging Linux, quite the reverse in fact.

Darl may have unwittingly done us all a big favour.

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Anonymous on Monday, May 01 2006 @ 09:11 PM EDT
The apparent expectations that people have for "justice" in a lot of
these threads frankly terrify me.

[ Reply to This | # ]

Two more books
Authored by: Anonymous on Monday, May 01 2006 @ 10:01 PM EDT
Operating System Design, the XINU Approach
Douglas Comer
Prentice Hall, 1984
ISBN: 0-13-637539-1

The UNIX Programming Environment
Brian W. Kernighan, Rob Pike
Prentice-Hall, 1984
ISBN: 0-13-937681-X

[ Reply to This | # ]

Tanenbaum Books
Authored by: Anonymous on Monday, May 01 2006 @ 10:01 PM EDT
Here is another tanenbaum book :

Prentice Hall, Inc. 1984
ISBN/ISSN : 0-13-637331-3

[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: Glenn on Monday, May 01 2006 @ 10:20 PM EDT
The house of cards that the SCOG's case depends upon, in my opinion, is
getting the court to agree with them on their interpretation of the contract
giving them control over IBM's and anyone else who has a Sys V license to treat
derivative works the same as the original and to keep such derivative works
confidential. This would only apply to M&C not already "out of the
bag", such as possibly NUMA and RCU.
Correct me if I am mistaken, but wasn't NUMA developed and published in a
white paper before it was actually implemented in code by Sequent? That cat
would have effectively been out of the bag before it was even in.
I do not know anything about the development of RCU but I would not be
surprised if it was not developed as a concept and published before actual code
The SCOG is clutching at one slender straw. All the rest is just smoke and
broken mirrors.


[ Reply to This | # ]

On Methods and Concepts and Horses Out of the Barn
Authored by: chad on Monday, May 01 2006 @ 11:50 PM EDT

I have a book, "The Design of the UNIX Operating System", by Maurice J. Bach.  It is copyright 1986 by Bell Telephone Laboratories, Inc.,  published by Prentice-Hall, ISBN 0-13-201799-7.

It is the classroom textbook used to teach Bell Labs new hires about System V and for a long time was the reference on UNIX internals.

From the back jacket:

  • describes the outline of the kernel architecture
  • introduces the system buffer cache mechanism
  • includes data structures and algorithms used internally by the file system
  • covers the system calls that provide the user interface to the file system
  • defines the context of a process and investigates the internal kernel primitives that manipulate the process context
  • describes process scheduling
  • discusses memory management, including swapping and paging systems
  • outlines general driver interfaces, with specific discussion of disk drivers and terminal drivers
  • presents an overviewof streams
  • introduces inter-process communication and networking, including System V messages, shared memory, and semaphores
  • Explains tightly coupled multiprocessor UNIX systems
  • investigates more distributed UNIX systems

If it is SCO's contention that they don't need to supply file names and line numbers because the case is (now) about methods and procedures, then that horse has long left the barn.

[ Reply to This | # ]

    Think BSD.
    Authored by: darkonc on Tuesday, May 02 2006 @ 01:38 AM EDT
    BSD/386 predates Linux, and the source is completely free to do anything you want with it (other than removing the copyrights, like AT&T did)... So, anything in most versions of BSD is open and clear -- and most of what was in System V up to that point can be found, in one way or another in BSD (or, rather, vice versa -- The BSD community provided a huge packet of ideas and method into the UNIX code base). is, thus, open season for IBM -- as is just about anything in Linux that predates IBM's official involvement (anything in between can be fobbed off on the employees doing nasty things on their 'off' time, when they didn't answer to, or act for, IBM).

    Now, As I understand the PSJ scenario, the BSD and other available code is going to need to squash the SCO claims to the point where 'no reasonable person could side for' them. ... so it's probably easier for IBM to simply attack on the basis of Law -- that the license doesn't say what SCO says it does. That seems, in my humble (and NAL) opinion, to be the much stronger argument at this point. A defence based on fact is (at this point) more of a reserve argument (( even though it's a 'reserve' that could overwhelm SCO in it's own right )).

    Really, this is almost like someone suing me for violating the copyright on the 1968 version of "Oh Canada" by singing it at a hockey game.
    (( For those of you [[ especially Americans]] who have never seen a hockey game played in Canadian stadium, just about everybody at the stadium knows -- and sings -- the words.))

    Powerful, committed communication. Touching the jewel within each person and bringing it to life..

    [ Reply to This | # ]

    • Think BSD. - Authored by: PJ on Tuesday, May 02 2006 @ 06:40 AM EDT
      Wasn't that easy?
      Authored by: DaveJakeman on Tuesday, May 02 2006 @ 05:37 AM EDT
      I think this short Groklaw exercise demonstrates how easy it will be for IBM to
      have any remaining M&C claims laughed out of court, should the need arise.

      And likewise, for any M&C claims remaining, after SCO's motley collection
      are reduced by 198.

      So that would leave just the specific version-file-line-to-version-file-line
      item(s), which should be easy to trace the history of and bring SCO back to the
      world we call Reality.

      SCO: hunting for snarks in an ocean of sharks
      Should one hear an accusation, first look to see how it might be levelled at the

      [ Reply to This | # ]

      Lions' book freely available as a PDF
      Authored by: Alan(UK) on Tuesday, May 02 2006 @ 07:06 AM EDT
      The original Lions' book(let) is available for download as a PDF. As it is linked from the Lucent Technologies Bell Laboratories in Murray Hill, I will presume that this is kosher from a copyright point of view.

      [ Reply to This | # ]

      Open Solaris may be an important factor
      Authored by: Anonymous on Tuesday, May 02 2006 @ 07:12 AM EDT
      Your comments on Sun releasing Solaris under an open source (yes, I know it's not Free may lead to some useful lines of research, even more than the various books.

      1. afaik, SysV R4 was a joint development between USL and Sun (which to some extent led to the Unix Wars), so many of the "methods and concepts" are Sun's, which are now freely available

      2. There are very strong suggestions from a number of quarters that Sun's paymet to Caldera / tSCOG was for the right to release USL / Novell / Santa Cruz / Caldera's UNIX "IP" under an open source license. If that is the case, the only damage to Caldera / tSCOG from any "improper disclosure" by IBM would have been in a reduced price paid by Sun. Any SysV R4 "IP" is now freely available thanks to opensolaris

      I was told many years ago that the only patent in UNIX was the suid bit, and that has long since expired. That may not have been correct, and there may have been subsequent patents in any case.

      [ Reply to This | # ]

      You have all missed the point!
      Authored by: Anonymous on Tuesday, May 02 2006 @ 09:31 AM EDT
      Since the methods and concepts aren't contained in the code, revealling the code
      doesn't disclose the methods and concepts! None of you are even trying to
      understand poor Darl and his friends.

      (PS it is possible you are not meant to take the above as a literal
      interpretation of my view!)

      [ Reply to This | # ]

      MS in illegal music download shocker
      Authored by: Anonymous on Tuesday, May 02 2006 @ 09:36 AM EDT

      MS in illegal music download shocker

      Copyright violation outrage

      By Lester Haines
      Published Tuesday 2nd May 2006 13:23 GMT

      [ Reply to This | # ]

      This is Great,
      Authored by: rsteinmetz70112 on Tuesday, May 02 2006 @ 02:56 PM EDT
      All we need to know now is what SCOG claims as theirs, so we can look up where
      it was published.

      Does anyone else think, as I do, that IBM is even now assembling an even bigger
      bibliography and references keyed to each and every one of the of the SCOG

      We have seen, in both Marriott's presentation and Davis' declaration, specific
      examples of items that have already been tracked down. IBM couldn't simply have
      leafed through it and come up with those, they must be systematically tracking
      each and every one down.

      I think these specific references may be a warning to SCOG.

      Rsteinmetz - IANAL therefore my opinions are illegal.

      "I could be wrong now, but I don't think so."
      Randy Newman - The Title Theme from Monk

      [ Reply to This | # ]

      Paging in System III
      Authored by: igb on Tuesday, May 02 2006 @ 03:56 PM EDT
      `` Virtual memory was added at Berkeley for the release of Bell Labs' System III''

      I'm confused by this. System V didn't page until SVR3 in its USL incarnation (Uniplus+ paged in the port of SVR2.2, and I think SVR2, but that was Unisoft's secret sauce). Bach's book covers, from memory, System III and System V.1, and that describes a swapping kernel. I'm assuming that if paging arrived in later V, it wasn't in III.

      I never used System III (I used 6th, 7th, various 4bsd and I worked on ports of V.2 and V.3, but III passed me by) but wasn't it essentially a productionised 7th Edition, and therefore capable of running on a pdp11 with split I&D (ie /45 and /70). I can't imagine paging being viable on a pdp11. Likewise things like 68008, those weird Fortune 16:32 mqchines and so on...


      [ Reply to This | # ]

      What about Novells waiver?
      Authored by: Anonymous on Tuesday, May 02 2006 @ 04:32 PM EDT
      What about Novells right to waive any of this stuff?

      If I remember correctly, Novell had the right to over-rule SCO on any matters
      like this.

      And from what I remember, Novell did so direct SCO.

      So, even in a "worst-case" scenario, SCOs claims are trumped by Novell
      anyhow... leaving SCO with nothing.

      [ Reply to This | # ]

      SUNExpert magazine 1989-2000
      Authored by: Anonymous on Tuesday, May 02 2006 @ 07:28 PM EDT
      Apparently, SUNExpert is/was some kind of monthly magazine dealing with UNIX in particular. Here are some titles of articles from that magazine written by Peter Collinson from 1989-2000. Here I show you the titles of the articles from 1990:

      December 1990: The kernel, the process and the system call
      - What's a system call, how processes talk via the kernel to the outside world
      November 1990: Shell prompts
      - How to set up nice shell prompts and set labels on X windows
      October 1990: Program Exit Status
      - Using results from commands sensibly
      September 1990: Programming models
      - What a process sees when it runs in the machine, how a compiled program works
      August 1990: Pipelines
      - How to use pipes
      July 1990: Environment variables
      - How to set and read environment variables, well known names
      June 1990: Permissions on files
      - What file permissions are and how to set them
      May 1990: Lost files
      - Really about the dump and restore commands
      April 1990: The UNIX filesystem
      - How the file system works
      March 1990: Loops
      - Loops in shell programs for, foreach, break, continue and a bit on the find and apply commands
      February 1990: Signals
      - What signals are, how they are handled
      January 1990: Processes
      - A discussion on how processes work on UNIX

      IMANAL, I'M Absolutely Not A Lawyer -- Just didn't login

      [ Reply to This | # ]

      How many nails does it take?
      Authored by: Anonymous on Tuesday, May 02 2006 @ 07:53 PM EDT
      I just don't get this. It seems that every other article on GL puts another
      10-20 nails in the SCOG coffin (and that is without *paid* research like IBM and
      it's lawyers are doing). I assume that for every item GL unearths, IBM is
      finding 10 additional things for its defense.

      My only question is how many nails can a coffin hold?

      [ Reply to This | # ]

      Rough extraction of books listed
      Authored by: grouch on Wednesday, May 03 2006 @ 12:58 AM EDT
      I've distilled a list of books from everyone's comments. It's long, so I'll post it as a reply to this comment.

      It's rough and needs a bunch more clean-up, but my eyes are too fried to do that now. Maybe somebody else can pick up the ball from here?

      -- grouch

      [ 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 )