Putting some meat on legal news' bones.

When you want to know more
about a legal story . . .
but don't know where to look.

IANAL. I am a paralegal, so if you have a legal problem
and want advice, this isn't the place. Hire an attorney
instead. Research is, however, what paras do, so here
I am sharing things I have found in my research.

Click to see the XML version of this web page.

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

Tuesday, July 15, 2003

Linus: "The Most Important Thing Has Always Been
That People Be Able To Trust Me"

A very reassuring interview with Linus here in which he says that Linux hasn't been affected in any real sense by the SCO business, because the way they have done development is so open, when something happens you can just go look and see who did what and when, which isn't so easy in proprietary software models. Clearly he has done so:

"So we actually have a very good notion of where the code came from and what the [intellectual property] rights are...when it comes to the stuff that IBM has given Linux, we have been very, very careful about how we accept them. The one thing SCO has mentioned has been the Read Copy Update code that IBM gave us, and that wasn't accepted for the longest time into the kernel exactly because we knew the patents were owned by IBM. [But] we said we couldn't take it until you [IBM] said very explicitly that you also license the patents."

Lots more. As to why he chose to go to OSDL and not a commercial company, he says it's all about people having trust in him, as to his motivations. Now if only dear Darl shared the same values, we could wrap this up.

comment [] 11:31:00 PM    

Thanks For The Memories

Dennis Ritchie has posted an old UNIX license issued to Katholieke Univerisity, dated 1974, found and scanned by Prof. Karl Kleine in Germany. This university was, he writes, "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."

He mentions the importance of the clause 4.05 and that "the restriction against disclosing methods or concepts (as distinct from actual source code) caused ill-ease to some university lawyers. The restriction was indeed a bit peculiar: the concepts had already been published, for example in the C.ACM paper." Here's the clause he is referring to:

"Software Agreement "Effective as of December 1, 1974 "WESTERN ELECTRIC COMPANY, INCORPORATED, a New York corporation ("WESTERN"), having an office at 222 Broadway, New York, New York 10038,

"and KATHOLIEKE UNIVERSITEIT ("Licensee"), having an office at Nijmegen, The Netherlands . . . .

"Section 4.05 LICENSEE agrees that it shall hold the LICENSED SOFTWARE in confidence for WESTERN and its ASSOCIATED COMPANIES. LICENSEE further agrees that it shall not make any disclosure of the LICENSED SOFTWARE or any portion thereof (including methods or concepts utilized therein) to anyone, except to employees or students of the LICENSEE to whom such disclosure is necessary to the use for which rights are granted hereunder. LICENSEE shall appropriately notify each employee and student to whom any such disclosure is made tht such disclosure is made in confidence and shall be kept in confidence by him."

However, there is another clause that I noted that next says that anything already disclosed by then or later wasn't covered by the restrictions in Section 4.05. Here's the wording that set such software, including methods or concepts, free:

"Section 4.06 The obligation of the LICENSEE and of its employees and students under Section 4.05 shall survive and continue after any termination of rights under this agreement; however, such obligations shall not extend to any information or technical data relating to the LICENSED SOFTWARE which is now available to the general public or which later becomes available to the general public by acts not attributable to LICENSEE, its employees or students."

How will SCO get around that clause, I wonder, when trying to say that all UNIX methods belong to them? It illustrates the value of making sure this history is collected and preserved and the value of many eyeballs, too, even outside of a software context. He noticed one significant part, I noticed another he hadn't, and you may see something else of significance.

And here he has three old UNIX ads, including one for MS's flavor of UNIX, XENIX, circa probably 1980, scanned in by Vincent Guyot. There is a little girl standing next to XENIX saying, "Your name is different but you're really a UNIX system too, aren't you?" A woman to the right says: "UNIX is an operating system, in other words, a program that supervises a computer."

This is exactly in harmony with what IBM wrote in its answer to the complaint, that UNIX is a system, a standard, for operating systems.

And here is a paper Ritchie gave in 1977, "The UNIX Time-sharing System -- A Retrospective", as an employee of Bell Laboratories at a conference in Hawaii. He describes it here but here are some relevant snips:

"UNIX is a general-purpose, interactive time-sharing operating system primarily for the DEC PDP-11 series of computers, and recently for the Interdata 8/32. Since its development in 1971, it has become quite widely used, although publicity efforts on its behalf have been minimal, and the license under which it is made available outside the Bell System explicitly excludes maintenance. Currently there are more than 300 Bell System installations, and an even larger number in universities, secondary schools, and commercial and government institutions. . . .

"In most ways UNIX is a very conservative system. Only a handful of its ideas are genuinely new. In fact, a good case can be made that it is in essence a modern implementation of MIT's CTSS system [1]. This claim is intended as a compliment to both UNIX and CTSS. Today, more than fifteen years after CTSS was born, few of the interactive systems we know of are superior to it in ease of use; many are inferior in basic design. . . ..

"One problem in discussing the capabilities and deficiencies of UNIX is that there is no unique version of the system. It has evolved continuously both in time, as new functions are added and old problems repaired, and in space, as various organizations add features intended to meet their own needs. Four important versions of the system are in current use:

"The standard system maintained by the UNIX Support Group at Bell Laboratories for Bell System projects.

"The 'Programmer's Workbench' version of UNIX [6, 7], also in wide use within Bell Laboratories, especially in areas in which text-processing and job-entry to other machines are important. Recently, the PWB system has become available to outside organizations as well.

"The 'Sixth Edition' system (so called from the manual that describes it), which is the most widely used under Western Electric licenses by organizations outside the Bell System.

"The version currently used in the Computer Science Research Center, where UNIX was developed, and at a few other locations at Bell Laboratories.

"The proliferation of versions makes some parts of this paper hard to write, especially where details (e.g., how large can a file be?) are mentioned. Although compilation of a list of differences between versions of UNIX is a useful exercise, this is not the place for such a list, so the paper will concentrate on the properties of the system as it exists for the author, in the current Research version of the system.

"The existence of several variants of UNIX is, of course, a problem not only when attempting to describe the system in a paper such as this, but also to the users and administrators. The importance of this problem is not lost upon the proprietors of the various versions; indeed, vigorous effort is underway to combine the best features of the variants into a single system. . . .

"A number of facilities provided in other systems are not present in UNIX. Many of these things would be useful, or even vital, to some applications--so vital, in fact, that several variant versions of the system, each implementing some subset of the possible facilities mentioned below, are extant. The existence of these variants is in itself a good argument for including the new extensions, perhaps somewhat generalized, in a unified version of the system."

So... still think all UNIX in the known world was written solely by AT&T, as SCO claimed in its Complaint? These are just some of the goodies you can find on Ritchie's Home Page. Say, he's doing his part, huh?

Speaking of goodies, you might like to take a look at the photo of Ken Thompson and Dennis Ritchie back when they began writing UNIX. Here is a thumbnail:

SCO and other corporate types have sometimes dismissed Linux because it's written by a bunch of young guys, some with beards and not in suits (actually some females do write code -- take a look at the writers of the GIMP, for example, if you have the GIMP). For example, in 1999, then president and CEO of the Santa Cruz Operation Doug Michels derisively called them "punk young kids" and said Linux's weakness compared to UNIX was this:

"It takes millions of dollars to run [reliability] tests. It takes expensive people, expensive labs, expensive [electric] bills, racks and racks of hardware, and really boring, hard, grubby work. It isn't stuff that people do for fun at home with volunteers."

Funny what time does to a guy's memory. Look at the picture of the two guys who started writing UNIX. Does it match Mr. Michels' description? I see a couple of young guys not in suits, with long hair, and one, Dennis Ritchie, in a -- gasp -- beard. I don't think today's Linux's writers look too different from Thompson and Ritchie in this picture, Alan Cox excepted, of course. No offense Mr. Ritchie. And thanks for the memories.

comment [] 6:58:37 PM    

Decoding Legalese Into English

Legal documents aren't written like novels. The creativity is predominantly in the strategy, not the words. In IBM's original Answer in the SCO case, which I am using here for demonstration purposes, it looks like it's written in English, but it's really code. Legal code.

Programmers should be able to grasp this concept easily, because they write in code too. Even when some of the words they use are English words, they don't necessarily mean the same thing when used in software that they do in a novel. The law is like that too. Words have certain very specific meanings in the law. To understand a legal document, you have to know the code and how to translate it into English.

I think misunderstanding this is why there was such a loud shout of frustration and disappointment when IBM's original Answer was filed with the court in April. What a lot of people expressed was, Why didn't IBM really let them have it? The answer is, they did. But to understand what they said, you have to translate the code.

So, here we go. Bear in mind that people write entire tomes on these subjects, and we'll just be skimming along, but at least you'll get enough of a picture to grasp what the terms mean.

First, all the denials. This seemed to really distress some folks, because IBM refused to admit to things people thought they really ought to know. For example, MozillaQuest Magazine took IBM to task for saying they lacked knowledge of whether "an organization was founded by former MIT professor Richard Stallman entitled 'GNU'" and all the other material SCO wrote that IBM responded to in paragraphs 77-84. They thought surely IBM ought to know who Stallman is and that they should have taken their opportunity to explain that SCO was wrong about calling Linux a bicycle compared to UNIX being a luxury car, etc.

But aside from all the errors of fact -- Stallman was never a professor at MIT and the organization wasn't called GNU -- it isn't IBM's responsibility, legally, to take a stand on such matters. Nor is it to their advantage. Saying you lack sufficient facts isn't a cop out. It's just stating that IBM isn't Stallman and they aren't privy to all the facts or responsible to prove anything about him or his organization. It's up to SCO to prove whatever they feel is important to prove about all that.

You don't have the option to write an essay correcting the other side's mistakes in an Answer, although you can correct them at trial later. Your choices here are admit, deny, or say that you lack sufficient information to form a belief. And "form a belief" here doesn't mean the same thing as when you have friends over and you're debating which movie of the summer was the best. It means you can't admit or deny because you can't prove it one way or another; you aren't in possession of enough facts to admit or deny.

Significantly, in paragraph 86, they did deny this paragraph, meaning they believe they can prove that what SCO wrote here in the Complaintis false:

"It is not possible for Linux to rapidly reach UNIX performance standards for complete enterprise functionality without the misappropriation of UNIX code, methods or concepts to achieve such performance, and coordination by a larger developer, such as IBM."

Admit, Deny, or Lack Sufficient Information to Form a Belief

When you get served with a complaint in a civil case, as opposed to a criminal matter, each paragraph in the complaint is numbered and each paragraph is supposed to have one or two clear facts in it, and you then are required to respond to each fact in all the paragraphs. The purpose of this is to get both sides focused on what the case is about. What's the core of the problem the court needs to solve? If you fail to address a point, it's deemed admitted, so you'll notice the care with which IBM answered absolutely everything and even added a line saying in effect, If we forgot anything, we deny it now.

You are required to admit whatever you know is true. If you admit, in a legal document, it means you won't contest that fact in the lawsuit. A corporation, for example, will admit they have their headquarters in New York, if they do, because that's not at issue in the case. But if they admit they breached the contract because they hoped to destroy the other side's business, the case is over. If you deny, it means you feel you can prove it to be false at trial. And that you fully intend to.

Obviously you want to admit as little as possible at this early stage. So you read every single word, and if it's craftily written to try to get you to admit something, you need to catch it and refuse to admit. Anything you want the other side to have to prove, you deny if you reasonably, honestly can. That's what IBM did.

If it's not something you could prove factually yourself, you say, in essence, "How should I know? It might be true or it might not, but I don't have enough inside scoop to say it's true or it isn't." It isn't what you "know" in the common sense of the word; it's what you can prove true or false in a court of law.

IBM's responses in paragraphs 25 -27 and 47-49 are examples of that. Or, significantly, IBM's saying they don't know if Novell acquired "all right, title and interest in and to UNIX from AT&T". By saying they don't know, they mean: you will have to prove this matter at trial. Had they admitted it, SCO would not have had to prove at trial that Novell acquired all rights from AT&T. IBM wants them to have to prove it.

Ditto with paragraph 57 and 58. IBM says they don't know what rights SCO acquired from Novell or whether "SCO became the authorized successor in interest to the original position of AT&T Technologies with respect to all licensed UNIX software products", as SCO claimed in its Complaint.

Sometimes, you'll admit one phrase or one fact in a sentence but deny the rest, because it's the only truthful way to respond. For example, take paragraph 19 of SCO's original complaint. SCO wrote, that "AIX is a modification of AT&T/SCO's licensed UNIX that is designed to run on IBM's processor chip set, currently called the 'Power PC' processor."

IBM responds by admitting it has a software product under the trade name AIX (meaning they have trade mark rights) but it denies the rest. Whether AIX is a "modification" of UNIX is what SCO has to prove. SCO claimed this in its Complaint:

"'IBM's AIX contributions' consisted of the improper extraction, use, and dissemination of SCO's UNIX source code and libraries, and unauthorized misuse of UNIX methods, concepts, and know-how."

In paragraph 96, IBM denied this. This could be why. A white paper available on its site, titled "JFS for Linux", is interesting in this regard:

"Source of the JFS Technology"

"IBM introduced its UNIX file system as the Journaled File System (JFS) with the initial release of AIX Version 3.1. This file system, now called JFS1 on AIX, has been the premier file system for AIX over the last 10 years and has been installed in million s of customer's AIX systems. In 1995, work began to enhance the file system to be more scalable and to support machines that had more than one processor. Another goal was to have a more portable file system, capable of running on multiple operating systems. Historically, the JFS1 file system is very closely tied to the memory manager of AIX. this design is typical of a closed-source operating system, or a file system supporting only one operating system.

"The new Journaled File System, on which the Linux port was based, was first shipped in OS/2 Warp server for eBusiness in April, 1999, after several years of designing, coding, and testing. It also shipped with OS/2 Warp Client in October, 2000. In parallel to this effort, some of the JFS development team returned to the AIX Operating System Development Group in 1997 and started to move this new JFS source base to the AIX operating system. In May, 2001, a second journaled file system, Enhanced Journaled File System (JFS2), was made available for AIX 5L. In December of 1999, a snapshot of the original OS/2 JFS source was taken and work was begun to port JFS to Linux."

So they are saying that the JFS version that got put in Linux is from their own OS/2 code, and that the same code was also added to AIX later. OS/2 doesn't stem from System V UNIX, and some of what got into AIX isn't from System V either, from what they are here saying. But this will be what the trial will determine.

Another example is in paragraph 50, where IBM makes a distinction between SCO and the Santa Cruz Operation, Inc., saying IBM entered into an agreement with the latter, not with SCO, to develop a UNIX operating system for 64-bit processing platform being developed by Intel, namely Project Monterey.

This distinction could be foreshadowing that IBM plans on saying that any breach of the contract would have been a breach of a contract to which SCO, SCO now, wasn't a party. In fact, in their Answer, one of their affirmative defenses is that SCO lacks standing. The argument could be that while SCO may have purchased certain rights to UNIX, they weren't a party to the contract allegedly breached, so they have no basis for complaining about any such breach even if it in fact had been breached.

As you can see, as with all code, you can say a lot with just a few words. So IBM denying as much as it did wasn't because they were too stupid to know. They were too smart to admit whatever they shouldn't or didn't have to. Another example, in paragraph 5 and 6, IBM denies being a Delaware corporation and they deny that SCO is "a Delaware corporation with its principal place of business in Utah County, State of Utah." They denied being a DE corporation because IBM is in fact incorporated in NY, something SCO's lawyers could have checked in IBM's SEC filings. But note they don't give the reason why they denied. I looked it up and so can figure out the reason, but they don't have to tell why they deny. As to whether and why they are denying that SCO is a Delaware corporation, time will tell, but to me it's a big flag. Unless they just goofed. Unlikely, but conceivable.

There's something else you need to understand about legal documents: they are written according to the facts the legal team knows and feels it can prove at trial. No one outside the legal team can know fully before the trial why they made the decisions they did in responding to SCO's complaint because we aren't privy to all the proofs they are holding. We haven't seen all the documents, the agreements over the years, nor do we know what witnesses they have lined up, what experts. They know, for sure, exactly what each word means, what evidence they have that supports their side, and what they plan on doing at trial. You plan your trial strategy before you write a single word.

This isn't, therefore, an attempt to read their minds, just to indicate that a lot of people misread the force of what IBM wrote. Once you understand that not admitting means "We're going to fight you on this point", you can read what IBM submitted and grasp the extent to which it plans to fight. In a word, totally. They didn't give an inch.

In response to what IBM wrote, SCO filed an amended complaint, in which it corrected some factual errors and deleted some interesting material and added some. You could write another article on just the changes, and in fact, I probably will, but my point is that for sure SCO knew better than to leave what IBM wrote unanswered. They understood the code.

IBM then answered their Amended Complaint with an Amended Answer, filed late in May, but I'll leave that for a future installment, when I cover the affirmative defenses, like laches, unclean hands, economic-loss doctrine, etc. No, unclean hands doesn't mean in legalese what it does in English. Note, I am not here intending to speak to the merits of the case between IBM and SCO because I have insufficient information on which to form an opinion.

No. Really.

comment [] 4:54:55 AM    

Click here to visit the Radio UserLand website. © Copyright 2003 PJ.
Last update: 8/1/03; 5:51:59 AM. Creative Commons License
This work is licensed under a Creative Commons License.

July 2003
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Jun   Aug