decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

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


You won't find me on Facebook


Donate

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

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text
Tuesday, July 18 2006 @ 06:17 AM EDT

Good morning, everyone. Another lovely day in the SCO Saga unfolds, with, lo and behold, a redacted version [PDF] of SCO's previously sealed Objections to Order Granting in Part IBM's Motion to Limit SCO's Claims. I told you we'd get to see it, or some of it at least, someday. Here's the Order to which they are objecting.

You don't want to miss the Appendix A [PDF], either, as it's hilarious to observe SCO try to justify its executives' early public statements to the world. I would love a transcript of the meeting they had with the lawyers working that piece of work up. Note as I do with a smile number 2 on the list, where Sontag's statement was that they had compared the Linux kernel and System V and found "many instances where our proprietary software has been simply copied and pasted or changed in order to hide the origin..."

SCO then states in the Appendix:

This is an accurate statement of comparison work performed by SCO in advance of public statements. There are in fact instances in which SCO's proprietary System V code was simply copied and pasted into the Linux kernel or associated libraries that were then included in a Red Hat distribution. Items Nos. 183, 184, 272.

Ah! Weasel! Thy name is SCO.

Hint to nongeeks: the libraries they are talking about are not part of the Linux kernel. Sontag didn't mention libraries to the media, only the kernel. And I see three items, not a "mountain of code" which when you subtract the libraries may be zero in the kernel, and as for the libraries, SCO is claiming things that most of us think they have no proprietary interest in. I thought it might be useful to collect all the articles Groklaw has published that rebut the libraries/headers/code claims.

Here's Groklaw's answer to all that guff:

My, we've done a lot of work. There is more, of course, on methods and concepts and on whether they even have the copyrights, but this is still a mountain of evidence, if I may put it that way. And where is SCO's mountain of code?

Yes, this Appendix is my favorite filing by far, and that's saying something. No, without a doubt, this is the one to bronze and hang on my wall. I haven't finished reading the Objections, so I'll do that and swing back by after I do, but I didn't want you to have to wait to enjoy this.

What I'm thinking would be most useful would be to list in your comments anything I forgot to list that rebuts their claims, instead of just laughing. That way there is a public record of facts standing forever, all in one place. It'll be easy. And fun.

And so here it is as text. I wish to say the most heartfelt of thank yous to Carlo Graziani, for writing a script that translates into HTML for me, and my poor wrists thank you too! And thank you to mwexler also, who tried some perl magic, and did some OCR stuff too. This filing was part text PDF and part not. It would have been argh hard, had it not been for these two.

********************************************************

Brent O. Hatch (5715)
Mark F. James (5295)
HATCH, JAMES & DODGE
[address, phone, fax]
Robert Silver (admitted pro hac vice)
Edward Normand (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Stuart H. Singer (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]
Stephen N. Zack (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
[address, phone, fax]

Attorneys for The SCO Group, Inc.



IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF UTAH


THE SCO GROUP, INC.,

Plaintiff/Counterclaim-Defendant,

v.

INTERNATIONAL BUSINESS
MACHINES CORPORATION,

Defendant/Counterclaim-Plaintiff.
SCO'S OBJECTIONS TO ORDER
GRANTING IN PART IBM'S MOTION
TO LIMIT SCO'S CLAIMS


FILED IN REDACTED FORM
(ORIGINAL FILED UNDER SEAL)

Case No. 2:03CV0294DAK
Honorable Dale A. Kimball

TABLE OF CONTENTS

Page

I. INTRODUCTION................................................................................................... 1

II. BACKGROUND..................................................................................................... 3

A. The Nature of SCO's Contract and Copyright Claims................................ 3

B. This Court's July 2005 Order Regarding "Specificity" .............................. 5

C. SCO's Compliance with the July 2005 Order............................................. 6

D. IBM's Motion to Limit SCO's Claims........................................................ 7

III. THE MAGISTRATE JUDGE'S ORDER SHOULD BE REVIEWED DE NOVO FOR COMPLIANCE WITH THE STRICT STANDARDS REGARDING STRIKING OF CLAIMS AS A DISCOVERY SANCTION. ........... 13

IV. SCO COMPLIED WITH THIS COURT'S DIRECTION TO IDENTIFY "MISUSED MATERIAL" WITH "SPECIFICITY." ..........................................................................15

A. The Magistrate Judge Clearly Erred in Concluding That the July 2005 Order Required "Version, File & Line" Information for Methods and Concepts.15

B. The Magistrate Judge Clearly Erred to the Extent the Order Is Predicated on SCO's Responses to Past Discovery Orders or IBM Interrogatories. .......................................................................................... 18

C. The Magistrate Judge Clearly Erred in Concluding That SCO's Past Interrogatories and the Deposition Testimony of SCO's Chief Technology Officer Support the Order's Interpretation of the Past Orders........................................................................................................ ..................................23

1. SCO's Past Discovery Requests................................................................... 24

2. Deposition Testimony of Sandeep Gupta.......................................................................28

3. Analogy to Deposit Requirement for Copyright Registration ...................................... 29

V. THE MAGISTRATE JUDGE CLEARLY ERRED IN FINDING THAT SCO WILLFULLY FAILED TO COMPLY WITH COURT ORDERS REQUIRING SPECIFICITY................................................................................ 30

ii

A. The Magistrate Judge Clearly Erred Because to Support a Discovery Sanction, an Order Must Clearly and Unambiguously State the Performance Required of a Party.................................................................................... 30

B. There Is No Record Evidence That SCO Willfully Violated a Court Order Or Declined to Respond to Interrogatories..................................... ...................32

VI. THE MAGISTRATE JUDGE CLEARLY ERRED IN FAILING TO CONSIDER WHETHER SPECIFIC DISCLOSURES WERE ADEQUATE. ..................39

A. The Failure to Provide Particularized Findings......................................... 40

B. The Failure to Consider the Adequacy of Disclosures on an Item-by- Item Basis.................................................................................................. 41

VII. THE MAGISTRATE JUDGE CLEARLY ERRED IN FAILING TO REQUIRE IBM TO ESTABLISH PREJUDICE AND TO CONSIDER ALTERNATIVES TO THE SANCTION IMPOSED. ......................................... 45

A. The Magistrate Judge Did Not Properly Consider the Issue of Supposed Prejudice Arising from SCO's Failure to Provide Source Code Identifiers for Each Item of Misused Material................................. 46

B. The Court Failed to Consider IBM's Own Responsibility for the Lack of Complete Source Code Identification........................................................... 50

C. The Magistrate Judge Clearly Erred in Failing to Consider Whether SCO Had Been Warned That Its Claims Were In Jeopardy. ................................................................ 51

D. The Magistrate Clearly Erred in Failing to Consider Alternatives to Limiting SCO's Claims............................................................................................ 52

VIII. CONCLUSION ..................................................................................................... 53

iii

TABLE OF AUTHORITIES

Cases

Page

American Stock Exch. v. Mopex, 215 F.R.D. 87 (S.D.N.Y. 2002)............................................................................... .......................................13, 49

Avicon Co. v. Gen Dynamics Corp., 957 F.2d 555 (8th Cir. 1992)......................................................................................... ........................................51

Cardenas v. Dorel Juvenile Group, Inc., 230 F.R.D. 611 (D. Kan. 2005)..................................................................................... ................................................32

Dorsey v. Academy Moving & Storage, Inc., 423 F.2d 858 (5th Cir. 1970)......................................................................................... ..........................52

Ehrenhaus v. Reynolds, 965 F.2d 916 (10th Cir. 1992).................................................................... 15

FTC v. Enforma Natural Prods., Inc., 362 F.3d 1204 (9th Cir. 2004)................................................................................. ................................14, 30

In re Flag Telecom Holdings, Ltd. Secs. Litig., 2006 WL 1072008 (S.D.N.Y. 2006) ....................................................................32

In re Westinghouse Electric Corporation Uranium Contracts Litigation, 563 F.2d 992 (10th Cir. 1977)....................................................................................... .................38

Gripe v. City of Enid, 312 F.3d 1184 (10th Cir. 2002)........................................................................ 15

Guinyard v. City of New York, 800 F. Supp. 1083 (E.D.N.Y. 1992).............................................................................. 49

Kropp v. Ziebarth, 557 F.2d 142 (8th Cir. 1977)......................................................................................... 32

M.E.N. Co. v. Control Fluidics, Inc., 834 F.2d 869 (10th Cir. 1987)....................................................................................... .....14

Miller v. Sprint Communications, 1997 WL 910426 (W.D. N.C. 1997)............................................................................. ......38

Mobley v. McCormick, 40 F.3d 337 (10th Cir. 1994).................................................15

iv

Ocelot Oil Corp. v. Sparrow Indus., 847 F.2d 1458 (10th Cir. 1988)..................................................................................... 13

Ortiz-Anglada v. Ortiz-Perez, 183 F.3d 65 (1st Cir. 1999) ........................................................................................... 51

Peterson v. Hantman, 227 F.R.D. 13 (D.D.C. 2005) ..................................................................31

Procter & Gamble Co. v. Haugen, 427 F.3d 727 (10th Cir. 2005)............................................................ passim R.W. Int'l Corp. v. Welch Foods, Inc., 937 F.2d 11 (1st Cir. 1991) ........................................................................................... 31

Robson v. Hallenbeck, 81 F.3d 1 (1t Cir. 1996)............................................................ 14, 30, 40

S&S Communications v. Local Exh. Carriers Ass'n, 2005 WL 2897045 (D.S.D. 2005) ................................................................................. 49

Schanzer v. United Techs. Corp., 120 F. Supp. 2d 200 (D. Conn. 2000) ........................................................................... 48

Searock v. Stripling, 736 F.2d 650 (11th Cir. 1984)....................................................................................... 46

Sithon Maritime, Co. v. Holiday Mansion, 1998 WL 638372 (D. Kan. 1998)................................................................... 33

Societe Internationale Pour Participations Industrielles Et Commerciales, S.A. v. Rogers, 357 U.S. 197 (1958) .......................................................................................... 38, 39, 52

Sonnino v. Univ. of Kan. Hosp. Auth., 220 F.R.D. 633 (D. Kan. 2004)..................................................................................... 32

Steil v. Humana Kansas City, Inc., 197 F.R.D. 445 (D. Kan. 2000)..................................................................................... 33

T.N. Taube Corporation v. Marine Midland Mortgage Corp., 136 F.R.D. 449 (W.D.N.C. 1991)...................................................................... 31

Tracinda Corp. v. DaimlerChrysler AG, 362 F. Supp. 2d 487 (D. Del. 2005)...................................................................49

v

Unicure, Inc. v. Thurman, 97 F.R.D. 7 (W.D.N.Y. 1982) ..................................................................... 23

Vandervest v. Wisconsin Cent., Ltd., 172 F.R.D. 401 (E.D. Wis. 1997).................................................................................. 49

Williams v. Sprint/United Mgmt. Co., 230 F.R.D. 640 (D. Kan. 2005)............................................................................... 23, 30

Zappala v. Albicelli, 954 F. Supp. 538 (N.D.N.Y. 1997) ............................................................................... 33

Federal Rules 28 U.S.C. § 636(b)(1)........................................................................................................ 14

Fed.R.Civ.P. 37 ................................................................................................................. 33

Federal Practice And Procedure § 3068.2 (2d ed. 2006) .................................................. 13

Federal Rule of Civil Procedure 72(a) .............................................................................. 14

Federal Rule of Civil Procedure 72(b) .............................................................................. 13

vi

I. INTRODUCTION

SCO seeks reversal of the Magistrate Judge's Order Granting in part IBM's Motion to Limit SCO's Claims (the "Order") which precludes SCO from pursuing its claims regarding over 180 technology disclosures made by IBM to the development of the Linux operating system. This is an extraordinary Order that is improperly predicated on what the Magistrate Judge "believes" this Court has required and on incorrect inferences that SCO is withholding information. The Magistrate Judge also failed to consider the specificity of the challenged items on an individualized basis, failed to hold an evidentiary hearing, and failed to make any specific findings on the challenged items.

The Magistrate Judge's extreme action is fundamentally improper for several reasons and should be reversed.

First, SCO fully complied with this Court's direction to identify "misused material" with "specificity," and to update its interrogatory answers. One type of restricted material that SCO contends IBM misused by disclosing to the Linux development process is methods and concepts that IBM was obligated to hold in confidence under the terms of the software licensing agreements. Most of the items challenged by IBM in its present motion are such methods and concepts. However, contrary to IBM's accusations, in its December 22, 2005 Disclosure of Material Misused by IBM ("December Submission"), SCO identified the misused methods and concepts with specificity. SCO specifically identified IBM's improper disclosures of "methods and concepts" by, in almost all cases, specifically referencing the entire disclosure made by IBM, and in most instances identifying the IBM developer making the disclosure, and the date and mode of disclosure. Where a source code "patch" was provided as part of

IBM's disclosure in order to show the Linux community how to implement the method or concept in Linux, that code was specifically referenced in the disclosure report. This Court did not direct SCO and SCO did not believe it had been directed, to divine what source code IBM developers had in their minds when disclosing a method and concept without at the same time disclosing source code. Certainly, the Court did not make such a direction with anything approaching the clarity required to support a sanction order of this severity.

Second, there is no basis in the record for the Magistrate Judge's conclusion that SCO willfully that is, intentionally refused to provide the source code information IBM contends it was obligated to provide. To the contrary, the record evidence shows that SCO provided all the identifying information it had regarding the "misused materials" at issue, and there is no evidence SCO is holding anything back. SCO simply cannot be sanctioned when it is providing all of the information that it has. A willful violation occurs when a party decides not to produce documents or other information within its possession. SCO's December Submission, as well as the declaration of Marc Rochkind, the technology expert who largely prepared the submission, make clear that SCO is not hiding the ball or seeking to sandbag IBM with any new disclosures.

Third, the Magistrate Judge erred by entering the order without conducting an evidentiary hearing, considering on an item-by-item basis the specificity of the disclosures made and the claimed prejudice to IBM, and making specific findings regarding those items that would allow for appropriate review. SCO provides numerous examples below of technology disclosures that could not reasonably be found to be lacking in specificity when considered individually including the very disclosure on

2

which IBM's expert focused in his opening declaration. Indeed, contrary to clear Tenth Circuit authority, the Magistrate Judge did not consider and make findings with respect to the relevant factors governing such a severe sanction.

SCO sets forth in detail below the relevant background to the Order and then a detailed analysis of each of the foregoing points. SCO makes its objections under Fed. R. Civ. P. 72(b) and seeks a de novo review of the Magistrate Judge's ruling because, as IBM's motion requested, the Magistrate Judge dismissed many claims, which clearly has the effect of a dispositive ruling in this litigation.

II. BACKGROUND

A. The Nature of SCO's Contract and Copyright Claims
SCO brings claims for both breach of contract and copyright infringement. SCO's contract claims are based upon the license agreements signed by AT&T, SCO's predecessor in interest, with both IBM and Sequent (which IBM later acquired). These agreements allowed for UNIX source code, methods, and concepts to be used by IBM and Sequent in the development of their own UNIX operating systems but made the source code and methods and concepts in such "derivative" or "modified" systems subject to nondisclosure requirements. SCO's principal contention in this case is that IBM violated these contractual restrictions by taking both source code and methods and concepts from such derivative systems, specifically the AIX operating system developed at IBM and the Dynix/ptx ("Dynix") operating system developed at Sequent, and disclosing or contributing these valuable technologies to the Linux community for the purpose of transforming Linux from a hobbyist tool into a powerful, reliable operating

3

system for business use that could compete with proprietary UNIX and non-UNIX operating systems.1

Unlike the contract claims, SCO's copyright claims in the case (as well as IBM's counterclaim seeking a clean bill of health for Linux) do not involve methods and concepts. The copyright claims concern literal and non-literal copying from duplication of structural elements by essentially building a UNIX clone in Linux down to specific system calls and other items copied directly in code as is explained in detail in SCO's expert reports. This distinction is important because methods and concepts are treated by the Order as though they were the subject of SCO's copyright claims, and thus must be presented in source code. They are not.2

Only the contract claims involve both source code contributions and disclosures of methods and concepts. The contributions of source code are just that patches of code that can be as large as a whole system (such as the Journaling File System) or a few critical lines in a patch. IBM's motion principally contested the specificity of the

4

identification of method and concept items, not source code contributions. The disclosure of methods and concepts to the Linux community by IBM occurred through emails, articles, discussions at conferences, and elsewhere. At times, these disclosures were accompanied by a patch file indicating how the method or concept could be implemented in Linux. In most of the method and concept disclosures, however, source code was not part of the disclosure; the IBM emails, while admitting that the source of the contribution was Dynix or AIX, often did not indicate the source code in the Dynix or AIX operating system that may relate to the method or concept being disclosed. SCO has in effect been sanctioned for failing to divine the source code coordinates that IBM developers had in mind when disclosing a method or concept from a derivative operating system that IBM had written or modified.

B. This Court's July 2005 Order Regarding "Specificity"

As recited in the Order, there have been a number of interrogatories promulgated by both sides seeking information regarding the technologies in dispute, and orders entered on those discovery requests. (These are discussed in detail below.) There has not, however, been any order or interrogatory directing SCO to provide more specificity for methods and concepts than IBM used in making the disclosure itself. Nor has there been any order, until now, finding that SCO has failed to comply with its discovery obligations or has acted in anything but good faith in discovery.

SCO's initial complaint was filed in March 2003. IBM provided minimal discovery at the outset, declining to produce numerous versions of AIX and DYNIX or their revision history. The CMVC and RCS systems, which store historical versions and other information regarding AIX and Dynix source code, were ordered to be produced by

5

IBM in February 2005, and began to be received by SCO in May 2005. The February 2005 Order also required framing a new pre-trial schedule.

This Court's Order of July 1, 2005 set forth new deadlines for completion of discovery, for exchange of expert reports, for filing of dispositive motions, for completion of pre-trial stipulations and witness and exhibit lists, and, ultimately, for a five-week jury trial set to begin on February 26, 2007. At IBM's request, the Court also included deadlines for the parties to "identify" all allegedly "misused material" with "specificity," and to update interrogatory answers. The interim deadline for this identification was October 28, 2005, and the final deadline was December 22, 2005. This Court declined to adopt IBM's proposed language for that deadline, which stated that line, version, and file of source code must be provided. The fact that this Court declined to adopt IBM's proposed language for that Order should be enough to overturn the June 28 Order.

C. SCO's Compliance with the July 2005 Order

SCO timely and fully complied with both the interim October and final December deadlines. In October, SCO identified 204 items of "misused material," and provided source code references for source code disclosures and specific references to the method and concept disclosures at issue. On December 5, 2005, little more than two weeks before the final submissions were due, IBM wrote SCO a letter claiming that the October disclosures were not specific enough and threatening to move to preclude SCO from pursuing any claims regarding allegedly misused material that IBM believed was not properly disclosed. As SCO's plan and effort was to provide as much specificity in its December Submission as possible, and as SCO informed IBM at the time, that

6

Submission, which SCO believed fully conformed to the Order and went well beyond what was required in many areas, was viewed as the response to IBM's letter.

The December Submission consisted of a 466-page principal document organized around 294 items of misused material. The Submission provided identification of the person(s) making the disclosure; a description identifying the nature of the improperly disclosed code, method or concept; a summary of the improper disclosure or use; a reference to specific supporting files or documents listed as "sources"; and a list of Linux files believed to contain or to be related to the improperly disclosed materials. For most methods and concepts, all or critical parts of the communication comprising the disclosure were reproduced in the "summary" section of the disclosure. Where IBM provided a patch file of code along with the disclosed method (which showed the Linux community how the method or concept might be implemented in Linux), such code was included or the link to the file which IBM identified as containing the code was noted. Along with this principal document, SCO provided many thousands of pages of referenced sources which constituted code files, articles, or copies of the full communications through which the improper disclosure was made. SCO also provided IBM and the Court with a CD containing the December Submission, with all backup material hyperlinked to each disclosure item so that all source information identified in each disclosure could readily be viewed by clicking on the name of the hyperlinked source file.

D. IBM's Motion to Limit SCO's Claims

On February 13, 2006, IBM filed its Motion to Limit SCO's Claims Relating to Allegedly Misused Material. The accompanying ten-page memorandum accused SCO generally of failing to comply with the July 2005 Order by failing to provide version, file

7

and line coordinates for all of the items. Only two items were specifically discussed. One was a catch-all category of information (Item No. 294) which, upon further consideration, SCO withdrew. The other was certain AIX and Dynix patented technology (Item No. 271) that IBM had decided to open-source; this item was defended by SCO in its opposition memorandum (at 6-17) and not further addressed by IBM, or by the Magistrate Judge, but is among the items struck.

SCO responded to IBM's motion in a memorandum filed March 7, 2006, arguing that SCO had provided disclosures with the specificity required by the Court's July 2005 Order, and discussing how the disclosures provided were sufficiently detailed for various code and method and concept items. (IBM subsequently withdrew its objection to two of those contested items Item No. 2 involving Read-Copy-Update code and Item No. 204, demonstrating that Dynix was based on UNIX System V but did not specifically address almost any of the other challenged items. The Magistrate Judge struck almost all of these items without specific discussion.

IBM filed a reply memorandum on April 4, 2006, repeating that the disclosures were fatally deficient because they did not provide source code coordinates for each disclosure, or for its destination in Linux, and repeating the assertion that identification of all the related code would be like looking for a needle in a haystack and prevented formulation of a defense. IBM also cited one method and concept (No. 146, Exh. 1, Decl. of Mark James)3 to support its position by way of example. It further tendered an expert declaration (which it did not do in connection with its original motion) from an expert in artificial intelligence (not UNIX programming) named Randall Davis ("Davis

8

Declaration"). Professor Davis also dealt with only one disclosure specifically (No. 146); he claimed that it would take an enormous amount of time and manpower to link up code to the referenced items, and repeated the unsupported IBM refrain that SCO has failed to provide "even the most basic information" relating to the 198 items then at issue.

Prior to the hearing, in response to the Davis Declaration, SCO sought leave to file a declaration from Marc Rochkind, an expert in computer science and specifically in UNIX Operating Systems.4 The Magistrate Judge received the declaration but gave IBM the opportunity, post-oral argument, to file a responsive declaration from Professor Davis ("Davis Rebuttal Declaration").

In his declaration (Exh. 2), Mr. Rochkind offers his opinion (at paragraph 7) that SCO's Submission "identified the technology in issue with specificity." For code disclosures, Mr. Rochkind explained (at paragraph 8) that disclosure consisted of "specific identification of the code that was wrongfully disclosed by IBM." For methods and concepts, Mr. Rochkind explained (at paragraph 9) that the items "are specifically identified in the December submissions not only by summarizing the method or concept, but also, in almost all cases, by identifying the actual written communication that constitutes the disclosure." Mr. Rochkind (at paragraph 10) "strongly disagreed" with Professor Davis' opinion that version, file and line of source code must be provided to identify a method and concept and to prepare a defense to an allegation of misuse. Mr. Rochkind stated (at paragraph 10): "Where IBM disclosed methods and concepts from the Dynix and Dynix/ptx operating systems without providing source code in the disclosures, for example, it is often not possible and certainly not necessary to cite to

9

specific source code in identifying the disclosure." Mr. Rochkind went on to explain (at paragraph 11) that for many of the challenged items in the December Submission, code is either cited in the item or a reference is given to the internet site at which the code is located. Mr. Rochkind also prepared a chart (Rochkind Decl., Exh. B Exh. 2) showing how for the overwhelming majority of the challenged items, there were express admissions in the material cited that the method and concept was taken from Dynix or AIX. The chart also showed that the files in Linux relating to the disclosed item were identified for almost all of the items.

Mr. Rochkind addressed (at paragraph 13) the one example cited by Professor Davis (Item No. 146, Exh. 1) which was the disclosure of a method and concept called "differential profiling" from IBM developer Paul McKenney. SCO's disclosure on the item referenced a technical paper by Mr. McKenney explaining the method and concept, and provided a URL (internet) reference to scripts from Dynix, as well as Linux destination files. The URL addresses presumably contained the source code, but as Mr. Rochkind explained, they referred to an IBM server to which neither SCO nor he had access, so no further identification was possible. (Item No. 146, without discussion in the Order, is one of the items struck for lack of specificity.)

Turning to the more general IBM objection, Mr. Rochkind, who had the largest role in assembling the December Submissions, stated (at paragraph 17):

For each of the 294 items, I did everything I could to ensure that everything we had was disclosed and that it was organized in the most accessible possible manner. Counsel to SCO made it very clear that this was what they wanted me to do. I made sure that every Tab containing a publicly available email included the complete URL.

10

Mr. Rochkind further definitively stated (at paragraph 17) that he "made sure" that "versions, lines and files be cited where available." (Mr. Rochkind also noted (at paragraph 17) that there were some candidate items that did not meet his professional standards for completeness, clarity and specificity, which he recommended be excluded, and that in all cases that was done.) No evidentiary hearing was held on the IBM Motion, and there is no finding in the Order, or any analysis, that any part of Mr. Rochkind's declaration testimony is unfounded or unreliable in any way.

At the argument before the Magistrate Judge, SCO stressed three points: First, SCO had identified the disputed items with "specificity" by providing virtually the whole disclosure made by IBM developers to the Linux community; if code was part of the disclosure it was specifically identified. Virtually all of the challenged items included written evidence specifically stating that the method or concept came from a UNIX or derivative system, generally Dynix. Also, file locations in Linux were provided for virtually all of the disputed items. Second, IBM had failed to establish any willful failure to comply with a court order. If source code information was not provided for certain items it is because source code was not part of the disclosure, SCO did not know specifically which lines of AIX, Dynix or UNIX code the disclosure was referring to, and that the disclosure as it was made constitutes a breach of contract. Since the disclosed items were methods and concepts being disclosed by an IBM developer and came from an operating system that IBM (or Sequent) developers wrote or modified (although subject to contractual limitations on disclosure), it was reasonable to expect IBM to obtain such information if it were available and relevant from its own developers who made the disclosure. Third, SCO argued that if the court were to proceed further on

11

IBM's motion, an evidentiary hearing was necessary for an item-by-item determination of whether the disclosures were sufficient. That would also allow for consideration of expert reports which were soon forthcoming.

After the argument, IBM submitted the Davis Rebuttal Declaration, which contained new evidence and, somewhat surprising for an artificial intelligence expert, legal arguments not previously offered by IBM and not raised by the Rochkind Declaration even though IBM assured the Magistrate Judge they would limit the rebuttal declaration to matters raised by the Rochkind Declaration. Professor Davis posited, for the first time, that the discovery SCO was obligated to provide to IBM was somehow dictated by: (1) a definition contained in SCO's early discovery requests to IBM and (2) the deposition testimony of a SCO employee. SCO moved to strike this rebuttal declaration for introducing new points beyond the Rochkind Declaration, or in the alternative, to allow SCO an opportunity to respond. The Magistrate Judge denied this motion.

On June 28, 2006, the Magistrate Judge entered an Order Granting in part IBM's Motion to Limit Claims. The Magistrate Judge found that SCO had willfully violated court orders by failing to provide version, file and line information for all technology that IBM misused. Notwithstanding the 497 pages of detailed disclosures and supporting source exhibits, the Magistrate Judge analogized SCO to a person accusing someone of shoplifting but refusing to say what goods were taken. The Magistrate Judge speculated that SCO must be seeking to sandbag IBM only to spring additional evidence in the "ninth inning." What the Order characterized as the "most important" factor in the Magistrate Judge's finding that SCO knew it had to provide source code coordinates for

12

all items and could do so was how SCO had defined "identify" in a discovery request served at the outset of the case. This argument appeared for the first time in the Davis Rebuttal Declaration to which SCO was not allowed to respond. The Magistrate Judge did not address SCO's request for an evidentiary hearing and for item-by-item consideration of the specificity of the disclosures provided. The Order proceeded to strike from SCO's case 187 of the 198 disputed items.

III. THE MAGISTRATE JUDGE'S ORDER SHOULD BE REVIEWED DE NOVO FOR COMPLIANCE WITH THE STRICT STANDARDS REGARDING STRIKING OF CLAIMS AS A DISCOVERY SANCTION.

Under Federal Rule of Civil Procedure 72(b), this Court reviews de novo a magistrate judge's orders with respect to dispositive matters. Any order (including one imposing a discovery sanction) having the "identical effect" to an order on summary judgment resolves a dispositive matter within the meaning of Rule 72(b). Ocelot Oil Corp. v. Sparrow Indus., 847 F.2d 1458, 1462 (10th Cir. 1988); accord 12 Wright, Miller & Marcus, Federal Practice And Procedure § 3068.2 (2d ed. 2006). By granting with respect to 187 out of 198 challenged items an IBM motion that expressly requests the Court to "Limit SCO's Claims," the Magistrate Judge's Order has dispositive effect. See e.g., American Stock Exch. v. Mopex, 215 F.R.D. 87, 92 (S.D.N.Y. 2002) (finding where plaintiff had asserted numerous patent claims of the patent at issue under one cause of action, the Magistrate Judge's order precluding evidence on one of the claims within a patent constituted a dispositive ruling, even though the plaintiff could still pursue other

13

patent claims which were covered by the overall cause of action.) Accordingly, this Court should perform a de novo review.5

The Court's consideration of the Order should begin with whether SCO did not comply with a clear order of the Court regarding discovery. See, e.g., Robson v. Hallenbeck, 81 F.3d 1, 4 (1st Cir. 1996) (vacating the district court's imposition of sanctions and emphasizing the need for "a clear preexisting requirement"); see also Part V, below. In seeking sanctions, the moving party has the burden of showing noncompliance with "a specific and definite order of the court." FTC v. Enforma Natural Prods., Inc., 362 F.3d 1204, 1211 (9th Cir. 2004) (emphasis added) (reversing contempt sanctions).

Only if there is a finding of non-compliance with an unambiguous order should the Court consider whether the noncompliance was willful. A party's non-compliance with a court order is sufficient grounds for the "harsh sanction" of dismissal of a claim "only when it is the result of willfulness, bad faith, or some fault of petitioner rather than inability to comply." M.E.N. Co. v. Control Fluidics, Inc., 834 F.2d 869, 872 (10th Cir. 1987) (quotations omitted). Willful failure is "any intentional failure as distinguished from involuntary noncompliance." Id. at 872-73.

A court's discretion to impose a discovery sanction is "further limited in that the chosen sanction must be both just and related to the particular claim which was at issue in

14

the order to provide discovery." Procter & Gamble Co. v. Haugen, 427 F.3d 727, 738 (10th Cir. 2005) (quotations omitted) (citing Ehrenhaus v. Reynolds, 965 F.2d 916, 920 (10th Cir. 1992)). When evaluating a sanction, a court should bear in mind the judicial system's "strong predisposition to resolve cases on their merits." Id. Where, as here, a sanction involves preclusion of a claim, "a district court should ordinarily evaluate the following factors on the record: (1) the degree of actual prejudice to the other party; (2) the amount of interference with the judicial process; (3) the culpability of the litigant; (4) whether the court warned the party in advance that dismissal of the action would be a likely sanction for noncompliance; and (5) the efficacy of lesser sanctions." Gripe v. City of Enid, 312 F.3d 1184, 1187 (10th Cir. 2002) (quotations, brackets, and ellipses omitted) (citing Ehrenhaus, 965 F.2d at 921). An analysis of these five factors (the "Ehrenhaus Factors") allows the appellate courts to engage in "meaningful review" of the imposition of a sanction. Procter & Gamble, 427 F.3d at 738 (citing Mobley v. McCormick, 40 F.3d 337, 341 (10th Cir. 1994)). A court's failure to consider the Ehrenhaus Factors on the record generally "amounts to an abuse of discretion." Id. at 738-39.

IV. SCO COMPLIED WITH THIS COURT'S DIRECTION TO IDENTIFY "MISUSED MATERIAL" WITH "SPECIFICITY."

A. The Magistrate Judge Clearly Erred in Concluding That the July
2005 Order Required "Version, File & Line" Information for
Methods and Concepts.

The July 2005 Order required the parties "to identify with specificity all allegedly misused material," which is what SCO did in its December Submission: for misused source code SCO identified the lines of code, and for misused methods and concepts SCO specifically identified the method and concept that was disclosed. Where the method and concept contributed by IBM identified source code, such as a code patch, a

15

specific reference to that code was provided. Destination files in Linux source code for virtually all the items in the December Submission were provided.

What SCO did not do, and did not believe it had to do, was provide a source code identifier for a method and concept where source code (either written as a patch for Linux or an example from a Dynix or other IBM system) was not provided as part of the IBM disclosure to Linux. When the contribution itself did not consist of source code, how can SCO be required to define it by source code? Where IBM included a reference to a Dynix or AIX file as part of the disclosure, SCO did designate that reference. SCO is essentially being sanctioned here for not having deduced the source code that IBM developers had in mind when they disclosed a method and concept without using source code, but expressly stated that the contribution came from Dynix or another UNIX derivative system. With respect to the destination in Linux of such contributions, SCO identified files in Linux it believed were impacted by the contribution, which was the most specific level of information SCO was able to determine after expert investigation by December 2005.

This level of specificity, especially when coupled with precise and complete descriptions of the method or concept usually by verbatim quoting of the IBM communication constituting the disclosure complies with this Court's July 2005 Order. SCO agrees that it would have been insufficient for SCO to have "generally" identified methods and concepts, such as just by saying IBM disclosed methods and concepts regarding Read-Copy-Update or NUMA. SCO did not do this. It provided highly specific descriptions, with citation, for virtually all of the methods and concepts in question. If SCO provided the detail of the disclosure that was sufficient for the Linux

16

developers to make use of the method or concept as IBM witnesses and documents admit, it certainly should be deemed specific enough for the discovery obligations in this case and for IBM to prepare its defense.

The July 2005 Order required no more. The Order plainly did not state that the "version, file and line" in source code must be provided so as to identify the item with specificity. (The Magistrate Judge does not say that was what the Order stated, but rather acknowledges that this meaning is what the Magistrate Judge "believes" the Court intended.)

IBM had proposed language that would have expressly required version, file, and line identification for each technology item; that language was not adopted in the Court's Order. Specifically, IBM's proposed scheduling order included a footnote that provided:

For this purpose, allegedly misused material must be identified by version, file, and line of code. For example, to the extent a party contends the other party has infringed its copyrights, the accusing party must identify and match up the allegedly infringing and allegedly infringed material by version, file, and line of code. To the extent a party contends that the other party has breached its contractual obligations by contributing code to Linux, the accusing party must identify the material alleged to have been contributed improperly by version, file and line of code and to the extent the allegedly contributed material is not Unix System V code, but is in any sense alleged to have been based on or resulted from Unix System V code, the version, file and line of Unix System V code from which the allegedly contributed material is alleged to derive or result.
(IBM's Proposed Amended Scheduling Order (Mar. 25, 2005), at 2, n.2). The Court omitted IBM's proposed footnote from its final order. It is clear error for SCO to be sanctioned so severely for failing to meet the standard that this Court itself rejected in its Order.

17

Further, while it was within the Court's authority to implement this additional discovery deadline and process, it should nevertheless be recognized that interim and final submissions to identify "allegedly misused material" are not part of a standard discovery process under the Federal Rules of Civil Procedure. There is no "standard" way to prepare an interim and final identification of misused material there is no established level of specificity, no federal rule of procedure to guide the process nor case precedent to rely upon. Where a unique discovery process such as this is employed, reasonable berth in implementing those processes is appropriate, particularly where, as here, a declaration is filed under oath asserting full effort to comply and there is no evidence a party withheld evidence in its possession.

In addition, SCO cannot be faulted for not providing more detail than the particular item disclosed allows. Certainly, for source code contributions IBM made verbatim from a UNIX derivative system, such information can be provided and has been. Where the method and concept is not associated with source code, the contribution cannot be identified by source code and such is not required to uphold SCO's claim.

B. The Magistrate Judge Clearly Erred to the Extent the Order Is
Predicated on SCO's Responses to Past Discovery Orders or IBM
Interrogatories.
Although the focus of IBM's opening brief was on the December Submission's alleged noncompliance with the July 2005 Order, in the Magistrate Judge's Order, SCO's interrogatory responses became the central concern.

The Magistrate Judge's December 2003 Order required SCO, in relevant part, to respond to IBM Interrogatory Nos. 1 through 9, 12 and 13, and to "to identify and state with specificity the source code(s) that SCO is claiming form the basis of their action against IBM." (December 2003 Order, at 2). The Magistrate Judge's March 2004 Order

18

recognized that SCO had made "good faith efforts to comply with the Court's prior order," and further required SCO, in relevant part to: (1) "provide and identify all specific lines of code that IBM is alleged to have contributed to Linux"; (2) "provide and identify all specific lines of code from Unix System V from which IBM's contributions from AIX or Dynix are alleged to be derived; (3) "provide and identify with specificity all lines of code in Linux that it claims right to"; and (4) "provide and identify with specificity the lines of code that SCO distributed to other parties."

None of these orders or interrogatories says what the Magistrate Judge now holds was required that all misused material of any type, even material that did not include source code, must be identified by "version, file and line of code." Specifically, the December 2003 Order compelled SCO to respond to IBM interrogatories. In the Magistrate Judge's current analysis of this Order, the focus is on Interrogatory Nos. 1, 4, 12, and 13, but none of these interrogatories in fact supports the conclusion reached.

IBM Interrogatory No. 1 states:

Please identify, with specificity (by product, file and line of code, where appropriate) all of the alleged trade secrets and any confidential or proprietary information that plaintiff alleges or contends IBM misappropriated or misused, including but not limited to as alleged in ¶ 105 of the Complaint.
(Exh. 3). (Emphasis added.) The limiting language "where appropriate" is critical. In some cases misused information is appropriately identified by product, file and line of code. This type of identification would be appropriate for source code that was misused by IBM; however, such identification would not be appropriate for methods or concepts that were misused by way of a disclosure of the method or concept without a disclosure of related source code. (See Rochkind Decl. ¶¶ 8-10, Exh. 2 (comparing the appropriate

19

mechanisms to identify misused source code versus misused methods and concepts).) SCO complied with this interrogatory request by identifying misused material by product, file and line of code, where appropriate. Furthermore, IBM's inclusion of the limiting phrase "as appropriate" in this interrogatory constitutes recognition even with respect to other requests that such source code identification is not always appropriate. Interrogatory No. 4 states, in pertinent part:

Please describe, in detail, each instance in which plaintiff alleges or contends that IBM misappropriated or misused the alleged trade secret or confidential or proprietary information, including but not limited to: . . . (d) with respect to any code or method plaintiff alleges or contends that IBM misappropriated or misused, the location of each portion of such code or method in any product, such as AIX, in Linux, in open source or in the public domain.
(Exh. 3). This interrogatory thus requests the "location" of "each portion" of misused "code or method" in "any product, such as AIX, in Linux, in open source or in the public domain." "Location" is certainly not synonymous with "version, file and line of code." SCO complied with this request by identifying the "location" of misused material as it did, with the most specific information available including references to the verbatim disclosures that admitted the particular method or concept came from Dynix or AIX. Interrogatory Nos. 12 and 136 request the identification of material "with specificity (by

20

file and line of code) in Linux to which SCO claims that it "has rights." To the extent that SCO can provide such identification by line it has done so, and otherwise it has complied by identifying the files relating to the method or concept. There has been, prior to this ruling, no Order that such a level of identification is inadequate, and that SCO must do more our could do more or face the striking of its claims.

The Magistrate Judge's March 2004 order also arose out of IBM seeking, in relevant part, more specific answers to these same interrogatories. Thus, like the December 2003 Order, this Order is understood against the backdrop of the interrogatories. However, even if the order could be read as going beyond IBM's interrogatories, SCO complied with the order to the greatest extent possible. The part of the March 2004 Order quoted and relied on by the Magistrate Judge focused on the direction that SCO identify those "specific lines of code" from AIX, Dynix and Unix System V that IBM is alleged to have contributed to Linux. In compliance with this order, SCO did identify for IBM those specific lines of code that it contends IBM disclosed improperly to Linux, and provided file locations in Linux where identification of lines was not possible.

Neither order required SCO to identify for IBM the specific lines of code that comprised the method that was disclosed, when those lines of code had not even been part of the disclosure by IBM, and were not reasonably available to SCO. Such an interpretation of the court's orders would have been most unreasonable since they would essentially be requiring SCO to identify, for IBM, code that was solely in the mind of the

21

IBM developer at the time he or she made the disclosure. Counsel for SCO is aware of no instance in which a party has been sanctioned let alone substantive portions of its case dismissed for failure to identify in discovery information that was not reasonably available to it and was more readily available to the other party. (See Part V, below.)

In addition, IBM's own conduct undercuts the Magistrate Judge's reliance on previous court orders and interrogatories as a basis for sanctions. In February 2006, several weeks after SCO had served its December Submission, IBM served its Interrogatory No. 23, asking SCO to provide additional information regarding the December Submission. In subsection (b) of Interrogatory No. 23, IBM asked SCO to "state with specificity" with respect to each "method and concept" identified by SCO "whether it appears in Linux and, in particular, the Linux kernel and, if so, which version(s) of Linux, and which files and lines of such version(s)." (Exh. 5.) IBM's service of that interrogatory obviously undercuts the argument that SCO had previously been obligated to provide such source code coordinates, either in response to any previous IBM discovery request or in order to comply with any court order. It would have been redundant and, thus, improper for IBM to have served such an interrogatory.

After filing its underlying motion to limit SCO's claims, however, IBM withdrew just subsection (b) of Interrogatory No. 23. In withdrawing that request in the interrogatories, counsel for IBM admitted that the request "is confusing in any case." (Exh. 6.) IBM's admission that the foregoing request "is confusing" directly undercuts any argument that either the IBM discovery requests or any court order clearly and unambiguously required SCO to produce Linux source code coordinates for methods and concepts that IBM contributed to Linux. However, the issuance of the interrogatory in

22

the first place is inconsistent with the premise that all such information was required by prior requests. In short, the Magistrate Judge's prior discovery orders did not clearly require and IBM's interrogatories did not ask SCO to identify the version, file and line information for each and every item of misused material.7

C. The Magistrate Judge Clearly Erred in Concluding That SCO's Past
Interrogatories and the Deposition Testimony of SCO's Chief
Technology Officer Support the Order's Interpretation of the Past
Orders.
The Magistrate Judge found that her interpretation of the July 2005 Order "really should come as no surprise" to SCO, on the basis of a definition contained in SCO's early discovery requests to IBM and the deposition testimony of Sandeep Gupta, a SCO employee. These arguments were not included in IBM's briefing on the Motion, but rather were raised for the first time in the Davis Rebuttal Declaration, to which SCO was denied an opportunity to respond. Neither of these secondary sources provides support for the Magistrate Judge's conclusion about how SCO must have interpreted the July 2005 Order. These issues, as presented by Professor Davis, are taken seriously out of context, as explained below. The Magistrate Judge also draws an analogy to the deposit requirements for copyright registration in support of the conclusion reached, which also was not briefed and has no bearing here.

23

1. SCO's Past Discovery Requests
Professor Davis asserted in his Rebuttal Declaration: "Note that the Court's orders required no more of SCO than SCO required of IBM." (Davis Rebuttal Decl. ¶ 19.) He then explained that SCO defined "identify" in its First Request for Production of Documents and First Set of Interrogatories as:
including but not limited to an identification of the specific lines and portions of code claimed as trade secrets or confidential or proprietary information, and the location (by module name, file name, sequence number or otherwise) of those lines of code within any larger software product or property.
Id. He then stated: "SCO subsequently incorporated this identical definition in eight additional document requests, five additional sets of interrogatories, seven 30(b)(6) deposition notices, and three requests for admission . . . ." (Id.) Professor Davis attached SCO's First Request for Production of Documents and First Set of Interrogatories (also attached hereto as Exh. 7), which included the definition, but did not attach any of the other referenced discovery requests, or IBM's responses. The fact is that the context of SCO's discovery requests and IBM's responses shows that SCO's discovery requests have no relevance whatsoever to the issue at hand.

While SCO did not have an opportunity to respond to and correct Professor Davis' misleading argument about SCO's early discovery requests, the Magistrate Judge seized on his argument and even labeled it (at 27) as "most important to the court" in reaching her decision. Furthermore, apparently without ever having seen IBM's responses to SCO's discovery requests (which were not provided by Professor Davis), the Magistrate Judge concluded (at 28):

24

Given SCO's track record in this case, the court is certain that if IBM had simply provided line information without version and file information for `methods,' SCO would have filed motions to compel complaining about IBM's lack of specificity.
As a threshold matter, the Magistrate Judge misunderstood the nature of SCO's discovery request. While the language cited by Davis was a definition used in SCO's discovery requests (not a stand-alone request), the Magistrate Judge wrote (at 27) that: "SCO itself sought this level of specificity by asking for `identification of the specific lines and portions of code' for all alleged trade secrets or confidential or proprietary information, whether computer code, methods or otherwise." Because this language is a definition, not a stand-alone discovery request, the language is only properly understood in the context of the specific discovery requests that use the defined term "identify."

Notably, in SCO's First Request for Production of Documents and First Set of Interrogatories (Exh. 7) (where the definition of "identify" at issue appears), all of SCO's "identify" interrogatories (Nos. 1, 3, 4 and 5) are directed at "persons." Naturally, "identify," when used in the context of "persons," was defined differently by SCO. None of the interrogatories in this initial request requires IBM to identify methods by line of code. The Magistrate Judge also suggested (at 25) that SCO's first motion to compel (filed November 4, 2003) incorporated the above definition of "identify." To the contrary, that motion was based only on IBM's failure to respond to these initial discovery requests, did not reference this definition, and certainly did not seek identification of methods and concepts by "the specific lines and portions of code."

It was not until SCO's Second Set of Interrogatories (served December 4, 2003) that SCO propounded an interrogatory request that implicated the above definition of "identify." In Interrogatory No. 6, SCO stated:

25

Please identify, with specificity (by product, file in light [sic] of code, where appropriate) all of the alleged contributions to Linux made by IBM, included but not limited to those claimed in paragraphs 108, 115 and 120 of IBM's Amended Counterclaims.
(Exh. 8). Emphasis added. Importantly, as in IBM's request, this request for files and code was qualified by the language "where appropriate." In other words, the first time SCO requested line and file information of code contributed to Linux, SCO qualified the request to say that methods should only be identified by specific lines or portions of code "where appropriate" just as IBM did in its first such request. That is all SCO contends it was obligated to do in responding to IBM, and is what SCO did do -- identify files and code "where appropriate."

Moreover contrary to the Magistrate Judge's assumption that "if IBM had simply provided line information without version and file information for `methods,' SCO would have filed motions to compel complaining about IBM's lack of specificity" IBM did not provide any "methods" or code in response to this request, let alone identification of methods it contributed to Linux by "specific lines or portions of code," and no Motion to Compel was filed on this. Rather, IBM's sole response to this request was an objection that the request was vague, overbroad, and unduly burdensome; a statement that its contributions are a matter of public record; and a reference to a lengthy list of produced documents. (IBM Response to SCO's Second Set of Interrogatories and Second Request for Production of Documents, Exh. 9). In short, contrary to the Magistrate Judge's assumption, IBM did not provide "specific lines or portions of code" in response to SCO's discovery request, and SCO certainly did not ask the Court to compel IBM to identify the methods it disclosed by "specific lines or portions of code" when the method was not disclosed to the Linux community with that level of specificity.

26

The definition of "identify" was also implicated in SCO's Fifth Set of Interrogatories. In Interrogatory 23, SCO requested IBM to "identify" IBM's reliance on UNIX in its contributions to Linux. (Exh. 10). Again, in its response to Interrogatory 23, IBM did not identify any methods on which it relied, let alone identify them via specific lines of code. Rather, IBM stated that SCO's request was vague, ambiguous, overbroad, and unduly burdensome. Further, IBM admitted (without providing any specific information) that:

"IBM has, in making Linux contributions, used or relied upon source code that may also be found in AIX or Dynix. IBM has used or relied upon source code also found in AIX or Dynix by offering the actual code to Linux and/or considering the code in creating new code."
(Exh. 11). In short, contrary to the Magistrate Judge's assumption, IBM's response to SCO's request that IBM identify its reliance on UNIX products, including IBM and Sequent's use of UNIX methods or concepts, in developing source code that IBM contributed to Linux, was vastly less specific than SCO's identification of misappropriated methods and concepts in its December Submission. Furthermore, SCO never sought from IBM more specific identification of the methods that it had disclosed, when those methods had not been disclosed by reference to specific code. However, such code would have been considerably easier for IBM to provide than SCO, since it is code IBM developers had in mind when disclosing a method or concept to the Linux community without mentioning the specific code in the disclosure.8

27

In addition, even if the SCO requests for discovery were exactly as characterized by Professor Davis, and as accepted by the Magistrate Judge, the use of an expansive definition in an early discovery definition where parties regularly ask for as much information as possible hardly constitutes support for the concept that for a specific subset of technology at issue (methods and concepts) source code is always available to be provided and court orders requiring identification of "misused materials" must be so interpreted.

The Magistrate Judge's reliance on this point as the most important factor in support of the June 28 Order is clearly in error.

2. Deposition Testimony of Sandeep Gupta
In his Rebuttal Declaration, Davis also relied (for the first time) on the deposition of Sandeep Gupta, SCO's Chief Technology Officer. He opined that Mr. Gupta testified concerning the importance of having version, file and line information with respect to methods and concepts, and he quoted a portion of that deposition. Although Mr. Gupta's deposition was not attached to the Rebuttal Declaration (nor even the entire relevant portion of the deposition), and although SCO never had an opportunity to respond to this introduction of new testimony to the record, the Magistrate Judge relied on it (at 28) "as further support of this court's finding that version, file, and line information was the required level of specificity."

The Magistrate Judge quoted (at 28) only a portion of the testimony that had been quoted in the Davis Rebuttal:

A. Okay, how would you determine whether a particular description was specific enough to describe an aspect of System V as a method?
A. I have to look at the source code.
Q. Okay. What would you do if you looked at the source code?

28

A. I look at various steps that are taken, specific for that particular method.
Q. Okay. So in order to determine what a particular method or concept is, you would actually have to look at the source code?
A. In some cases, yes. .....

Q. . . . would you have to look at the source code to be able to accurately describe a method or concept in UNIX?
A. That's my opinion, yes.

This testimony does not support IBM's position that coordinates in source code are always available and always needed. Mr. Gupta testified that one would need to look at the source code of a particular method to identify it only "in some cases."

In addition, Mr. Gupta's testimony neither establishes that court orders had to be understood as requiring SCO to ascertain what source code IBM developers were thinking of when making their method and concept contributions to Linux or that SCO had the ability to provide such information even if it were ordered. It would be most extraordinary for deposition testimony to bear on the interpretation of a court order.

In sum, neither the July 2005 Order nor other orders required SCO to do more than what it has done provide identification with "specificity" of the materials allegedly misused by IBM, and when source code is the basis of SCO's claim, to provide identification by source code coordinates.

3. Analogy to Deposit Requirement for Copyright Registration
The Magistrate Judge also drew an analogy to the deposit requirements for copyright registration. This argument was never advanced by IBM and SCO never was given an opportunity to respond. From these deposit requirements, the Magistrate Judge concluded that "even the copyright law, from which SCO seeks protection, prefers the production and identification of specific source code." (Order at 29-30). The deposit requirements for copyright registration have no relevance to the interpretation of past

29

court orders or SCO's reasonable understanding of those orders. Copyright law includes these deposit requirements because it protects "expression." The items the Magistrate Judge purports to strike from SCO's case in actuality are parts of SCO's claim for breach of contract not copyright infringement. SCO is seeking protection (and damages for the disclosure) of these items under contract law not copyright law. Moreover, even if such source code is "preferred" as the Magistrate opined, that does not mean that it is "required" or always available. Therefore, the deposit requirements for a copyright registration can have no possible relevance to the conclusion for which it is offered.

V. THE MAGISTRATE JUDGE CLEARLY ERRED IN FINDING THAT SCO WILLFULLY FAILED TO COMPLY WITH COURT ORDERS REQUIRING SPECIFICITY.

A. The Magistrate Judge Clearly Erred Because to Support a Discovery
Sanction, an Order Must Clearly and Unambiguously State the
Performance Required of a Party.

The Magistrate Judge says that "it really should come as no surprise" to SCO that she infers the meaning she does from the July 2005 Order. That is no basis for a discovery sanction which requires clear notice of what is required. A party cannot be sanctioned for failing to comply with an ambiguous court order that is later interpreted contrary to the party's own interpretation. See Robson, 81 F.3d at 3-4 (vacating the district court's imposition of sanctions and emphasizing the factor of "a clear preexisting requirement"). In seeking sanctions, the moving party has the burden of showing noncompliance with "a specific and definite order of the court." Enforma, 362 F.3d at 1211 (emphasis added) (reversing contempt sanctions). Where there is an "arguable ambiguity in the Court's prior rulings," even where the court subsequently interprets the order against the non-moving party, there is no proper basis for sanctioning a party for failing to produce the material at issue. Williams, 230 F.R.D. at 656 (finding no basis to impose

30

sanctions); cf. Peterson v. Hantman, 227 F.R.D. 13, 18 (D.D.C. 2005) (finding no basis to impose sanctions for non-production of certain material: "If there is an absence of controlling authority, and the issue presented is one not free from doubt and could engender a responsible difference of opinion among conscientious, diligent but reasonable advocates, then the opposing positions taken by them are substantially justified." (citation and quotations omitted)).

Indeed, the same principles apply even where in sharp contrast to the facts here a party has withheld material that a court later determines should have been produced by court order. See R.W. Int'l Corp. v. Welch Foods, Inc., 937 F.2d 11, 17 (1st Cir. 1991) (stating that "when a court issues a broad-form discovery order, and the party to whom it is addressed complies with it somewhat less than fully, withholding documents arguably outside the order's scope, the district court cannot dismiss without first entering an order commanding production of the specific materials"). The necessity of a clear requirement also applies with respect to responses to interrogatories. See, e.g., T.N. Taube Corp. v. Marine Midland Mortgage Corp., 136 F.R.D. 449, 456-57 (W.D.N.C. 1991) (declining to impose sanctions based on defendant's responses and opposition to certain interrogatories because "[a]lthough the Court has determined that Defendant failed to comply with the provisions of Rule 33(c), the question is not so clear as to render Defendant's opposition substantially unjustified").

Thus the fact that the Magistrate Judge now interprets court orders to require a certain level of specificity does not render SCO's actions sanctionable. Given that the Magistrate Judge is relying on what she "believes" this Court's July 2005 Order meant, rather than what it expressly said, and then upon such secondary materials as inferences

31

from SCO's own discovery requests and a witness's deposition, the standard of clarity to support a sanction is not met here. The fact that the Magistrate Judge had to refer to unanalyzed discovery requests, incomplete deposition testimony and copyright registration procedures to explain what the court found should have been no surprise to SCO about the unstated meaning of July 2005 Order defeats the very point they were meant to support.

B. There Is No Record Evidence That SCO Willfully Violated a Court
Order Or Declined to Respond to Interrogatories
Only willful noncompliance with a court order could support a sanction as severe as the one imposed here. (See Part III, above). The Magistrate Judge's Order does not state otherwise. However, there is no evidence presented by IBM or cited by the Magistrate Judge that SCO intentionally refused to provide source code information that it possessed. It is well established that if a party cannot comply with an order, its failure cannot be deemed willful and cannot support a sanction. A party can be ordered to produce on pain of sanction only material that the party possesses. See Cardenas v. Dorel Juvenile Group, Inc., 230 F.R.D. 611, 620 (D. Kan. 2005) ("The Court cannot compel the production of documents that do not exist or that are not in the possession, custody or control of a party."); accord Sonnino v. Univ. of Kan. Hosp. Auth., 220 F.R.D. 633, 640 (D. Kan. 2004); Steil v. Humana Kansas City, Inc., 197 F.R.D. 445, 448 (D. Kan. 2000). A party "possesses" material if it physically has the material in hand or if it has "control" of the material, and a party does not have control of material if it otherwise does not have "the practical ability" to obtain the material. In re Flag Telecom Holdings, Ltd. Secs. Litig., No. 02 Civ. 3400 (WCC), 2006 WL 1072008, at *2 (S.D.N.Y. Apr. 19, 2006) (attached hereto as Exh. A, Decl. of Mark James); see, e.g., Kropp v. Ziebarth, 557 F.2d

32

142, 147 (8th Cir. 1977) (reversing dismissal as sanction for failure to answer interrogatories where "review of the record reveals that there is some merit to Kropp's position that he was unable to respond more fully to the defendants' interrogatories than he did," and holding: "Dismissal is not authorized under Fed.R.Civ.P. 37 when the failure to comply is the result of inability rather than willfulness or bad faith."). Sithon Maritime Co. v. Holiday Mansion, No. Civ. A. 96-2262-EEO, 1998 WL 638372, at *4 (D. Kan. Sept. 14, 1998) (declining to impose sanctions with respect to responses to discovery requests for production of documents where "plaintiff has provided no evidence of deliberate and purposeful withholding of documents") (attached hereto as Exh. B, Decl. of Mark James). Zappala v. Albicelli, 954 F. Supp. 538, 548 (N.D.N.Y. 1997) (declining to impose sanctions where "the record indicates that the Defendants have made a good faith effort to comply with the Plaintiffs' voluminous discovery requests" and that "the Defendants have not `failed' to answer the interrogatories").

The Magistrate Judge stated that "There is no evidence before the Court to indicate that SCO lacked the ability to comply with the Court's Orders." In the first place, there was no evidence to establish a willful violation, and thus, to establish that SCO could provide source code information that it was simply failing to turn over. Moreover, SCO presented evidence that it could not comply with such an order. Marc Rochkind, SCO's expert witness filed a declaration explaining: "Where IBM disclosed methods and concepts from the Dynix and Dynix/ptx operating systems without providing source code in the disclosures, for example, it is often not possible and certainly not necessary to cite to specific source code in identifying the disclosure." (Rochkind Decl. ¶ 10, Exh. 2 (emphasis added).) Mr. Rochkind also testified that he

33

"made sure" that "versions, lines and files be cited where available." (Rochkind Decl. ¶ 17, Exh. 2 (emphasis added).)

Even if it were theoretically possible to match up every method or concept with source code implementing the method, as Professor Davis contends, it does not follow that SCO was able to do so. The items in the December Submission for which such source code information was not provided were methods and concepts where IBM did not identify the source code implementing the method in Dynix or AIX, but did definitively state that Dynix or AIX was the operating system from which the technology came.9 In these situations, IBM is asking the Court to sanction SCO for not ascertaining what lines of code an IBM software engineer may have pointed to if asked to identify where in Dynix or AIX the method or concept is implemented. The operating system from which the overwhelming majority of method and concepts were taken is an IBM system (such as Dynix or AIX) written or modified by IBM developers (or Sequent employees now working at IBM). While these operating systems are derivative products of UNIX System V, subject to the restrictions on disclosure and use contained in licensing agreements, Dynix and AIX are operating systems created and maintained at IBM, not at SCO. If, as Professor Davis opines, it is an "impossible burden" (¶ 21) requiring an extraordinary number of man-years (¶ 16) to identify the code related to such disclosures, it would take SCO even longer, as it would not have the aid of the IBM developers who actually wrote the code and made the disclosures.

34

This fact -- that IBM has control and the ability to locate the information at issue to a significantly greater extent than SCO -- is directly relevant, and inexplicably ignored by the Magistrate Judge. In basing her Order on SCO's failure to produce evidence that SCO does not "control," the Magistrate Judge committed clear error.

Moreover, Mr. Rochkind's testimony goes further and establishes that where SCO did have source code coordinates, it was provided. There are roughly 100 items not challenged by IBM that are largely source code disclosures. In addition, "for many of the challenged items in the December Submission, there is code imbedded in the disclosure email or other document, or found at a referenced URL (internet website) address." (Rochkind Decl. ¶ 11, Exh. 2.) For example, Item No. 3 (Exh. 13) is NUMA/ptx locking routines contributed to Linux. The December Submission states (at 5) that the "code in the 4 associated source code files appeared in a patch for the 2.4.6 kernel" and provides an internet address for the patch. Inexplicably, items such as this and others of similar nature have been struck.

Mr. Rochkind's declaration is irreconcilable with a finding of willful violation by SCO. He says that he played the largest role in assembling the disclosures, and that "For each of the 294 items, I did everything I could to ensure that everything we had was disclosed and that it was organized in the most accessible manner." (Rochkind Decl. ¶ 17, Exh. 2).

The Magistrate Judge's Order goes so far as to strike SCO submissions where the code associated with a particular method and concept is cited in the Report, but cannot be accessed because it resides in an IBM server to which only IBM has access. This is true, for example, of Item No. 146, involving differential profiling. (Rochkind Decl. ¶¶ 13-15,

35

Exh. 2.) This was in fact the only misused method that IBM's expert discussed. Rochkind explained that the disclosed method includes a URL to Dynix source code that SCO could not access: "The URL referencing the Dynix/ptx scripts is for an internal IBM server to which neither SCO nor I have access. It is part of the Linux development materials that SCO sought from IBM, but that appear not to have been produced. Accordingly, the actual code cannot be present in Item No. 146, although IBM has access to it." (Rochkind Decl. n. 3 at 6, Exh. 2) (emphasis added).) In stating that there was "no evidence" before her of SCO's inability to comply with the July 2005 Order as she interpreted it, the Magistrate Judge thus ignored the foregoing expert testimony and compounded her erroneous decision not to consider such evidence with respect to the Items individually.

With respect to the identification of locations in Linux where the disclosed method and concept may have had an impact, there also is no showing by IBM that SCO is withholding any information. As indicated in Rochkind's declaration, and an attached chart, and as can be seen by perusing the December Submissions, for virtually every item, files in Linux are identified where the contribution, if source code, would be found, or if a method and concept or other know-how, would most likely have an effect. (SCO does not contend that every disclosure has already manifested itself in Linux but that does not negate a breach for the unauthorized disclosure itself.) (See Rochkind Decl. Exh. B, Column D, Exh. 2.)10 There is no finding by the Magistrate Judge, and no basis for such a finding, that SCO willfully violated judicial orders by having the ability to provide line references within Linux files, but not doing so.

36

Lacking any direct support for finding a willful violation, the Magistrate Judge drew an inference from SCO public statements about the case that such information was present. In 2003, SCO said at that time that it possessed evidence of lines of source code misappropriated into Linux. Those statements do not mean that SCO possessed such evidence regarding the 198 methods at issue in IBM's motion, and the Magistrate Judge made no effort whatsoever to link any statement to any Item. The statements in fact were based on SCO's knowledge of technologies pertaining to many Items that were not at issue in IBM's motion, including Items 150-164, 183-185 and 205-231. The point-by- point defense provided in Appendix A to this Memorandum shows that the statements were accurate. Indeed, the items in the December Submissions involving source-code contributions show that the statements by SCO executives in 2003 were, if anything, understated. SCO would have made these points to the Magistrate Judge if the question of SCO's public statements had even been made a subject of the motion by IBM. The fact is that SCO's experts identified in 2005, well after SCO made the statements cited by the Magistrate Judge, all or almost all of the 187 methods and concepts the Court dismissed.

The record below establishes that SCO believed its December Submission was in full compliance with the July 2005 Order, and that SCO had certified its discovery responses as complete. With respect to the Magistrate Judge's reference to SCO not having sought "clarification," her finding overlooks the well-established law that where there is a "genuine dispute" between the parties regarding the scope of the court order or discovery request at issue, sanctions for noncompliance is unwarranted regardless of

37

whether the responding party sought clarification of an order that, in retrospect, could be interpreted in a different way. (See Part IV, above.)

In Societe Internationale Pour Participations Industrielles et Commercials, S.A. v. Rogers, 357 U.S. 197, 210 (1958), the plaintiff failed to comply with a discovery order, where compliance would have constituted a violation of Swiss law and where the plaintiff had unsuccessfully sought to obtain a waiver from that law. The district court and court of appeals concluded that sanction in the form of the dismissal of the plaintiff's complaint were appropriate for the non-compliance. The Supreme Court reversed, answering in the affirmative "the question whether Fifth Amendment due process is violated by the striking of a complaint because of a plaintiff's inability, despite good-faith efforts, to comply with a pretrial production order." As the Tenth Circuit subsequently explained in In re Westinghouse Electric Corporation Uranium Contracts Litigation, 563 F.2d 992 (10th Cir. 1977), the operative facts in Rogers were that the plaintiff "had made a good faith and diligent effort to comply with the local discovery order, and had tried to secure a waiver from the foreign government." Id. at 998. Presented with similar facts regarding Canadian regulations, the Westinghouse court held that sanctions for noncompliance were unwarranted where third-party Rio Algom "has made diligent effort to produce materials not subject to the Canadian regulation," and "has sought a waiver from the Canadian authorities." Id.

The decision in Rogers (and Westinghouse) broadly establish that a party cannot be sanctioned for non-compliance with a discovery order or request where despite its diligent, good-faith efforts, the party is unable to comply or respond. See, e.g., Miller v. Sprint Communications, No. 3:97CV156-P, 1997 WL 910426, at *2-3 (W.D.N.C. Dec.

38

31, 1997) (citing Rogers and imposing sanctions only where "Plaintiff has acted in bad faith" by failing to appear for deposition and failing to offer any explanation.) (Attached hereto as Exh. C, Decl. of Mark James). The record below shows that SCO and its experts made such good-faith efforts, and that the Magistrate Judge failed to take account of the extent of those efforts. The foregoing precedent applies with particular force where SCO does not assert, and need not assert to support the merits of its claims or requests for relief, that all of the methods and concepts disclosed have yet been implemented in Linux.

In short, there is neither the clarity required of a court order to support a severe sanction such as this nor direct or even indirect support that SCO acted willfully in violating such an order by withholding any information regarding source code locations for the disputed items.

VI. THE MAGISTRATE JUDGE CLEARLY ERRED IN FAILNG TO
CONSIDER WHETHER SPECIFIC DISCLOSURES WERE ADEQUATE.

SCO requested a hearing to have the Magistrate Judge address SCO's Items individually and to hold an evidentiary hearing to allow SCO's experts to address the particular facts regarding each of them. (Hearing Transcript (Apr. 14, 2006) at 52-56, 79- 82, Exh. 14). The Magistrate Judge did not address SCO's request and did not hold an evidentiary hearing. The Magistrate Judge thus did not allow for a process where the parties could address the identification of the misused material item-by-item, and present testimony regarding the specificity of the disclosure made, the alleged inadequacy of the disclosure, whether additional information concerning the item was available, and the prejudice claimed by IBM with respect to its ability to prepare a defense.

39

Instead, the Magistrate Judge discussed (at 36-38) a few categories of disclosed items. For eleven items, the "court agrees that they were disclosed with sufficient specificity to survive the current motion." (Order at 36.) For the others, SCO is left with nothing more than the court's assurance that it has individually reviewed all of the disputed items and that, without any specific reasons being given, "SCO failed to support its alleged misappropriated items with the specificity required by the court's orders."

This process and decision constitutes clear error. First, the Order fails to comply with the legal requirement of particularized findings to support a severe sanction order of this type. Second, the Order's general determination that SCO's other disclosures "failed to meet the level of specificity required by the Court's Orders" cannot be squared with the record regarding those items.

A. The Failure to Provide Particularized Findings
In considering a motion for sanctions, a court must evaluate and make findings with respect to each instance in which the non-moving party has allegedly failed to comply with the court order at issue. Here, there must be "detailed" and "specific" findings regarding the court's reasons for excluding each of the disclosures. Haugen see also Robson, 81 F.3d at 3 (vacating the district court's imposition of sanctions for several alleged instances of failure to comply with a court order and remanding where "factual disputes exist over the extent of the misconduct, including excuses offered as to each of the episodes, that have never been resolved by the district court" and "there are no findings to resolve the matter"). Where "the district court has not expressed any view on the matter that would permit us to provide effective review," the appellate court must vacate and remand for appropriate, specific fact-findings as to each alleged instance of non-compliance with the court order at issue. Robson, 81 F.3d at

40

5. No less should be required in a determination by a federal magistrate judge. In failing to address the individual scope and nature of each of the disclosures (and instead only concluding without explanation that many of the disclosures lacked sufficient specificity), the Magistrate Judge thus committed clear error. SCO assumes that the Magistrate Judge's decision to exclude disclosures was not "off the cuff," Haugen, 427 F.3d at 742, but the fact is that the record precludes SCO and this Court from evaluating the decision on any reasoned basis.

B. The Failure to Consider the Adequacy of Disclosures on an Item-by-
Item Basis
The failure to have particularized findings is magnified in light of the record of the detailed information provided by SCO on items that were struck. The Magistrate Judge compared SCO's disclosures to a shoplifter being told by an officer simply that "you know what you stole I'm not telling" or being given a catalog of Neiman Marcus' entire inventory and saying "its in there somewhere, you figure it out." (Order at 34.) With all due respect, these analogies are so far afield from the actual detail provided in SCO's disclosures that they indicate all the more reason that a particularized item-by- item consideration, and an evidentiary hearing, should have been held.

In the briefing, SCO and Mr. Rochkind in his declaration specifically addressed the one item that Professor Davis discussed in his initial Declaration ("differential profiling" in Item No. 146, Exh. 1), pointing out that while specific code was written to illustrate the method disclosed by IBM Dynix developer Paul McKenney, it was located on a server accessible to IBM, but not to SCO. This was not refuted by IBM but then was not addressed by the Magistrate Judge. Nor did the Magistrate Judge address the examples of specific identification discussed by SCO at argument. Item No.

41

53 concerned the disclosure of the method used in Dynix to handle semaphores (which are used in "locking" to restrict access to shared resources in a multiprocessing environment). (See. Hr. Tr. at 53-54, Exh. 14). IBM developer Tim Wright expressly told non-IBM Linux developers about locking techniques "that are not currently used in Linux," then stated "the classic coding style in Dynix/ptx is...," followed by specific source code. SCO also identified Linux files relating to this method and concept. Moreover, Mr. Wright, at his deposition (Wright (11/05/05) Dep. Tr. 153:15-154:10, Exh. 15) admits

REDACTED

IBM has never said one word about Item 53, yet without any discussion or findings, it is struck from SCO's case by the Order.11 Item 38, discussed at argument, involved the disclosure of a method and concept that goes back to UNIX System V relating to an automatic method of checking for updates in memory. (See Hr. Tr. at 54-55, Exh. 14). An IBM employee, William Irwin, made this disclosure and the Minutes from the February 21, 2003 teleconference during which the disclosure was made are referenced, as are the specific Linux files involved. Without discussion or findings, this item has been struck for lack of specificity. The same was true of other items where the specificity of the disclosure was presented at Argument (see Item Nos. 32 (Tab 22) and 23, discussed at Hr.Tr. at 55). These examples were presented to the Court not as an exhaustive listing, but to demonstrate the need for an item-by-item consideration, and an evidentiary hearing, before SCO's claims were struck for lack of specificity.

42

The following and others listed in Appendix C are additional examples of the items that the Magistrare Judge has struck from SCO's case, without specific discussion, let alone testimony. The examples show that the existiing identification is adequate, that more precise identifying information was unavailable, that such informaton was at least as available if not more readily available to IBM, and that IBM was not unduly prejudiced in preparing a defense.

One major area of method and concept disclosure by IBM was "locking". Item Nos. 279 and 280 demonstrate methods IBM developer Rick Lindsley contributed to improving Linux in the technology area of locking after he had been exposed to Dynix/ptx locking techniques. (Attached as Exhs. 16 and 17, respectively.) Like Item Nos. 186-192, which the Order found were sufficient, Item Nos. 279 and 280 are supported by deposition testimony admissions from Lindsley himself (Exhs. 18 and 19.) Lindsley admitted:

REDACTED

(Lindsley Dep. (12/1/05), 100:20-24; 20-204:4, Exh. 19);

REDACTED

(Lindsley Dep. (12/1/05) 222:133-13, Exh. 18). In addition to the deposition testimony, Item Nos. 279 and 280 (Exhs. 16 and 17) contain significant specificity identifying the material misused by IBM, including the source code patches contributed by IBM to Linux that consist of hundreds of lines of source code identified by file, version and line. (Attached as Exhs. 20-23). Item Nos. 279-280 were struck without any specific discussion by IBM and without findings. Another example, Item No. 46 (Exh. 24), is a February 26, 2003 email

43

exchange between IBM developers Martin Bligh, James Cleverdon and a public Linux mailing list in which Bligh and Cleverdon describe a "bug fix" Bligh made to Linux and how it was based on the method from Dynix/ptx.12 In the December Submission, SCO actually cited the files and lines where this occurs in Linux. 13 Subsequently, during Bligh's deposition on January 16, 2006, he admitted:

REDACTED

REDACTED

(Bligh (1/16/06) Depo. Tr. 73:22-75:17, Exh. 26). Moreover, these same lines of Linux source were included in the patch Bligh disclosed to Linux, which SCO included as December Submission Item 236 (Exh. 27). Nonetheless, IBM, without any showing that it did not know and could not ask its own employee, Bligh, what he was talking about -- indeed, without any specific discussion at all of these Items -- IBM has achieved their removal from SCO's case.

The above examples (and additional Items described in Appendix C) are illustrative of information that would properly be considered at a hearing focused on the adequacy of item-by-item disclosures whether additiona1 information not disclosed was in SCO's possession, whether IBM had ready access to additional information if available because it employed the individuals making these disclosures, and whether and to what extent IBM experienced any prejudice in defending. If the arguments above,

44

given the lack of proof of willful noncompliance, were not in themselves sufficient to warrant denial of IBM's motion, the correct and necessary course is to have an item-by- item hearing, allowing as well for testimony on these points, followed by specific findings.

The Magistrate Judge also, without discussion in the Order, rejected SCO's express invitation to await the upcoming filing of expert reports, which would aid in understanding the disclosures. SCO's expert reports were submitted in May, including specifically the report of Marc Rochkind, the report of Dr. Evan Ivie, a former professor of computer science at Brigham Young University and UNIX expert, who also opined the IBM disclosed substantial protected technology.14

Given the technological complexity of these issues, it would also be appropriate for a technology expert (not affiliated with any party or side of this dispute) to be retained as an expert to the court, or appointed as a special master for the purpose of reporting on these technical issues. A generalized conclusion that SCO simply told IBM like the hypothetical shoplifter at Neiman Marcus referenced by the Magistrate Judge to figure out itself what was taken is simply incorrect, and cannot substitute for the type of particularized consideration and findings that must precede a decision to limit SCO's case.

VII. THE MAGISTRATE JUDGE CLEARLY ERRED IN FAILING TO
REQUIRE IBM TO ESTABLISH PREJUDICE AND TO CONSIDER
ALTERNATIVES TO THE SANCTION IMPOSED.

Following a determination that a clear order of the court has been violated, that the violation has been willful, and the making of specific findings regarding the

45

insufficiency of the information provided (none of which is present here), it is still incumbent upon the Court to consider additional factors before entering a severe sanction effectively dismissing a large part of SCO's breach of contract claim.

A. The Magistrate Judge Did Not Properly Consider the Issue of
Supposed Prejudice Arising from SCO's Failure to Provide Source
Code Identifiers for Each Item of Misused Material.
This Court must consider the extent of any "prejudice" to IBM. Haugen, 427 F.3d at 740-41. That consideration must include whether the material at issue was available to the moving party and whether the moving party took steps to obtain that material. In Searock v. Stripling, 736 F.2d 650 (11th Cir. 1984), for example, the court of appeals reversed sanctions imposed by the district court on the ground that the district court had abused its discretion in sanctioning the defendant, Stripling, for failing to produce certain materials to the plaintiff, Allied Marine. The court noted that:
although the district court found that these documents were essential to Allied Marine's defense of counterclaim, the record in this case does not reflect that Allied Marine took any action to attempt to secure these crucial documents itself. Clearly, Allied Marine had the ability to subpoena these documents by taking the deposition of the custodians of the records of the companies concerned; however, the record does not reflect any such attempt by Allied Marine. Since Allied Marine also could have obtained the required documents if they were then in existence and failed to attempt to do so, it does not appear that Allied Marine's preparation for trial was substantially prejudiced by Stripling's failure to obtain and produce them.
Id. at 654. This reasoning directly applies here, because IBM has made no assertion that it asked any of its own programmers who made the disclosures at issue (1) what Unix, Dynix, or AIX code they had in mind when they made the disclosure of the method or concept, or (2) the source-code coordinates of any version of Linux in which the disclosed method or concept might have been embodied.

46

In the June 28 Order, the Magistrate Judge, in effect, decided that whether IBM's conduct breached its contracts with SCO could be resolved even before summary judgment. SCO does not and need not assert that it "owned" the methods and concepts; the non-disclosure restrictions on IBM were independent of any question of ownership. See generally SCO's Mem. in Opp. to IBM's Motion for Summary Judgment on SCO's Breach-of-Contract Claims (Nov. 30, 2004). The Magistrate Judge thus compounded the error in the improper interpretation of the July 2005 Order through a misplaced summary- judgment-like, and thus dispositive, assessment of disclosures in SCO's December Submission. Assessing a presentation given by Richard Moore of IBM's Linux Technology Center in June 2005, the Magistrate Judge stated (at 35):

While it discusses Kernel patches, thread locks and NUMA there is nothing that links these back to being originally owned by SCO. And even with a related "smoking gun" email there is once again little connection back to what is allegedly owned by SCO. This simply is not enough specificity under the court's orders.
This analysis and conclusion is in clear error. SCO need not show that it "owned" the material disclosed, only that restrictions in the license agreements govern those methods and concepts which it has done.

The Magistrate Judge engaged in no particularized consideration on an item-by- item basis of how IBM was prejudiced in the absence of source code coordinates where IBM's own programmers did not feel they were needed to convey the method or concept. The Magistrate Judge did not address the issue except by hypothetical examples of where she believed such information would be important.

First, the Magistrate Judge stated: "Is the code that comprised the method or concept still in use in Linux? If not, then damages may become nominal instead of in the

47

billions." (Order at 34.) There was nothing in the record to support such speculation. It will be SCO's obligation to prove damages at trial. SCO has identified the file locations in Linux where its experts believe the particular method or concept either had an impact or may have an impact in the future (injunctive relief is also requested in this case). There is no showing that SCO has but is not telling what particular lines of code in those files are impacted. Nor is there anything in the record which establishes that IBM cannot work with the file level information as to Linux in evaluating, as will SCO's experts, whether the disclosure of a method or concept, or negative knowhow (so as to avoid a blind alley) contributed to Linux.

Second, the Magistrate Judge stated that "it may be possible that the code comprising a method or concept was already disclosed pursuant to some other license such as the BSD license." (Order at 34.) This, too, is pure speculation, unsupported by any record of prejudice, let along tied to particular technology items. Dynix, the principal breeding ground for the methods and concepts at issue, is a UNIX System V derivative developed at Sequent. There is nothing in the record to suggest that Dynix source code has been released into the public, under a BSD license or otherwise. Nor is there anything in this record that establishes IBM could not investigate whether the method and concept was publicly known by looking for the method and concept itself in articles, books, and other texts.

Although a court may preclude either party from "sandbagging" the other by declining to produce evidence during discovery and then later seeking to use it, where there is no evidence of such activity, sanctions are inappropriate. See, e.g., Schanzer v. United Techs. Corp., 120 F. Supp. 2d 200, 206 (D. Conn. 2000) (finding that Rule 37

48

does not apply where the facts are "not a case of `sandbagging' an adversary at trial with newly disclosed evidence"); Vandervest v. Wisconsin Cent., Ltd., 172 F.R.D. 401, 402- 03 (E.D. Wis. 1997) (declining to impose sanctions for alleged failure to provide certain discovery under Rule 26 where the plaintiffs' counsel sought but did not have the information requested, and therefore "the plaintiffs did not improperly withhold discoverable information"); cf. Tracinda Corp. v. DaimlerChrysler AG, 362 F. Supp. 2d 487, 506-07 (D. Del. 2005) (declining to exclude proposed expert testimony that was not materially different from the expert's earlier report). That is equally true with respect to an alleged violation of a court order or an alleged failure to respond to interrogatories. As one court has said of Rules 26 and 37, the "purpose of these rules is to avoid `surprise' or `trial by ambush.'" American Stock Exch., LLC v. Mopex, Inc., 215 F.R.D. at 93 (citing cases).

Indeed, even where (unlike here) the prospect of surprise is presented, courts have emphasized that the "drastic sanction of preclusion should only be used in cases where the late disclosure occurs at the `eleventh hour' on the eve of trial." S&S Communications v. Local Exh. Carriers Ass'n, No. Civ. 02-1028, 2005 WL 2897045, at *4 (D.S.D. Nov. 3, 2005). (Attached hereto as Exh. D, Decl. of Mark James). In basing her Order on the mistaken proposition that SCO possesses evidence that it simply declined to produce, the Magistrate Judge committed clear error. See, e.g., Guinyard v. City of New York, 800 F. Supp. 1083, 1086 (E.D.N.Y. 1992) (denying defendants' motion to sanction plaintiffs for allegedly inadequate interrogatory responses, as ordered by the court, where those responses "set forth plaintiffs' theory and evidence to support it").

49

In short, the Magistrate Judge's hypothetical instances of prejudice do not substitute for a particularized determination of actual prejudice, especially given that the methods and concepts at issue are identified by IBM's own employees as coming from derivative products subject to SCO's licensing rights.15

B. The Court Failed to Consider IBM's Own Responsibility for the Lack of Complete Source Code Identification.
Even after the Court ordered the source code to be produced, IBM failed to produce all versions of its AIX code, claiming that they cannot be located. Even more egregious was IBM's spoliation of evidence. Weeks after SCO filed its lawsuit, IBM directed "dozens" of its Linux developers within its LTC and at least ten of its Linux developers outside the LOC to delete the AIX and/or Dynix source code from their computers. (SCO Opp. Memo. (3/7/06) at 3.) One IBM Linux developer has admitted to destroying Dynix source code and tests, as well as pre-March 2003 drafts of source code he had written for Linux while referring to Dynix code on his computer. (Id. at 3-4.)

50

Clearly, any effort to link up methods and concepts with specific source code from Dynix or AIX would have been assisted by the information that was intentionally discarded by IBM after the filing of the suit. At argument, however, the Magistrate Judge believed that this issue was irrelevant to the matter before the court, and did not address it in the Order. SCO intends to raise the issue of IBM's spoliation of evidence before this Court at the appropriate time. However, in light of IBM's present Motion, the issue of IBM's spoliation of evidence has become immediately relevant and the Magistrate Judge should have considered it in assessing responsibility for the problem if, as the judge concluded, SCO was obligated to identify source code coordinates for all method and concept disclosures.

C. The Magistrate Judge Clearly Erred in Failing to Consider Whether
SCO Had Been Warned That Its Claims Were In Jeopardy.

An additional factor required to be considered under Tenth Circuit authority is whether a party had been warned by the court that it faced dismissal or striking of claims. A court can impose a sanction as serious as the exclusion of claims only where the sanctioned party has previously been given notice that sanctions will follow from a failure to comply with the court order at issue. See Haugen, 427 F.3d at 741; see also Ortiz-Anglada v. Ortiz-Perez, 183 F.3d 65, 67 & n. 4 (1st Cir. 1999) (reversing district court's imposition of sanctions, in the form of dismissal, where district court had failed to give plaintiff any reason to suspect that her case was at risk); Avionic Co. v. Gen. Dynamics Corp., 957 F.2d 555, 558 (8th Cir. 1992) (requiring a prior order so as to "give the party failing to comply with discovery adequate notice of what is required and an opportunity to contest the discovery sought prior to the imposition of sanctions").

51

Here, there is no consideration at all in the Order of the fact that SCO had never been warned that it faced limitation of claims. There had been no prior sanction order against SCO in this case. Indeed, the Magistrate Judge had previously found, in March 2004, that SCO had acted "in good faith" in its efforts to provide information to IBM's requests. This process was the first consideration of the adequacy of SCO's submissions in response to this Court's July 2005 Order -- and yet the Magistrate Judge jumped immediately to striking SCO's claims on the challenged items.

D. The Magistrate Clearly Erred in Failing to Consider Alternatives to
Limiting SCO's Claims.
The record shows no consideration of any alternatives to the sanction imposed. SCO, for example, repeatedly pointed out at argument that the remedy for a belief that one party is sandbagging the other is for a party to object at the time the evidence not previously produced is sought to be used. SCO objects to the Magistrate Judge's statement that it "is almost like SCO sought to hide its case until the ninth inning" to gain some tactical surprise. But if SCO seeks to rely on misused technology disclosures not identified in the December Submission, the appropriate remedy would be not to allow such new disclosures to be introduced at time of trial. Indeed, orders restricting the introduction of evidence not properly disclosed in discovery are the usual and more appropriate remedy for deficiencies in interrogatories or other discovery. See Rogers, 357 U.S. at 212-213; Dorsey v. Academy Moving & Storage, Inc., 423 F.2d 858, 860-861 (5th Cir. 1970); see also 4A Moore, Federal Practice, P 37.03(2.-3) (2d ed. rev. 1976).

A second alternative, to the extent the Court is convinced that certain of the information at issue is within SCO's ability to feasibly provide which is a necessary predicate to the sanction ordered here would be to order the providing of more

52

complete source code information and extending IBM's time for discovery. Given this Motion has occasioned the first consideration of the specificity required for method and concept disclosures, and the first examination of the adequacy of the voluminous December Submission by SCO, this is far more equitable than the preemptory limiting of claims by the Magistrate Judge's Order.

A third alternative would be to deny the IBM Motion without prejudice to IBM seeking, after expert discovery has been completed, to exclude specific items of technoloty on the grounds that the disclosures for those items are not specific enough to permit a defense. Then, the Court could consider, potentially with the aid of an independent expert appointed by the court, such technology disputes in the context of a complete record including expert reports and expert depositions.

Because the Magistrate Judge failed to consider any such alternatives, or others, its Order cannot stand.

VII. CONCLUSION

For the reasons stated above, the Order Granting In Part IBM's Motion to Limit SCO's Claims should be reversed.

DATED this 13th day of July, 2006.

HATCH, JAMES & DODGE, P.C.
Brent O. Hatch
Mark F. James

BOIES, SCHILLER & FLEXNER LLP
Robert Silver
Stuart H. Singer
Stephen N. Zack
Edward Normand

By: ____[signature]___________
Counsel for The SCO Group, Inc.


1 Although the Magistrate Judge suggested that SCO changed its claims from code to methods and concepts, SCO's claims have been based in part on IBM's misuse of methods and concepts from the inception of this case. In SCO's original complaint, SCO alleged that the redesign of Linux would not have been possible at the enterprise level without "access to UNIX code, methods and concepts." (Complaint at ¶ 84) (emphasis added). SCO further alleged that IBM's contributions to Linux included "unauthorized misuse of UNIX methods, concepts, and know- how." (Id. at ¶ 96) (emphasis added). SCO also made allegations regarding IBM's misuse of methods in its now operative complaint, the Second Amended Complaint.

2 For some reason the Magistrate Judge skipped over SCO's allegation that IBM has violated SCO's contracts in setting up the background for her ruling and focused on the copyright allegations even though the two are different. Order at p. 3. It appears from the ruling that the Magistrate Judge applied a copyright analysis to all of SCO's 293 disclosures which appears to be inconsistent with a prior order. In the Magistrate Judge's January 18, 2005 Order (at 7-8), she recognized: "From the foregoing, it is clear that the contracts and their interpretations are central to the disputes in this case. In fact, the contract claims may have a more important role in the outcome of this case than the copyright claims. Other courts have determined that "contractual alternatives to copyright may give an owner of computer software more protection than copyright would."

3 All exhibits to SCO's Objections to Order Granting in Part IBM's Motion to Limit SCO's Claims are attached to the Declaration of Mark James and will be henceforth referred to simply by the "Exh. No."

4 Mr. Rochkind is the author of "Advanced UNIX Programming," Addison-Wesley, 1985 (First Edition) and 2004 (Second Edition).

5 Judge Well's Order exceeded the authority under the Order of Reference (Docket 35) under 28 U.S.C. § 636(b)(1)(A). Under the Order of Reference, the Magistrate was authorized to hear and determine only "nondispositive pretrial matters." The District Judge did not give the Magistrate Judge a reference under 28 U.S.C. § 636(b)(1)(B) to hear dispositive matters. Thus, the Order should be taken as a Report and Recommendation which the District Court is obligated to review de novo. In any event, SCO respectfully submits, as explained below, that the Order would also fail under a "clearly erroneous or contrary to law" standard under Fed. R. Civ. P. 72(a), for review of non-dispositive orders.

6 Interrogatory No. 12 requested:

Please identify, with specificity (by file and line of code), (a) all source code and other material in Linux (including but not limited to the Linux kernel, any Linux operating system and any Linux distribution) to which plaintiff has rights; and (b) the nature of plaintiff's rights, including but not limited to whether and how the code or other material derives from UNIX.
Interrogatory No. 13 requested:
For each line of code and other material identified in response to Interrogatory No. 12, please state whether (a) IBM has infringed plaintiff's rights, and for any rights IBM is alleged to have infringed, describe in detail how IBM is alleged to have infringed plaintiff's rights; and (b) whether plaintiff has ever distributed the code or other material or otherwise made it available to the public, as part of a Linux distribution or otherwise

....

(Exh. 4).

7 The Magistrate Judge appeared to reason that SCO could have moved to clarify the precise meaning of this Court's July 2005 Order, but she does not cite any precedent suggesting that SCO's failure to file such a motion supports any imposition of sanctions. To the contrary, see, e.g., Williams v. Sprint/United Mgmt. Co., 230 F.R.D. 640, 656 (D. Kan. 2005) (declining to impose sanctions where there was an "arguable ambiguity in the Court's prior rulings," see also Unicure, Inc. v. Thurman, 97 F.R.D. 7 (W.D.N.Y. 1982) (refusing to impose sanction of dismissal where the discovery order was "somewhat ambiguous").

8 The only other discovery request in which SCO's definition of "identify" (in relation to "methods") is implicated in SCO's Third Set of Interrogatories (Exh. 12), directed at IBM's patent counterclaims. IBM subsequently dropped its patent claims, which in any event were entirely different than SCO's breach of contract claims, and subject to different types of proof. As such, the discovery appropriate on a patent claim was entirely different than the discovery appropriate on the breach of contract claim.

9 Thus, to fall back on the Magistrate Judge's Neiman Marcus example, SCO's allegations of IBM's improper disclosure begin with IBM's admissions of its own guilt. Yet in the face of IBM's admissions of guilt, the magistrate judge would ask SCO to not only show the evidence of theft (which it has done) but to entirely recreate the crime scene. As it stands, the Magistrate Judge's Order creates the remarkable result that the fact-finder should not even be permitted to see IBM's admissions of its own contributions of confidential methods and concepts.

10 Rochkind's declaration also makes clear that while versions of Linux are not expressly indicated in the December Submission, "the files referenced can be found, in most cases, in any version of Linux issued after the disclosure." (Rochkind Decl. at 5 n.2, Exh. 2).

11 These materials, all found in SCO's December Submission and presented to the Magistrate Judge at argument, as well as a number of other examples, are attached as Appendix B hereto.

12"James Cleverdon ... he was involved in this with PTX, and gave me some pointers to hair-restorer during the Linux timeframe... the four writes to ESR is still enshrined in Dynix/PTX's APIC error handler, and will remain a hidden testimony to this bug for as long as IBM maintains PTX support."(Attached as Exh. 25).

13 "[A]arch/i386/kernel/apic.c,line 331-336" and "arch/x86_64/kernel/apic.c, line 284-289." (Attached as Exh. 24). The lines of code are the following:

/* Pound the ESR really hard over the head with a big hammer-mbligh*/ 
If (esr-disable) { 
apic-write (APIC-ESR, 0); . 
apic-write (APIC-ESR, 0); 
apic-write (APIC-ESR, 0); 
apic-write (APIC-ESR, 0); 

14 These reports are on file in connection with yet another IBM motion, one to exclude certain items from SCO's Expert Reports.

15 IBM's developers made these methods and concepts disclosures without disclosing related source code and they knew that such method and concept disclosures were extremely valuable to the Linux development community. In fact, IBM has publicly boasted that their AIX and Dynix developers have contributed expertise and ideas that have improved Linux. IBM claims that 80% of its contributions are actually accepted into Linux. See Exh. 28. For example, in a Computerworld interview, IBM executive Steve Mills answered this question, "To what degree is IBM involved in the development of the Linux kernel?" by answering:, "We have our Linux Technology Center, and we have a team of people that are involved with the Linux community on Linux development and have ... since `98 or `99. We don't have any people that are literally part of the core team. We play an influencer role in terms of what we work on, suggestions that we make, code samples that we offer up. We're trying to encourage a particular set of improvements to Linux. Obviously, our interest tend to relate to things that our large corporate customers are most interested in. They worry about robustness, scalability, fail-over, so that's a direction that we have an interest in. We've had very good success in having ideas that we've been working on become accepted by the community and incorporated into the kernel." (Exh. 29). In another example, during an interview with Linux Magazine about the state of the Linux kernel in 2001, IBM programmer Patricia Gaughen stated that Linux was "not where the proprietary Unixe[s] are yet, but we are making much faster progress due to the experienced Dynix/IRIX/AIX/SN1/Yalnix/ hackers." (Exh. 30). After claiming that its disclosures from AIX and Dynix/ptx improved Linux, IBM cannot argue that specific identification of the same disclosures is insufficient.

53

CERTIFICATE OF SERVICE

Plaintiff, The SCO Group, Inc., hereby certifies that a true and correct copy of the foregoing Objections to Order Granting In Part IBM's Motion to Limit SCO's Claims was served on Defendant International Business Machines Corporation on the 13th day of July, 2006, by U.S. Mail, first class postage prepaid, to the following:

David Marriott, Esq.
Cravath, Swaine & Moore LLP
[address]

Donald J. Rosenberg, Esq.
[address]

Todd Shaughnessy, Esq.
Snell & Wilmer LLP
[address]

__[signature]___

54


  


SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text | 653 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections here
Authored by: feldegast on Tuesday, July 18 2006 @ 07:54 AM EDT
So they can be found

---
IANAL
The above post is (C)Copyright 2006 and released under the Creative Commons
License Attribution-Noncommercial 2.0
P.J. has permission for commercial use

[ Reply to This | # ]

Off Topic
Authored by: feldegast on Tuesday, July 18 2006 @ 07:55 AM EDT
To make links clickable, post as HTML

---
IANAL
The above post is (C)Copyright 2006 and released under the Creative Commons
License Attribution-Noncommercial 2.0
P.J. has permission for commercial use

[ Reply to This | # ]

Maybe it is now time to write directly to ignorant jurors.
Authored by: entre on Tuesday, July 18 2006 @ 08:20 AM EDT
PJ's content is overwhelming to SCO and clear to Groklaw readers but is it time
now to write also to the ones whom may matter in the end, if it goes that far?
This article is just great but can Joe average juror comprehend the content to
render an informed decision. Just a thought...

[ Reply to This | # ]

The Nazgul are going to tear this apart...
Authored by: sirwired on Tuesday, July 18 2006 @ 08:21 AM EDT
I haven't finished reading the whole thing, but nowhere do I see SCO address the
fact that the disclosed methods and concepts ARE IMPLEMENTED IN CODE. SCO
pounds on how the the contract claims are different from the copyright claims,
brings up "good faith" again, etc. They neglect to counter (from what
I have read so far) that for a method and concept to be improperly disclosed, it
has to be implemented in UNIX to begin with, and the place to find that method
or concept is... drum roll please... the UNIX source code!

SirWired

[ Reply to This | # ]

SLOOOOOWLY they turned
Authored by: overshoot on Tuesday, July 18 2006 @ 08:22 AM EDT
Well, SCOX is getting closer and closer to admitting that their whole case is about IBM contributing "methods and concepts" that IBM invented to Linux. Sort of.

Of course they still haven't outright said that. However, they're getting closer (pages 15-20). They admit that they can't trace the "methods and concepts" back to SysV, but insist that they don't need to.

I can see why they didn't want to spell that out at the beginning of the case. IBM, back in the day, was concerned that the contract not limit their own use of their own code, but even they weren't paranoid enough to believe that AT&T would argue that IBM couldn't develop whole new technologies and then be forced to choose between

  • Using them in AIX
  • Presenting them in research papers, patent applications, etc.

However, that's what this is coming down to.

I'm pretty sure that Judge Wells has figured out that the whole show over discovery was a total sham now. IBM offered early in the case to stipulate that they had contributed code etc. from AIX to Linux to speed matters up; instead we got the last two years. Her Honor knows she's been used, and I'm reading her Order as taking SCOX at their word the last two years. If their current story is to be believed, they didn't need all that discovery in the first place -- so, on the presumption of good faith, she's acting as though they really did need all that "critical predicate discovery."

The real fun is going to be whether Judge Kimball similarly plays dense and ignores SCOX' not-quite-stated theory.

[ Reply to This | # ]

SCO's Redacted Objections to Wells' Order & Appendix
Authored by: Steve Martin on Tuesday, July 18 2006 @ 08:24 AM EDT

This Court’s Order of July 1, 2005 set forth new deadlines for completion of discovery, for exchange of expert reports, for filing of dispositive motions, for completion of pre-trial stipulations and witness and exhibit lists, and, ultimately, for a five-week jury trial set to begin on February 26, 2007. At IBM’s request, the Court also included deadlines for the parties to “identify” all allegedly “misused material” with “specificity,” and to update interrogatory answers. The interim deadline for this identification was October 28, 2005, and the final deadline was December 22, 2005. This Court declined to adopt IBM’s proposed language for that deadline, which stated that line, version, and file of source code must be provided. The fact that this Court declined to adopt IBM’s proposed language for that Order should be enough to overturn the June 28 Order.

Oh, Goody! Not only has BS&F tried to tell Judge Wells what her own Orders actually meant, now they're trying that same stunt with Judge Kimball. Somebody pass me the popcorn.

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

[ Reply to This | # ]

No willful infringement?
Authored by: Anonymous on Tuesday, July 18 2006 @ 08:25 AM EDT
From page 8: "SCO simply cannot be sanctioned when it is providing all of
the information that it has. A willful violation occurs when a party decides not
to produce documents or other information within its possession"

Do they really mean "you can't sanction us because we don't in fact HAVE
any real evidence to our court case, therefore it's not our fault that we can't
provide this evidence"??

Maybe they are right then; however if they admit this, the case is over?

[ Reply to This | # ]

They sooo want to get in front of a Jury ...
Authored by: mickkelly on Tuesday, July 18 2006 @ 08:32 AM EDT
... with as many items as possible. Quality does not matter to them, only quantity. BSF thinks they can create the appearance of quality (concerning the items in the disclosed misused materials list) by their court magick.

Concider:

"Those statements [a.k.a ramblings by Darl et al.] do not mean that SCO possessed such evidence regarding the 198 methods at issue in IBM’s motion, and the Magistrate Judge made no effort whatsoever to link any statement to any Item."
([stuff in brackets] added by me)

Do they really think that they can weasel their way out? Everybody following the case knows perfectly well that they publically claimed to have mountains of specific evidence, specific source-code examples; now they are just hiding it? it's not relevant any more?

---
- may you ever drink deep -

[ Reply to This | # ]

Clever weasle-wording
Authored by: Jude on Tuesday, July 18 2006 @ 08:35 AM EDT
II. BACKGROUND
A. The Nature of SCO’s Contract and Copyright Claims
SCO brings claims for both breach of contract and copyright infringement.
SCO’s contract claims are based upon the license agreements signed by AT&T, SCO’s
predecessor in interest, with both IBM and Sequent (which IBM later acquired). These
agreements allowed for UNIX source code, methods, and concepts to be used by IBM
and Sequent in the development of their own UNIX operating systems but made the
source code and methods and concepts in such “derivative” or “modified” systems
subject to nondisclosure requirements.

Methinks SCO is trying to sneak in the legal conclusion that ALL methods and concepts
used in AIX or Dynix were subject to nondisclosure, including methods and concepts that
were never in the original Unix code (IE, methods and concepts created by Sequent or IBM).

[ Reply to This | # ]

Code vs. Disclosure
Authored by: Anonymous on Tuesday, July 18 2006 @ 08:40 AM EDT
With all the cries of "show us the code", I have to admit I find SCO's
basic argument reasonable: Where they claim a breach of a contractual
obligation not to disclose, surely demonstrating disclosure is sufficient.
Whether the disclosed information was used or ignored in Linux would presumably
affect the determination of damages, but the truth of the allegation doesn't
logically depend on their being Linux code to point at.

[ Reply to This | # ]

SCO's Redacted Objections to Wells' Order & Appendix
Authored by: tredman on Tuesday, July 18 2006 @ 08:50 AM EDT
I've only had a chance to skim the document, but it seems to me that it's simply
a rehashing of arguments they made in the hearing on this very motion. No doubt
them going almost as far as to call Judge Wells inept will endear them to this
court; particularly if Judge Kimball upholds the findings, since he's made it
clear in the past that he's not entirely convinced by their arguments to begin
with.

PJ, you were most certainly right, Appendix A is a hoot. Actually, I'm not sure
what purpose it serves. Most of the items they're actually admitting to, and
the ones that they're denying are on the basis of some real linguistic
finagling. I particularly enjoy the comment about the MIT deep divers. If
that's not mincing words, I don't know what is.

Oh, and I don't have the greatest memory in the world, but referring to Appendix
A, could somebody point out to me where in their original complaint SCO ever
used the term "Carrier Grade Linux", or as we've discussed before,
where in their original complaint the STREAMS API ever shows up? Can somebody
show me where, for that matter, STREAMS has ever appeared in a vanilla kernel,
or even a kernel distributed by IBM (hint hint we know now it came from a little
company in Utah called Caldera). Unless it's from redacted material, I don't
remember it. BSF, on the other hand, mentions it as if it's been the crux of
their argument from day one.

The more the story changes, the more it stays the same.

---
Tim
"I drank what?" - Socrates, 399 BCE

[ Reply to This | # ]

SCO accuses magistrate judge about something she didn't say
Authored by: JR on Tuesday, July 18 2006 @ 08:58 AM EDT
SCO says in pages 18 and 19 of 60 (numbered differently in the PDF file):
    'What the Order characterized as the “most important” factor in the Magistrate Judge’s finding that SCO knew it had to provide source code coordinates for all items – and could do so – was how SCO had defined “identify” in a discovery request served at the outset of the case.'
Then they say in page 20 of 60:
    'Willful failure is “any intentional failure as distinguished from involuntary noncompliance.” Id. at 872-73.'
SCO characterizes their failure as "involuntary noncompliance".

As I understood the judge's order when I read it, she said that SCO submitted the items even though it knew it didn't have the information and it knew that it HAD to submit the complete file/version/line information. If SCO knew that it should NOT include any claims that are not fundamented in specific information, it should have NOT submitted them; to me then, this was a WILLFUL act.

If I know that the stove is hot, and I know that I get burned if I touch a hot stove, then when I touch it (nobody forcing me) and get burned, I cannot claim that I didn't know.

So, SCO knew the rules and decided to overlook them, this was a willful act, no question about it.

[ Reply to This | # ]

Chockfull of howlers
Authored by: _Arthur on Tuesday, July 18 2006 @ 09:12 AM EDT
And you can quote me.

[ Reply to This | # ]

SCO's Redacted Objections to Wells' Order & Appendix
Authored by: Anonymous on Tuesday, July 18 2006 @ 09:24 AM EDT
And what do libraries in a RH distro have to do with suing IBM?

[ Reply to This | # ]

Does Judge Wells lack authority
Authored by: Chris Lingard on Tuesday, July 18 2006 @ 09:27 AM EDT

SCO are blaming Judge Wells for their lack of proof, instead they hope for a Perry Mason moment in court. But I am sure that the below paragraph is wrong. About 2 years ago Judge Kimball gave authority to Judge Wells for this case

Page 14, subnote 5:

Judge Well's Order exceeded the authority under the Order of Reference (Docket 35) under 28 U.S.C. § 636(b)(1)(A). Under the Order of Reference, the Magistrate was authorized to hear and determine only "nondispositive pretrial matters." The District Judge did not give the Magistrate Judge a reference under 28 U.S.C. § 636(b)(1)(B) to hear dispositive matters. Thus, the Order should be taken as a Report and Recommendation which the District Court is obligated to review de novo. In any event, SCO respectfully submits, as explained below, that the Order would also fail under a "clearly erroneous or contrary to law" standard under Fed. R. Civ. P. 72(a), for review of non-dispositive orders.

[ Reply to This | # ]

SCO's Redacted Objections to Wells' Order & Appendix
Authored by: Anonymous on Tuesday, July 18 2006 @ 09:29 AM EDT
I have to disagree with you, PJ, about item 2. The quote in the PDF says 'Unix
System V source code and Red Hat [Linux]', so presumably, the Linux is an
editorial addition, and not part of the original statement. So, in at least this
one instance, Sontag did not use the word 'kernel,' nor should this be read as
limited to the kernel.

It may be reasonable to limit a reference to X existing in Linux as a reference
to the kernel, since technically speaking, Linux is only a kernel.

'Red Hat Linux,' on the other hand, is a reference to a distribution, a complete
OS, including kernel, supporting libraries, and applications, some elements of
which are Red Hat's development, and others that are mere aggregation.

As an additional confirmation that the Linux kernel was not mentioned and then
tweaked by the lawyers in the quote, I went into the quote db and dug up this
quote.

****

We are using objective third parties to do comparisons of our UNIX System V
source code and Red Hat as an example. We are coming across many instances where
our proprietary software has simply been copied and pasted or changed in order
to hide the origin of our System V code in Red Hat. This is the kind of thing
that we will need to address with many Linux distribution companies at some
point.-- Chris Sontag, 2003-04-28

****

In this text the 'Linux' after Red Hat is not present, and the only 'Linux'
present is paired with 'distribution companies'. So in this one case, it is
actually reasonable to grant the wider scope of kernel+libraries or even
kernel+libraries+applications.

Now, whether that actually helps SCO is an entirely different question.

Howard C. Shaw III

[ Reply to This | # ]

They're baaaack!
Authored by: Anonymous on Tuesday, July 18 2006 @ 09:47 AM EDT
Apparently now, the "MIT Rocket Scientists" DID exist after all, and
they DID do code comparison.

First Darl says they did, then the court documents say they didn't, now the
court documents say they did.

Reading Appendix A one wonders why they needed the CMVC if they already had
proof. Oh, right, now I remember, they needed the CMVC to show proof of what
they thought they already had proof of, but found out they really didn't. And
still didn't find.

[ Reply to This | # ]

SCO's Objections to Wells' hitting the nail on the head
Authored by: Anonymous on Tuesday, July 18 2006 @ 09:48 AM EDT
To save me putting a link to the previous story I'm reposting here.

On the end of page 52 going to page 53 (IBM-724)

SCO suggests that it would be appropriate for the Judge to order SCO provide
more information on the items under discussion AND extend IBMs time for
discovery.

What is it about prejudice that SCO don't understand.

SCO goes on to say (top of page 53)

"Given this motion has occassioned the first consideration of the
specificity required for method and concept disclosures, and the first
examination of the adequacy of the voluminous December Submission by SCO, this
[giving SCO more time and IBM more discovery]is far more equitable than the
preemptory limiting of claims by the Magistrate Judge's Order"

On Groklaw the cry has often gone up "In what alternate universe does SCO
live in?" I think it will go up again. I think that the Judge has already
answered these objections in her order. Didn't she point out that methods and
concepts were in the case from the beginning and that the specificity applied to
methods and concepts. Didn't she point out that IBM had already told SCO that
its submission lacked specificity and the Judge further pointed out that SCO did
not at any time seek clarification on this.

In which alternate universe do they reside?

delay delay delay... I note that it looks like Vista is late again ...

[ Reply to This | # ]

SCO's Redacted Objections to Wells' Order & Appendix
Authored by: jazzyjoe on Tuesday, July 18 2006 @ 09:54 AM EDT
> SCO then states in the Appendix:
> This is an accurate statement of comparison work performed by SCO in
advance of public statements. There are in fact instances in which SCO's ...


PJ, you need to stop pounding SCO, since the above statement is correct. Their
statements at the time were indeed accurately based on their comparison work.

Of course, no one is disputing the validity of their comparison work...

[ Reply to This | # ]

But SCO did not own it ever
Authored by: Chris Lingard on Tuesday, July 18 2006 @ 10:01 AM EDT

The following quote illustrates something about United States law that I, and probably a lot of other people, do not understand.

Breach-of-Contract Claims (Nov. 30, 2004). The Magistrate Judge thus compounded the error in the improper interpretation of the July 2005 Order through a misplaced summary- judgment-like, and thus dispositive, assessment of disclosures in SCO's December

Submission. Assessing a presentation given by Richard Moore of IBM's Linux Technology Center in June 2005, the Magistrate Judge stated (at 35): While it discusses Kernel patches, thread locks and NUMA there is nothing that links these back to being originally owned by SCO. And even with a related "smoking gun" email there is once again little connection back to what is allegedly owned by SCO. This simply is not enough specificity under the court's orders.

This analysis and conclusion is in clear error. SCO need not show that it "owned" the material disclosed, only that restrictions in the license agreements govern those methods and concepts which it has done.

Kernel patches, thread locks and NUMA were not written by some Utah cowboy on Darl's ranch. They were written by a company called SEQUENT, that was later bought by IBM. Why can SCO claim that they do not need to show ownership, they clearly have no claim on this technology anyway.

[ Reply to This | # ]

Methods and Concepts: Specificity
Authored by: Anonymous on Tuesday, July 18 2006 @ 10:02 AM EDT
IANAL. I certainly cannot judge all the legal arguments made in SCO's objection (though it does seem very cleverly argued from what I can see). The most important questions, though, seem to be
  • what is needed to demonstrate that methods and concepts have been implemented in Linux?
  • is there proof that these methods and concepts came from code in which SCO had some kind of controlling authority?
For all SCO's hand waving, methods and concepts are implemented in code. If SCO cannot point at specific lines of code in Linux that implement a method or concept, they are basically admitting that they have no evidence.

Similarly, to show a controlling authority over a method or concept, they must be able to show both the code (or perhaps design documents) in question and the grounds on which they claim to be able to control its distribution.

I believe SCO has two problems. First, they have no real evidence. Second, they have been avoiding specifying their claims (weak as they are) in a straightforward manner because, properly examined, they are worthless. They must now try to convince the court to allow them to retain worthless, vague claims because they have nothing else.

[ Reply to This | # ]

Yahoo's SCOX Message Board
Authored by: Anonymous on Tuesday, July 18 2006 @ 10:21 AM EDT
Hi All

I have had personal issues which have prevented me from following issues fro the
last two months.

Apparently during that time Yahoo Message Board was droped off the deep end,
success being not desirable, thus a reorganization into an unusable trash.

Would some kind person please post the URLs of the new gathering places.

Thanks

[ Reply to This | # ]

I like footnote 13 and 15
Authored by: jesse on Tuesday, July 18 2006 @ 10:31 AM EDT
and the comment "pound the ESR really hard over the head with a big
hammer".

This is a standard procedure whenever working with a piece of slightly flakey
hardware.

It introduces a time delay giving the device time to respond to the request. It
also ensures that the device accepted the request where the device may sometimes
"drop" directives depending on the internal state of the device.

THIS IS NOT UNUSUAL.

Footnote 15 is also interesting, since the entire thing doesn't differentiate
between IBM/Sequent technology and UNIX concepts. Most of the references appear
to be about HARDWARE, though my deduction is very indirect.

[ Reply to This | # ]

How do YOU spell "mitigation"?
Authored by: Anonymous on Tuesday, July 18 2006 @ 10:38 AM EDT
It's obviously not spelled "185", and yet there doesn't seem to be
anything else to mitigate...

Maybe a scrivener's error at SCO turned the "m" into an "l"
and that was the start of this whole sorry fiaSCO.

[ Reply to This | # ]

Expert Reports
Authored by: toys on Tuesday, July 18 2006 @ 10:44 AM EDT
SCO is getting to have a huge problems remembering which fibs it told in what
documents.

I would lay money on IBM skewering SCOx based on the SCOx expert reports. If
you include these reports along with the pleading in this area it pretty much
blows the words "accidental" and "unintentional" completely
out of the water.

[ Reply to This | # ]

Failure to warn SCO
Authored by: Anonymous on Tuesday, July 18 2006 @ 11:02 AM EDT
I particularly liked the bit about "The Magistrate Judge Clearly Erred in
Failing to Consider Whether
SCO Had Been Warned That Its Claims Were In Jeopardy.":

"An additional factor required to be considered under Tenth Circuit
authority is whether a party had been warned by the court that it faced
dismissal or striking of claims."

So, every time you file a motion with the court seeking to strike or dismiss a
claim, you must request a hearing so the court can inform the other party that
it might decide to grant the motion?

Otherwise, never having been to court before, they might not realize that courts
sometimes grant motions?

[ Reply to This | # ]

Did anyone notice that "source code," as used by SCO's law firms means "UNIX," not "Linux" code?
Authored by: PTrenholme on Tuesday, July 18 2006 @ 11:12 AM EDT

Throughout their motion, almost every reference to "source code" seams to mean "code in IBM's control, not ours" rather than the (I thought) plain meaning: "code in Linux that implements the method or concept."

If one uses their definition of "source code," their argument that the IBM developer would have a clear idea of where the concept originated seems valid. But I thought (and still think) that IBM (and the Court) was asking "where in Linux can we find the violation of which you're complaining?"

In other words, the "technical" meaning of "source code," i.e., the source that was compiled to create the executable binary code, is somewhat different from "source: the place from which it came."

---
IANAL, just a retired statistician

[ Reply to This | # ]

My rebuttal of SCO claims
Authored by: Anonymous on Tuesday, July 18 2006 @ 11:12 AM EDT

"What I'm thinking would be most useful would be to list in your comments anything I forgot to list that rebuts their claims, instead of just laughing."

Here is my list.

jacuse

--------------------
Steve Stites

[ Reply to This | # ]

    Everything Explained
    Authored by: Anonymous on Tuesday, July 18 2006 @ 11:21 AM EDT
    Darl:
    "Along the way, over the last several months, once we had the copyright issue resolved where fully we had clarity around the copyright ownership on Unix and System V source code, we've gone in, we've done a deep dive into Linux, we've compared the source code of Linux with Unix every which way but Tuesday. We've come out with a number of violations that relate to those copyrights...."


    Well...It IS Tuesday... ;) Now we know why they can't find anything...

    [ Reply to This | # ]

    SCO says they control it all
    Authored by: tinkerghost on Tuesday, July 18 2006 @ 11:21 AM EDT
    From the motion:
    These agreements allowed for UNIX source code, methods, and concepts to be used by IBM and Sequent in the development of their own UNIX operating systems but made the source code and methods and concepts in such “derivative” or modified” systems subject to nondisclosure requirements.

    I think that right there is the crux of the issue, "but made the source code and methods and concepts in such “derivative” or modified” systems subject to nondisclosure requirements." SCO is in fact claiming that any M&C used in any Unix system is part of the NDA - irreguardless of where or with whom it originated.

    I really think that's the heart of SCO's case, a claim that once something is included in a Unix derivative, the M&C behind it become retroactively bound by the NDA - even if the M&C was developed outside of the context of Unix.

    While I can understand that in a sort of twisted way, I don't think that it will fly in court when you have AT&T saying "that's not how we intended it when we wrote it", Novell saying "We certainly didn't understand it to mean that when we were AT&T's successor in interest.", and IBM showing where they did similar things while both Novell & AT&T owned the contract - and nobody objected.

    The problem with this is that SCO would still have had to provide FLV(OS) for each of it's M&C NDA complaints, along with either a matching coded M&C in Linux or a communication showing the disclosure. Something they did not do. So even under this 'interpretation' of the contract, they failed to provide the specificity requested.

    ---
    You patented WHAT?!?!?!

    [ Reply to This | # ]

    SCO's Redacted Objections to Wells' Order & Appendix
    Authored by: Anonymous on Tuesday, July 18 2006 @ 11:59 AM EDT
    It seems that the largest single entry that is discussed in Appendix A is Item
    #185. I know that the allegedly infringing materials were sealed, but that much
    of it has come out. Do we know exactly what these items are? I would most like
    to know what 184 and 185 are, given how they're described in Appendix A as
    backing what SCO executives claimed...

    [ Reply to This | # ]

    SCOG still wants to play the
    Authored by: Waterman on Tuesday, July 18 2006 @ 12:16 PM EDT
    "good faith" card. It pops up in several places. I think Judge Kimball
    is going to take that card out of the deck and shred it right in front of them.
    :-)

    [ Reply to This | # ]

    What would it take to overturn?
    Authored by: Anonymous on Tuesday, July 18 2006 @ 12:27 PM EDT
    Could someone explain what the rules are, under which circumstances Judge
    Wells's order would be overturned?

    As I understand it, if this was a situation where two different judges could
    have
    made different decisions, and Judge Kimball thinks that he would have decided
    differently, then Judge Wells' decision would _not_ be overturned. It would only

    be overturned if Judge Kimball thought that she got it completely, incompetently

    wrong. Does anyone have the exact rules for this?

    [ Reply to This | # ]

    SCO's Redacted Objections to Wells' Order & Appendix
    Authored by: Anonymous on Tuesday, July 18 2006 @ 12:37 PM EDT
    I disagree.

    Throwing out 2/3rds of the claims , adn furthermore pema;lizing them by for
    example order them to pay fines fro contempt of court, or impose new
    requirements on them would have been sanctions. Throwing out these items was
    imply a matter of narrowing down discovery to the proper issues. Had seh told
    SCO to go to bed without food, because they were naughty, these woudl have been
    sanctions.

    The remarkable thing with Wells' ruling is the lack of sanctions. Claims lacking
    specificity could have been done in good faith, and still been thrown out.
    Wells states willfulness, which is bad faith, and if she were to impose
    sanctions for that, she would have had to do more than throwing the items out. I
    think she could have given a warning about contempt of court, threatened with
    imprisonment or heavy fines. All Wells did was to point out to SCO that they had
    been stepping over the line. Maybe this coudl serve as a basis for future
    sanctions if SCO insists on continuously insulting the court's intelligence.

    IANAL, though.

    But sanctions means something completely else in my dictionary than they do in
    BS&F's briefs.

    [ Reply to This | # ]

    What? No Puffery Defense?
    Authored by: Dave23 on Tuesday, July 18 2006 @ 12:45 PM EDT
    In my very brief skimming of the Appendices, I didn't notice any direct
    reference to a "puffery defense" with regards to the statements made
    to the press.

    I'm surprised. Or maybe, Darl, you learned from BSF (too late!) that
    "puffery" doesn't apply to legal claims made in public?

    ---
    Nonlawyer Gawker

    [ Reply to This | # ]

    I love the parts where...
    Authored by: kawabago on Tuesday, July 18 2006 @ 01:16 PM EDT
    SCO freely admits it is claiming rights to subsystem code, that IBM developed
    and wrote, claiming it is a derivative work. Isn't that a lot like the item you
    bought owning you?

    [ Reply to This | # ]

    Appendix A item 1
    Authored by: Anonymous on Tuesday, July 18 2006 @ 01:26 PM EDT
    Forget Item 2; Item 1 seems the more explicit wrongness to me.

    "a. Misappropriation in the form of line-for-line code copied from System
    V into the Linux kernel (Item Nos. 183-185, 205-231) as well as line-for-line
    code copied from System V into the Linux tool chain used to compile and operate
    Linux (Item No. 272) and line-for-line code copied from System V into STREAMS
    modules used by, among others, enterprise Linux customers to operate
    "Carrier Grade Linux" (Item Nos. 150-164);"

    The tool chain used to compile and operate Linux? IBM misappropriated System V
    code by contributing it to autotools and GCC? glibc? util-linux?
    module-init-tools? What am I missing? How many others of the numerous
    *independent projects* that might conceivably make up a Linux distribution are
    we talking about here? Why haven't we heard these projects mentioned by name
    (not that I don't have my suspicions on that account)? They are separate
    entities from linux. If it is a contribution to a related, but separate
    project, that should be named explicitly.

    (I haven't been paying close enough attention to find out where I can see (if I
    can see) the references here, so Item No. 272 is obscure to me. Can anyone help
    enlighten me?)

    [ Reply to This | # ]

    SCO's Redacted Objections to Wells' Order & Appendix
    Authored by: Animal_Speaker on Tuesday, July 18 2006 @ 01:46 PM EDT
    You know, it is kind of funny reading through the document, for a moment I had
    the impression they were shouting:

    We complied! We complied!

    ---
    La vida es un sueño, la muerte es el despertar.

    [ Reply to This | # ]

    Exibit A
    Authored by: tinkerghost on Tuesday, July 18 2006 @ 02:10 PM EDT
    Am I the only one who noticed:
    ... the verbetim copying of 80 to 100 lines of code.
    If it's verbetim, how come they don't know the exact number of lines of code?

    ---
    You patented WHAT?!?!?!

    [ Reply to This | # ]

    SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text
    Authored by: stats_for_all on Tuesday, July 18 2006 @ 02:35 PM EDT
    Refreshed table with collated information on allegations.

    [ Reply to This | # ]

    Master at misdirection
    Authored by: Anonymous on Tuesday, July 18 2006 @ 02:40 PM EDT
    You know, you have to give them credit. SCO is a master at misdirection,
    especially when they have a new audience.

    For example, the appendix repeats the public statements and links them to
    examples (usually only one) of where they identified something by file, line,
    and version. But, of course the issue is not that they didn't specify some
    things with the required specificity, it's that they didn't identify the
    stricken claims with the required specificity.

    Another example, they go on about using the words "methods and
    concepts" in their original filing. They never get to the point that they
    were never specific about whatever method or concept they meant before the
    December deadline. I guess their reasoning is that they mentioned methods and
    concepts from the start, so anything they define as a method or concept is
    automatically included, even if they didn't say what method or concept with
    specificity by the deadline?

    They are also glossing over or ignoring the issue of who put in something into
    Linux they claim infringes, implying IBM is the source without actually stating
    so. But of course, this really gets us back to the requirement for specificity
    so that it could be linked specifically to something IBM did.

    So, now that they have a new audience it seems they are bringing out some of
    their old tricks.

    Also, I have to say it looks like this document was prepared in advance,
    considering the length and ordered nature. At least, it looks better and reads
    more logically than most of their filings.

    I wonder how long it will take Judge Kimball to compare all of Judge Well's
    alleged errors with the history of the case? Or if in fact that's how it's
    done?

    [ Reply to This | # ]

    Call me crazy...
    Authored by: Anonymous on Tuesday, July 18 2006 @ 03:13 PM EDT

    ... but when you have three court orders telling you to produce specific information and you fail to do so in response to all three of those orders, you are either deaf or the lack of response is willful.

    Sanctions seem to be the only thing that'll get some folks to take notice that what they're doing isn't what's expected of them.

    [ Reply to This | # ]

    The smart money doesn't buy it
    Authored by: Anonymous on Tuesday, July 18 2006 @ 03:18 PM EDT

    The financial markets don't seem to be impressed by the information in SCO's redacted objection - SCOX is still trading between $2.50 and $2.65 per share. (In May, it never traded below $4).

    [ Reply to This | # ]

    Great defense for IBM should SCO succeed
    Authored by: Anonymous on Tuesday, July 18 2006 @ 04:17 PM EDT
    Simple...for all items that SCO claims they don’t need to provide where the "method and concept" came from IBM says "it didn't come from SVR4" or "Oh, that was from MVS". Of course SCO would still have the opportunity to whip out some impeachment evidence "see, they took it right from here" but then run afoul with their contention that they don’t have it.

    I just don't get how SCO could be allowed to continue considering they have not even proved ownership of these "method and concepts". Why should the court believe it just because SCO points to an email disclosing the "method and concept"

    I think the SCO knows this because they carefully avoid this point in their objection.

    [ Reply to This | # ]

    Do they have a tiger by the tail?
    Authored by: Anonymous on Tuesday, July 18 2006 @ 04:45 PM EDT
    These SCO guys started with a lot of bluster and just assumed IBM would settle.
    They set all this nonsense into motion and are they now stuck with it?

    If they 'fess up and say, "sorry, you caught us, we got nothing, we made it
    up." That's a crime with prison time.

    So are they now forced to do what they can to persue this case to a logical
    conclusion to the best of their abilities. (As disgusting as they are.) Else be
    disbarred or prosecuted?

    Just an interesting question.

    [ Reply to This | # ]

    Appendix A: what's redacted
    Authored by: Anonymous on Tuesday, July 18 2006 @ 05:37 PM EDT
    Compare appendix A to Judge Well's order and notice that SCO redacted out the
    references to "millions of lines of code". I guess there is no way to
    spin around that one.

    [ Reply to This | # ]

    Footnote 13
    Authored by: philc on Tuesday, July 18 2006 @ 05:59 PM EDT
    "/* Pound the ESR really hard over the head with a big hammer-mbligh*/
    If (esr-disable) {
    apic-write (APIC-ESR, 0); .
    apic-write (APIC-ESR, 0);
    apic-write (APIC-ESR, 0);
    apic-write (APIC-ESR, 0);"

    This is as good as they can do?!

    The apic is a bit of interrupt controller hardware that is also on Pentiums. It
    routes interrupts to various processors in a SMP system. It is pretty common to
    run into problems getting the apic to work properly.

    The apic hardware has a bug that requires the reset to be done multiple times.
    This is pretty common. There is a lot of hardware that needs special treatment.
    Linux is littered with hacks to get around hardware bugs. I have had to do this
    kind of thing on multiple occasions.

    So discussing how to workaround a hardware problem is a valuable method and
    concept. Go figure. The valuable concept of stepping on a bit multiple times to
    get it to stick has been around for a long time, well before Unix was written.

    [ Reply to This | # ]

    Wow, numerous defenses
    Authored by: Anonymous on Tuesday, July 18 2006 @ 06:52 PM EDT

    Talk about not being sure if your spaghetti is done: throw the whole pot at the wall and see if any of it sticks.

    RAS

    [ Reply to This | # ]

    Appendix A - the smell of fear
    Authored by: Anonymous on Tuesday, July 18 2006 @ 07:04 PM EDT
    I commented at the time Judge Wells made her ruling that this was the point
    where all of Darl & Co's public statements moved from the PR and FUD arena
    into the real possibility of jail time.

    By quoting those statements in her ruling, Wells has made them part and parcel
    of a legal case in front of the US courts.

    Making it much easier for the SEC and anyone else to shove them up SCO's ...
    (sorry) down SCO's throat.

    Appendix A has nothing to do with winning (or losing) the case - it's all about
    keeping certain people with foot-in-mouth disease out of the slammer!

    [ Reply to This | # ]

    SCO admits lying
    Authored by: Anonymous on Tuesday, July 18 2006 @ 07:26 PM EDT
    [quote]IBM's disclosure in order to show the Linux community how to implement the method or concept in Linux, that code was specifically referenced in the disclosure report. This Court did not direct SCO and SCO did not believe it had been directed, to divine what source code IBM developers had in their minds when disclosing a method and concept without at the same time disclosing source code,. Certainly, the Court did not make such a direction with anything approaching the clarity required to support a sanction order of this severity.[unquote]

    So SCO now admits it has been telling baldfaced lies when it talked about copying of code! As for breach of contract with regard to NDAs, doesn't the same principle apply? SCO has to state what IBM has wrongly disclosed under the NDA, and show some evidence of this, and that IBM and not any one of the many other Unix licensees disclosed the alleged and unidentified methods and concepts. Instead SCO is saying "We don't know what IBM developers had in their minds when disclosing a method and concept, so we don't know what they have done wrong. IBM must have done something wrong and only IBM knows what".

    [ Reply to This | # ]

    The Great Stone Face
    Authored by: vruz on Tuesday, July 18 2006 @ 07:41 PM EDT
    how can they keep a straight face ?

    The Great Stone Face
    by Nathaniel Hawthorne

    ...
    By this time poor Mr. Gathergold was dead and buried; and the oddest part of the matter was, that his wealth, which was the body and spirit of his existence, had disappeared before his death, leaving nothing of him but a living skeleton, covered over with a wrinkled yellow skin.
    Since the melting away of his gold, it had been very generally conceded that there was no such striking resemblance, after all, betwixt the ignoble features of the ruined merchant and that majestic face upon the mountain-side. So the people ceased to honor him during his lifetime, and quietly consigned him to forgetfulness after his decease. Once in a while, it is true, his memory was brought up in connection with the magnificent palace which he had built, and which had long ago been turned into a hotel for the accommodation of strangers, multitudes of whom came, every summer, to visit that famous natural curiosity, the Great Stone Face.
    Thus, Mr. Gathergold being discredited and thrown into the shade, the man of prophecy was yet to come.
    ...

    ---
    --- the vruz

    [ Reply to This | # ]

    Un-freaking-believable!
    Authored by: Anonymous on Tuesday, July 18 2006 @ 08:03 PM EDT
    Page after page of nothing at all!

    Nothing here that they haven't already trotted by the judeges more than once,
    and that hasn't already been destroyed. We knew they had to appeal, but I for
    one, at least expected them to try some kind of new twisted legal argument, or
    new claim... one of the infamous SCO bag of tricks. But nothing! Nada! Just
    whining.

    This is SCO pathetic.

    [ Reply to This | # ]

    Priceless
    Authored by: GLJason on Tuesday, July 18 2006 @ 08:25 PM EDT
    Further, while it was within the Court's authority to implement this additional discovery deadline and process, it should nevertheless be recognized that interim and final submissions to identify "allegedly misused material" are not part of a standard discovery process under the Federal Rules of Civil Procedure."
    Hmmm... Why might that be? Maybe because someone filing suit usually is able to articulate what the other side has done wrong. Imagine Sir Arthur Conan Doyle suing J.K. Rowling saying that she misused materials from a Sherlock Holmes book in her Harry Potter books. He trumpets to the press that there are mountains of words copied and that he had three teams of experts on it. Months later he can't respond to a discovery request asking what exactly was copied and actually gets access to all of her notes and drafts she used when writing the books so he can figure it out. YEARS after that there is still no explanation other than an email she sent to her editor saying something about dragons, yet he still can't show where that came from in any of his books.

    Seriously, the time to tell IBM what they did wrong was in 2003, when you brought the case and IBM asked in its interrogitories.

    I'm just racking my brain trying to figure out what SCO is claiming. At the very least, SCO should be limited to the evidence they've given to IBM, no surprises either in summary judgement or at trial. They seem to be clinging to their misguided ladder theory: AT&T gives IBM a ladder with 10 rungs, IBM adds 10 more rungs, but IBM cannot take off the top two rungs (even though IBM added them) because the bottom 10 rungs were from AT&T. I have total faith that this misconception will be corrected at summary judgement, it is too bad that Judge Kimball postponed it until now.

    SCO sidesteps around the issue of specificity by just claiming that source code isn't always required. From Judge Wells's ruling, it is clear that she did review all the items, and she even let some stay in where no source code was provided because they were specific enough. IBM showed in it's motion how one of the items could mean several different things and they could not determine what SCO believes they had done wrong.

    My blood is just boiling here...

    Such an interpretation of the court's orders would have been most unreasonable since they would essentially be requiring SCO to identify, for IBM, code that was solely in the mind of the IBM developer at the time he or she made the disclosure. Counsel for SCO is aware of no instance in which a party has been sanctioned let alone substantive portions of its case dismissed for failure to identify in discovery information that was not reasonably available to it and was more readily available to the other party.
    If the code exists only in the mind of the IBM developer, what makes SCO think that it is protected by a contract that IBM signed with AT&T over 20 years ago? SCO needs to show how each of these disclosures violated the contract. Basically they are saying "this email had the word Dynix in it so it was misuse of methods and concepts". That developer probably didn't even work for IBM (or sequent) when the contract with AT&T was signed. He may have worked on BSD for 10 years and written the code or came up with the "method or concept" then, and ported it to Dynix after joining IBM.

    They REALLY need to smack down SCO on the "everything in AIX and Dynix belongs to us" theory. That is all that SCO is clinging to on these items and it is unreasonable and unenforceable. SCO's weird theory means that if IBM developed a filesystem for Linux it would be fine, but if they then added it to AIX later, it would be infringing in Linux. That is pure poppycock!

    [ Reply to This | # ]

    Gmail as OCR
    Authored by: rm6990 on Tuesday, July 18 2006 @ 08:54 PM EDT
    Hey everyone. I am not sure whether or not everyone has found a suitable OCR
    solution for when the Summary Judgements start flying, but I just tried a little
    experiment. I downloaded SCO's motion, and then used my Gmail account to email
    it to myself.

    For those of you who don't know, whenever a text attachment (whether it be
    opendocument, MS Office, PDF, etc) is sent or received by Gmail, Gmail
    automatically converts the document to HTML. Then, when you view the email, it
    gives you the option to view the attachment as HTML as opposed to downloading
    it.

    When I clicked View as HTML on the SCO document, it came out with an almost
    perfect (to me, anyways) reproduction of the document in HTML format. It is even
    more realistic in that even the length of each line is identical to the
    original.

    So yeah, there was a thread a while back looking for solutions when the big
    motions start flying. Just thought I would put this idea out there and see
    whether or not it would work, and whether anyone else has tried it before.

    If anyone needs a Gmail invite, post in this thread and let me know.

    [ Reply to This | # ]

    SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text
    Authored by: Anonymous on Tuesday, July 18 2006 @ 09:54 PM EDT
    Now if they only said the code was in SUSE, we could all
    take a break and wait for the Novel/SCO case be finish
    arbitration.

    [ Reply to This | # ]

    Why doesn't IBM file a motion for a ruling on the *PROPER* interpretation of the contracts?
    Authored by: Anonymous on Tuesday, July 18 2006 @ 10:06 PM EDT
    Surely this would gut SCOG's case where it matters, and all this other nonsense
    can be foregone.

    [ Reply to This | # ]

    did SCOG just make a MAJOR error?
    Authored by: skidrash on Tuesday, July 18 2006 @ 11:03 PM EDT
    by referencing the code comparisons they did do but refused to turn over ??

    SCOG refused to turn them over to IBM because, SCOG claimed, they would not be
    used.

    Surely IBM can now petition the court to FORCE SCOG to turn every detail of
    those over?

    [ Reply to This | # ]

    SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text
    Authored by: Anonymous on Tuesday, July 18 2006 @ 11:18 PM EDT
    IBM's disclosure in order to show the Linux community how to implement the method or concept in Linux, that code was specifically referenced in the disclosure report. This Court did not direct SCO and SCO did not believe it had been directed, to divine what source code IBM developers had in their minds when disclosing a method and concept without at the same time disclosing source code,. Certainly, the Court did not make such a direction with anything approaching the clarity required to support a sanction order of this severity.

    Bull. Bull, bull, and more bull. Do these people think the world is stupid?

    If a method or concept is employed in a piece of software, it must be expressed in the code. If that method or concept has been appropriated for another piece of software, then it must be expressed in the code there too. It cannot be otherwise for the method or concept to be present. If it cannot be identified in the first piece of software then it didn't exist there. Period. If SCO is going to allege that a particular concept or method was stolen from SVR4, then it had to exist there somewhere! To retain the claim in their case, it would have been sufficient to point out even one place where it was used. Who cares what some random IBM developer might have had in mind?

    Fine, save proving how it got from there into Linux for the trial, but at least demonstrate in the first place that you possess the thing you're saying was stolen!

    [ Reply to This | # ]

    Even if the code was copied, and even if scox owned the code,
    Authored by: Anonymous on Tuesday, July 18 2006 @ 11:58 PM EDT
    scox still has not provided any evidence that this alledged copying was done by
    IBM.

    What scox claims to own is sysV. Scox is not even claiming that IBM copied sysV
    into Linux. Yet they go on and on and on, about similarities between sysV and
    Linux.

    As IBM has already pointed out: thousands of people have contributed to Linux.
    Unless scox is claiming that the code in question was put there by IBM, it's not
    relevant.

    [ Reply to This | # ]

    SCO will own Microsoft
    Authored by: Anonymous on Wednesday, July 19 2006 @ 12:08 AM EDT
    SCO's stated position is that they own the copyrights to UNIX and any derived
    work is also belongs to them by reason of their license agreement.

    This would mean to SCO that works derived from works derived from the methods
    and concepts in UNIX even though the code no longer made a specific connection
    would still belong to them.

    This list would include Mimix, the MKS tool kit, PS-DOS 2.2, and by derivation
    Windows, ME, MAC OS X, to name a few.

    This would mean that if SCO wins this law suit, it will own just about every
    operating system on the planet, and can extract a fee for each and every copy
    sold back to 1993.

    I don't think even Microsoft would have the money to pay. SCO would virtually
    own them, and IBM, and all the rest.

    No wonder they want methods and concepts included without specificacy.

    [ Reply to This | # ]

    I am honestly suprised
    Authored by: mobrien_12 on Wednesday, July 19 2006 @ 12:28 AM EDT
    I truly am amazed. I do not think this has a snowballs chance in Utah's deserts
    sun of going through. Are they truly going for the Microsoft
    annoy-the-judge-innecessantly-then-cry-foul-on-appeal defense?

    It's not like they don't have other claims.



    [ Reply to This | # ]

    SCO Logic
    Authored by: MrCharon on Wednesday, July 19 2006 @ 12:52 AM EDT
    The Magistrate Judge’s Order goes so far as to strike SCO submissions where the code associated with a particular method and concept is cited in the Report, but cannot be accessed because it resides in an IBM server to which only IBM has access.

    a) How does SCO know what source code is on that server if only IBM has access too it?

    b) Why did SCO not request the source code during discovery?

    ---
    MrCharon
    ~~~~

    [ Reply to This | # ]

    • SCO Logic - Authored by: eric76 on Wednesday, July 19 2006 @ 01:21 AM EDT
    • SCO Logic - Authored by: Anonymous on Wednesday, July 19 2006 @ 09:31 AM EDT
    • SCO Logic - Authored by: Christian on Wednesday, July 19 2006 @ 02:38 PM EDT
    SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text
    Authored by: Anonymous on Wednesday, July 19 2006 @ 01:19 AM EDT
    IANAL After reading many comments here, I think there is a good chance that
    Judge Kimbal will not grant SCO their request. Much to the credit of Judge
    Wells! The big concern I had, was that the methods and concepts controls that
    could have merits, based on the wording of the original AT&T contract. No
    IBM source code need be identified to describe a method or concept. Disclosure
    of a method or concept could still be a contract violation without code making
    its way into Linux.

    However it was pointed out that a ladder has to have a base somewhere that was
    inside IBM under the SCO pruported span of control. A base outside IBM would
    absolve IBM. It seems that SCO was required to demonstrate that they had reason
    to believe that base was within IBM under SCO's pruported span of control.
    Wells covered this when she denied IBM in part for claims of disclosure where
    there was deposition to reveal what was in the minds of IBMers disclosing to
    Linux Developers.

    I think that the best that SCO can hope for here is for Judge Kimbal's refusal
    of request to file overlength memorandum. They seem almost to be inviting
    additional case management from Judge Kimbal and I don't see them scoring any
    points with Judge Wells.

    IANAW What a difference women make! Both PJ and Judge Wells with their
    dilligence have carefully tended the base of our socities and are happy to let
    us men (mostly, here I presume) enjoy the benefits.

    It would be interesting to see this get to oral arguments. It would probably
    take us a week to realize when the Nazgul inserted the knife. It won't be
    obvious unless they want it to be obvious. It just a lot less bother that way.


    For some reason I expect a number of motions from IBM carving up the remains of
    this case piecemeal, instead of one big summary judgement but I can't say why.
    Maybe it is less of a burden for the judges to give ten forty page rulings than
    a four hundred page ruling

    [ Reply to This | # ]

    Redacted?
    Authored by: Night Flyer on Wednesday, July 19 2006 @ 03:24 AM EDT
    I read through the text copy and the pdf file. It seemed to me that only a very
    small portion of the document was redacted, and the redacted amounts (usually a
    line or two) seemed to be opinions of various people.

    As an example: (Page 42) "Moreover, Mr. Wright, at his deposition ....
    admits" "REDACTED"

    I am intrigued as to why they have redacted what might be their best points.
    (There isn't enough space for very much secret code.) I can only presume it is
    to tease GROKLAW readers. Or maybe the arguments are so weak they cannot stand
    scrutiny.

    ----------------
    I more-or-less understand SCO's position: One analogy I use to explain it, is
    that, in SCO's world, if I were to write a murder-mystery novel, however
    original the detail and description, the butler cannot be the murderer because
    it has been done in a copyrighted novel before me.

    I would be found guilty of copyright infringement and in violation of various
    unspecified methods and concepts throughout the book, (a gun? a knife? poison?,
    in the kitchen? -all been done) and if I wrote "The butler did it"...
    -endless pain-

    My mind boggles at living in SCO's universe and what it would mean to creativity
    and progress.

    ---
    Veritas Vincit - Truth Conquers

    [ Reply to This | # ]

    Hardware and firmware
    Authored by: Jude on Wednesday, July 19 2006 @ 05:00 AM EDT
    One of SCO's more bizarre discovery demands was for hardware and firmware
    information. Now I can see why they wanted it.

    Under SCO's viral IP theory, anything the ever touches Unix or any Unix
    derivative must forever be kept secret. Unix, like any OS, must be able to
    control the hardware it runs on. According to SCO, this would make the hardware
    specs themselves subject to confidentiality. The logical conclusion would be
    that any hardware ever used to run a Unix derivative would be forever restricted
    to running only proprietary closed-source OS.

    I think Microsoft would be very gratified by such a result. I wonder if this is
    one reason why they bought that license from SCO?

    Microsoft aside, this conclusion is so obviously unreasonable that I think it
    casts doubt on the validity of SCO's viral IP theory. IANAL, but I'm pretty
    sure the courts are disinclined to accept contract interpretations that are
    manifestly unfair.

    [ Reply to This | # ]

    Important Lesson
    Authored by: iceworm on Wednesday, July 19 2006 @ 05:37 AM EDT

    Golly! We have a good lesson to learn here, to wit: When preparing to shoot oneself in the foot, select a small caliber revolver. Do not, repeat NOT attempt to use a hand grenade. And I only read the introduction.

    [ Reply to This | # ]

      Re: Feature request
      Authored by: Anonymous on Wednesday, July 19 2006 @ 06:53 AM EDT
      This is in response to the feature request item in the off topic section. It was
      posted in respose to Brian S's comment by clicking the button above the comments
      at the top of the page... Lets see where it ends up.

      [ Reply to This | # ]

      I hope Judge Kimball sees it like this
      Authored by: Anonymous on Wednesday, July 19 2006 @ 07:04 AM EDT
      Even under SCO's bold derivates theory, if a method or concept wasn't embodied
      in any UNIX before IBM donated it to Linux, then SCO can't claim to own it, no
      matter how convoluted their contract interpretation. And SCO, with full access
      to IBM's source control system, have just admitted that there is no embodiment
      of these contested methods. So they don't and can't own them. Claim denied.

      If there is an implementation in UNIX, but the method or concept wasn't
      implemented in Linux (which, again, SCO have just blown their last chance to
      identify), then OK, perhaps IBM breached a contract term. But there was no loss
      to SCO, direct, indirect, tangible or intangible. No loss, no damages, no basis
      for relief. Claim denied.

      [ Reply to This | # ]

      Methods & concepts -- who owns what?
      Authored by: Anonymous on Wednesday, July 19 2006 @ 09:04 AM EDT
      What really tees me off, is the arrogance of tSCOg asserting that all these
      "methods and concepts" that IBM donated to Linux, came from SysV UNIX,
      or somehow became subject to restrictions because they were incorporated into a
      version of SysV UNIX. Anyone with even a passing exposure to IBM history knows
      tSCOg is full of hot air.

      IBM was writing operating systems when Darl was in diapers. They have probably,
      as a corporation, forgotten more "methods and concepts" than Darl and
      his crew of litigious monkeys ever "owned". And IBM has written
      operating systems far larger and more complex than UNIX both before and after
      they bought Sequent. IBM's body of operating system knowledge far exceeds that
      of any "UNIX company". Remember Deep Blue (the champion chess plaing
      computer)? -- IBM. The space shuttle's original three (four?) computers were
      IBM -- a redundant fault detecting multiprocessor system developed in the
      seventies.

      To assert, for example, that the concept of "pounding on a register real
      hard with a big hammer" is something that one could have only learned from
      seeing the UNIX source code, is laughable. As is the assertion that because the
      code to perform a certain function has been part of a UNIX code base at some
      time, it becomes forever encumbered by a secrecy restriction and can never be
      used in any other operating system.

      Thanks, I feel better now.
      Peter

      [ Reply to This | # ]

      (IMHO) The death blow for "Methods and Concepts"
      Authored by: toads_for_all on Wednesday, July 19 2006 @ 09:26 AM EDT
      From the Side Letter of February 1985:

      9. Amend Section 7.06(a) by replacing such section with the following:

      ...Nothing in this agreement shall prevent LICENSEE from developing or marketing products or services employing ideas, concepts, know-how or techniques relating to data processing embodied in SOFTWARE PRODUCTS subject to this Agreement, provided that LICENSEE shall not copy any code from such SOFTWARE PRODUCTS into any such product or in connection with any such service and employees of LICENSEE shall not refer to the physical documents and materials comprising SOFTWARE PRODUCTS subject to this Agreement when they are developing any such products or service or providing any such service.


      (Strikeout is per Amendment X, paragraph 6)

      One really has to wonder just what it is about this paragraph that SCO doesn't understand. Unless IBM used actual AT&T(now SCO)-owned code, "methods and concepts" is a dead issue. This paragraph alone should be enough for a PSJ on any "methods and concepts" claim that doesn't specify code that SCO can prove ownership and control of.

      [ Reply to This | # ]

      Language
      Authored by: belboz on Wednesday, July 19 2006 @ 09:42 AM EDT
      Darn!

      Almost all the redacted parts follow just after the word "admitted" or
      "admits".

      It must be extreamly incriminaating, since the people were forced to
      "admit" it!

      Also: several places in the document, IBM "has admitted". SCO on the
      other hand has merly "infomed" IBM of things.

      No doubt here: SCO must be innocent.

      .... just in case: I might have been slighly ironic.

      [ Reply to This | # ]

      I didn't want to believe it, but...
      Authored by: Anonymous on Wednesday, July 19 2006 @ 09:59 AM EDT

      ... in defense of its failure to provide specific files and line numbers, SCO is actually using the argument that they didn't do this because IBM didn't point to those lines of code.

      "Un-freaking-believable" is all I can say.

      [ Reply to This | # ]

        SCO's Redacted Objections to Wells' Order & Appendix - Updated, as text
        Authored by: webster on Wednesday, July 19 2006 @ 10:58 AM EDT
        .
        0. It's late and it's long, but it lookl like a fun read. Especially after
        skimming the comments. IBM is going to pick this apart and stress every twist
        and lie. When your argument is weak you have to stretch and misapprehend. That
        is what they have been doing to oppose the obvious.

        1. Intro: Flying start. SCO tells Judge Kimball that Wells didn't know what
        he ordered. If Kimball doesn't remember or understand it, they can rely on good
        ole SCO to explain it:

        --*--"...extraordinary Order that is improperly predicated on what the
        Magistrate Judge "believes" this Court has required..."--*--

        SCO embarks on a very slow and crooked path. They are being devious and hiding
        the obvious but the truth is in the air. They think they have crossed the
        pasture without stepping on anything, but SCOspeak has a meaning. Note how they
        never claim any method or concept. Never do they say they took "Our"
        methods and concepts. They never say methods we put in Unix or mthods we
        created. They don't make a specific claim that they own any of it. They talk
        past the obvious. And then they blurt out a possible truth despit themselves:

        --*--"SCO simply cannot be sanctioned when it is providing all of the
        information that it has.--*--

        It is providing all the information that it has and more, but they are being
        sanctioned. That is because they pretend they have something but don't specify
        what it is. They are saying they have no claim but throw this chaff out hoping
        some judge will buy it.

        II. Background is clear enough for SCO. Contracts by IBM and Sequent are the
        backbone of their claim. But they dare to say that Kimball did not want
        Version, File and Line because he did not adopt that wording suggested by IBM.
        So SCO is now saying they can read Kimball's mind. They then discuss IBM's
        Motion to Strike and the history with the experts thrown in.

        The only thing that SCO ever does is point to a discussion or
        "disclosure" of a concept or method by an IBM employee. They don't
        say where the method come from OR say where it was put in Linux, or that it was
        even put and used in Linux. You have to think - no harm, no foul.

        SCO whines to Kimball that they were fouled by IBM's rebuttal expert declaration
        which they claim Wells relied on in her deision. Pretty good argument but
        another relentless instance of form over substance.

        3. De Novo review and appropriate sanction. They spout the laws as they see it
        and stress the ones they want applied to reverse Wells. Rule 72 and the
        "Ehrenhous Factors." They are there for the Judge to use if he wants
        to.

        4.A They say they complied. And that Judge Kimball didn't want v-f-l. They
        repeat the same old. IBM disclosed a concept from AIX/Dynix a file in Linux.
        SCO again gives no source. They again stress that Kimball left out the v-f-l in
        his scheduling order. He could have specified it, he didn't specify it, so he
        must not have meant to be so specific. Certainly Kimball knows what he meant by
        all misused material and how it should be specified. He's been around many
        cases before this one. What a set-up for Wells' riposte: "If you disputed
        what it meant, why didn't you ask for a clarification?"

        SCO says that the claims can't be identified by source code. But they arise
        from a contract on Source code. The derivative claim, such as it is, must be
        their desperate defense to frivolity.

        4. B. They argue that IBM didn't ask for specificity. Sometimes they just
        can't resist giving the other side a target.

        4. C. Here SCO tries to rebut Wells' conclustion that SCO knows what
        specificity is. They asked for it themselves and their own code
        "expert" Sandy Gupta explained it all in his deposition. He
        articulated how you needed code which would manifest a method and concept. But
        they go back to all your code is derived from mine contract theory. So they
        don't need code. SCO is particularly stung by IBM's arguments here. They were
        presented last and prominently if not on the sly by IBM. IBM loves to see SCO
        rebut and repeat this stuff. It's a winner.

        The presumption is going to be against SCO. Kimball will need some clear
        arguments to smack down his colleague. But he can be had. Remember he let that
        slander of title survive just out of curiosity, it seems.

        5 A. ...MAGISTRATE...ERRED IN ...WILLFULLY...: The order was ambiguous at best
        and the Judge changed interpretations. She didn't realize this. she does not
        know her own mind. SCO can't be faulted for willfully not specifying. They are
        letting Kimball know Wells can't be taken at her word. Twisting away.

        5 B. Watch out here SCO! If SCO is saying they specified what they had, and
        are therefore not willfully failing to comply, they might be saying they don't
        have anything. They are willfully not specifying what they don't have.
        Nothing. IBM invited them to say so years ago. They again blame IBM for not
        specifying.

        The Judge used their public statements against them here. SCO says the
        statements don't prove they are holding out: "statements do not mean that
        SCO possessed such evidence regarding the 198 methods at issue." p. 37.
        Their public statements were not talking about these items. They must have been
        talking about the "never mind" items. They also shouldn't be
        sanctioned for failing to ask for a clarification when the discovery dispute
        arose. I'm sure they feared "clarification." It would take away
        their arguments.

        VI.. Here SCO tells Kimball that Wells did not rule with sufficient .......
        {here it is!] specificity! Such brass... Well, so what. With so many items
        it is reasonable to deal with them in groupings which she did. But I guess they
        found some law so they won't restrain themselves. Like they are going to make
        Kimball overrule her item by item. They want a hearing and experts on every
        one. This is their twisting back to the dispositive rendering on the merits
        issue. You have to watch these guys.

        VII. Finally they say Judge Wells didn't find prejudice properly; that IBM is at
        fault for not specifying; that SCO was not warned: that she did not consider
        alternatives.

        Altogether another overlength tour de force that should help get Kimball
        specifically reacquainted with SCOland. He is going to sit down and read Wells
        Order, SCO's Objection, IBM's Opposition and SCO's reply. IBM should now pull a
        rebuttal to every point with caselaw and Wells Order itself.

        Most disturbing is that SCO seems to deny code is necessary. They repeatedly
        argue Methods and Concepts from the contractual derivative theory. It seems
        they should have specifically said so at some point and not wasted so much of
        the Court's and IBM's time. If we have a copying case without code, they could
        have saved everyone a lot of trouble. As we grind on here we are seeing the
        mill produce little product and great waste. SCO must think that their
        specified code copying claims are frivolous.



        ---
        webster

        [ Reply to This | # ]

        Judicial economy
        Authored by: Jude on Wednesday, July 19 2006 @ 11:06 AM EDT
        It seems to me that much of SCO's case hangs by the thread of SCO's
        interpretation of the scope of the nondisclosure stipulations in the contracts.
        If SCO's interpretation is not accepted by the courts, then there is no point in
        individually considering the merits of many of SCO's numerous claims.

        Can Kimball apply the principle of judicial economy by dealing with the contract
        interpretation first? Or is he doomed to let SCO present all of the gory
        details to a jury?

        [ Reply to This | # ]

        Appendix A and public comments
        Authored by: Anonymous on Wednesday, July 19 2006 @ 04:16 PM EDT
        Let me get this straight...

        SCO had three teams of deep divers turn up millions of lines of literal copying
        BEFORE any of the discovery, but that isn't at issue. They're concerned only
        about the methods and concepts that turned up in discovery that they didn't know
        about until recently.

        Hmmm... but those MIT guys, who could find all those millions of lines that no
        one else can find, couldn't figure out that they involved methods and
        concepts...

        Not even methods and concepts that were part of standards that had been public
        knowledge for years.

        What about that seems a little funny?

        [ Reply to This | # ]

        Wilful behaviour
        Authored by: NigelWhitley on Wednesday, July 19 2006 @ 05:34 PM EDT
        I understand why many feel that SCO's objections are reasonable. IANAL but it
        seems SCO's case is based on circumstantial evidence. A key element in
        determining the validity of circumstantial evidence is the corroborating
        evidence - that permits the court to decide whether there are other reasonable
        explanations for the alleged incriminating behaviour.

        SCO say they failed to provide the corroborating evidence (file,version,line)
        because they could not find it : they are incompetent not wicked so shouldn't be
        punished.

        Unfortunately for SCO's position, the court had already defined the standard for
        submitting claims so that each side would be able fairly to prepare it's
        defence. Their wilful behaviour which permitted the claim to be struck was not
        failing to provide the evidence it didn't have - it was wilfully submitting a
        claim without the required level of corroborating evidence. If they knew they
        lacked the required information they should not have submitted the claim. If
        IBM's behaviour "may" be consistent with infringing behaviour it is
        the corroborating evidence which permits the court to assess possible
        non-infringing alternatives.

        Simply, if SCO can't provide evidence it came from SVR4 only then the claim
        fails : if they can't show where their property was used, there is no harm so no
        relief is possible and the claim must be struck.

        [ Reply to This | # ]

        • Wilful behaviour - Authored by: Anonymous on Wednesday, July 19 2006 @ 06:07 PM EDT
          • Wilful behaviour - Authored by: Anonymous on Thursday, July 20 2006 @ 07:57 AM EDT
        spoliation of evidence
        Authored by: ggiedke on Friday, July 21 2006 @ 04:10 AM EDT
        As pointed out in a Forbes article SCO accuses IBM of destroying evidence:

        Even after the Court ordered the source code to be produced, IBM failed to produce all versions of its AIX code, claiming that they cannot be located. Even more egregious was IBM's spoliation of evidence. Weeks after SCO filed its lawsuit, IBM directed "dozens" of its Linux developers within its LTC and at least ten of its Linux developers outside the LOC to delete the AIX and/or Dynix source code from their computers. (SCO Opp. Memo. (3/7/06) at 3.) One IBM Linux developer has admitted to destroying Dynix source code and tests, as well as pre-March 2003 drafts of source code he had written for Linux while referring to Dynix code on his computer. (Id. at 3-4.)

        This sounds like a serious allegation. But if it were, why haven't we heard of it before? Is there any relevance to this allegation? After all, the fact that IBM developers deleted stuff on their computers shouldn't prevent SCO from pointing out which of their "property" has shown up in Linux, as all its versions are, afaik, still available at kernel.org. But if no SCO property ended up in Linux, then there was nothing incriminating on IBM's hard disk, so no evidence can have been deleted...

        [ Reply to This | # ]

        Perhaps I'm just dumb...
        Authored by: Anonymous on Friday, July 21 2006 @ 10:35 AM EDT
        ...but why, if code is irrelevant, did SCO request source code for every version
        of Linux under the sun?

        [ Reply to This | # ]

        A pretty big claim against IBM
        Authored by: Bill The Cat on Friday, July 21 2006 @ 01:29 PM EDT
        VII. THE MAGISTRATE JUDGE CLEARLY ERRED IN FAILING TO REQUIRE IBM TO ESTABLISH PREJUDICE AND TO CONSIDER ALTERNATIVES TO THE SANCTION IMPOSED.
        B. The Court Failed to Consider IBM's Own Responsibility for the Lack of Complete Source Code Identification.
         
        Even after the Court ordered the source code to be produced, IBM failed to produce all versions of its AIX code, claiming that they cannot be located. Even more egregious was IBM's spoliation of evidence. Weeks after SCO filed its lawsuit, IBM directed "dozens" of its Linux developers within its LTC and at least ten of its Linux developers outside the LOC to delete the AIX and/or Dynix source code from their computers. (SCO Opp. Memo. (3/7/06) at 3.) One IBM Linux developer has admitted to destroying Dynix source code and tests, as well as pre-March 2003 drafts of source code he had written for Linux while referring to Dynix code on his computer. (Id. at 3-4.)
         
        50
         
        Clearly, any effort to link up methods and concepts with specific source code from Dynix or AIX would have been assisted by the information that was intentionally discarded by IBM after the filing of the suit. At argument, however, the Magistrate Judge believed that this issue was irrelevant to the matter before the court, and did not address it in the Order. SCO intends to raise the issue of IBM's spoliation of evidence before this Court at the appropriate time. However, in light of IBM's present Motion, the issue of IBM's spoliation of evidence has become immediately relevant and the Magistrate Judge should have considered it in assessing responsibility for the problem if, as the judge concluded, SCO was obligated to identify source code coordinates for all method and concept disclosures.

        I assume that SCO is going to have to prove this claim. By reading what they said, it is possible that the code was destroyed but had nothing to do with the case -- it could have occurred years ago but, SCO has worded it to sound that it was done with malice.

        ---
        Bill Catz

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