Here is IBM's answer to all the discovery accusations from SCO in their Renewed Motion to Compel, their Memorandum in Opposition to SCO's "Renewed" Motion to Compel. Note the quotation marks. A renewed motion normally means you are asking the court once again to force the other side to give you what the court earlier ordered they should or the other side represented to the court they would provide but then failed to produce.
That's not the case here. Here, IBM says, they have complied with the Court's Order of March 3, 2004 in all respects, so it's ridiculous to call it a "renewed" motion. This "renewed" motion, they tell the court, has been filed by SCO in the apparent hope of simply further delaying discovery and resolution of the summary adjudication IBM is requesting on its 10th counterclaim.
You can see a Renewed Motion to Compel and a supporting Memorandum by Boies and the DOJ in the US v. Microsoft trial, by the way. There, in a hearing, Microsoft's attorneys said that they were surprised that one issue was in the original motion to compel, because they were working with the other side voluntarily and would continue to do so. The judge accepted that. Later, when the US side didn't get what it thought was promised, they brought a Renewed Motion to Compel. I'm starting to wonder if the Boies team had that template in the office and cynically pulled it out to toss it in to the SCO case just to try to achieve a delay. That might explain why it has so little to do with anything IBM actually has done. You'll see some similarities in Boies' request and SCO's, if you read it, including asking for unfettered access to Microsoft's database.
Anyway, IBM points out that there is no justification for a "renewed" motion, because they are in full compliance with the one order from Judge Wells.
IBM then carefully and methodically lays out all SCO's little tricks they believe SCO is using to make IBM look bad to the judge and to the world.
First, they point out, SCO is asking for the same things that the court already said IBM didn't have to produce, like all the code that ever was, even code that has absolutely nothing to do with this case. SCO, like a shark that tries to take a bite, then swims away and then circles back around from a different angle, is now back, asking the court in a new guise for the same thing it asked for before and was refused. It's a renewal of their persistent efforts to get code that isn't relevant to the lawsuit, which the court already ruled IBM didn't have to produce. They call that "discovery abuse" on IBM's part?
Second, SCO has already filed a Memorandum Regarding Discovery, asking for the same code this "Renewed" Motion to Compel is asking for. IBM responded. But before SCO replied, it filed this new "renewed" motion, asking for the same code all over again, before the Memo Re Discovery was fully briefed, let alone decided by the judge. In the footnotes, 1 and 2, IBM implies that this is all a bogus, phoney deal. This motion was filed, they point out, the day before it filed its opposition to IBM's motion for summary judgment on its 10th counterclaim. In its opposition papers, SCO then said IBM's motion should be denied, among other reasons, because SCO had a motion to compel pending before the court. Come on, IBM is saying. How obvious is it that SCO is just trying to avoid losing the motion for summary judgment, any way they can and is desperate to try to postpone judgment?
Third, as for the items that SCO says IBM was "ordered" to turn over, the court told IBM to turn over only what IBM had already volunteered to provide to SCO, but which SCO had refused to accept, turning to the court with a motion to compel instead. All SCO got was what IBM had already offered, and as for the court's order, IBM complied with the order promptly, so this motion is just grandstanding. SCO seems to be playing to the crowd outside the courtroom, IBM says.
Here is what SCO is now asking for:
- the code this court said IBM didn't have to produce;
- documents from IBM executives IBM has already said don't exist;
- contact information for witnesses the Court didn't require IBM to produce
IBM has already turned over everything it is "obligated or should be required to produce". Therefore, the "renewed" motion to compel should be denied:
"SCO appears to have filed this motion merely to prolong discovery unnecessarily (by making IBM gather and produce masses of irrelevant information and information that SCO could discover on its own with little effort) and to forestall the adjudication of IBM's pending motion for summary judgment on its Tenth Counterclaim. Indeed, SCO filed this motion without conferring with IBM as required under DUCivR 37-1(a) and Fed. R. Civ. P. 37(a)(2)(A), presumably because SCO knew the issues it raises could easily have been resolved by the parties without involvement of the Court."
Fourth, regarding IBM's alleged "refusal" to produce all source code for AIX and Dynix, allegations which plastered the headlines all over the world, IBM says with some indignation that, in truth, they turned over everything they were supposed to:
"Despite SCO's request (in its original motion to compel) that IBM be ordered to produce all source code files for its AIX and Dynix operating systems, the Court ordered in its March 3, 2004 Order, only that IBM provide 'the releases of AIX and Dynix consisting of "about 232" products as was represented by Mr. Marriott at the February 6, 2004 hearing'. (3/3/04 Order at II.1.) IBM produced all of these releases of AIX and Dynix well in advance of the April 19, 2004 deadline set by the Court.
"In this 'renewed' motion to compel, however, SCO asserts that IBM failed to comply with this Court's Order and engaged in 'discovery abuse' by not producing the very source code files the Court held IBM did not have to produce. SCO's argument is frivolous. The Court rejected SCO's original motion seeking this information. Indeed, the Court specifically provided in its Order that it would 'consider ordering IBM to produce more code from AIX and Dynix' only if SCO submitted additional briefing to the Court that would 'include, with specificity, and to the extent possible, identification of additional files SCO requests and the reasons for such requests'. (3/3/04 Order at II.1.)
"SCO purportedly invoked this very procedure in filing its Memorandum Regarding Discovery on May 28, 2004 requesting the production of all source code (rather than just specific files) maintained by IBM for its AIX and Dynix programs in its internal 'CMVC' and 'RCS' databases."
As we know, SCO has problems with specificity.
Fifth, SCO's original and equally unnecessary motion to compel, the one in November of 2003, was about Interrogatories 2, 4 and 5. SCO asked for the following:
A list of names and addresses of everyone with knowledge about any issues of this lawsuit, with the subject matter the witness has knowledge about
- A list identifying all persons who have or had access to UNIX, AIX and Dynix source code, including all derivative works, modifications and methods, with precise listing of materials each had access to
- A list of IBM or Sequent personnel that work or worked on development for AIX, Dynix and Linux, listing their contributions.
IBM provided responses, but SCO complained that senior executives should be on the list for Interrogatory 2 and that they didn't get addresses for 4 and 5. The court directed IBM to provide such, and it did. The list of 7,200 individuals didn't satisfy SCO, because they wanted for each name the precise contributions to AIX, Dynix and Linux.
But SCO's claim doesn't match this unreasonable request. They are complaining about contributions to Linux, not code IBM developed for AIX and did not contribute to Linux. As for what each IBM person donated to Linux, it's publicly available information which the court told SCO to go dig up itself. For the rest, there really is no way to figure out who did what and we are talking about 2 billion lines of source code, most of which isn't relevant to this case. (PJ aside: so much for proprietary software being better than Linux because "unknown" parties contribute code to Linux and proprietary software is carefully tracked and monitored.)
Sixth, as for the accusation that IBM is filtering documents of executives, that is simply untrue. They looked, they found, they turned over. There isn't anything else to turn over, so there is nothing for the court to order IBM to do. And furthermore, SCO paints a false picture in saying it has been forced to move to compel "two times" to get these documents. The original motion to compel filed by SCO had to do with three (2,3 and 11) of the 52 requests from SCO's 1st Request for the Production of Documents, all of them asking for code, not documents. The motion didn't ask for compelled production of documents of executives. Then their next move was to complain at the hearing in February that IBM had failed to turn over documents responsive to requests in SCO's 2nd Set of Document Requests, which they had only served on IBM the day before the Court stayed further discovery of IBM. If SCO didn't have them on February 6 at the hearing, it was because the stay was still in effect.
In any case, SCO isn't entitled to "the full files" of IBM executives, which it now is clamoring for, in IBM's opinion. Not every document in the files, even if it says Linux somewhere on it, has to do with the issues in this case. The request is overbroad. SCO identified what it said was relevant, and IBM turned over documents in response. IBM shouldn't have to turn over documents SCO never asked for in any of its document requests and which have no relevance to the issues here.
Seventh, on the matter of contact information, originally IBM turned over the 7,200 names and SCO complained about needing contact info for each one. IBM objected to the request as being overbroad, and the court obviously agreed, ordering them to turn over contact information for 1,000 individuals, as agreed upon by IBM and SCO. Of course, getting the parties to agree to a list has been a problem. IBM wrote to SCO asking who it wanted on the list of 1,000 individuals from the list of 7,200. SCO instead decided to make up its own list of anyone it wanted, whether they were on the 7,200 list or not, and indeed whether they had ever even been identified by IBM, including people IBM doesn't have contact information for. SCO asked for contact info not for the 1,000 from the 7200 list, but for some on a list of third-party witnesses identified by IBM in response to Interrogatory 2, such as Ransom Love and Bryan Sparks. They even asked for contact information for a current SCO employee. Surely SCO already has that. IBM has no contact info on these, other than what they could find in the course of an investigation which SCO could just as easily do for itself. Try the phone book.
SCO hasn't turned over the equivalent information to IBM. So IBM has an idea. How about we *both* help each other out and we'll give SCO what information we have, and SCO can do the same? They don't think SCO is entitled to what it is asking for, but to move past this "silly dispute" IBM says it is hereby turning over all the info it found in places like the phone book, and they formally ask the judge to so order that SCO do the same in return and turn over contact information in the possession of SCO or SCO's counsel for each of the witnesses identified by SCO in response to IBM's interrogatories, including third-party witnesses, and "each of the persons from whom SCO has produced documents but didn't identify in its interrogatory responses."
I believe SCO will be sorry it ever asked for this material. This is what I meant the other day when I said that IBM has had it with SCO. If SCO causes them to be annoyed with endless discovery work, it will try to see to it that SCO suffers the same fate. IBM has neatly boomeranged SCO's whining to the judge back against them. Remember the IBM letter to SCO, saying OK, what day shall we each turn over all that you are asking for? And SCO writing back, Forget it. We'll go to the judge. They did and I'm sure they are sorry now. Because IBM has accomplished something else. It has provided the judge with a clear picture of the game afoot here. The last time the parties argued about discovery delays, it was in June before Judge Kimball, who wasn't there for most of the discovery story. Now, they are back before Judge Wells, and it isn't so hard for her to know who is being truthful about past events. To order SCO to produce all that IBM is requesting would not normally be something you'd expect a judge to do. But because SCO made such a fuss about demanding the same from IBM, and IBM turned over what they asked for, how can she now refuse? Even if she does, she will know now what she is dealing with here, if she doesn't already.
Footnote 15 is quite interesting too. Remember the order from Judge Wells about turning over witness declarations prior to depositions? IBM presents the judge here with some case law showing that such declarations are work product, not required to be produced in discovery. Now, while the judge is free to disagree with the cases, they show that IBM was not acting unreasonably in not turning over work product. No one can justly accuse IBM of failing to turn over the declaration, or "sandbagging" SCO, since they had a good faith basis for thinking they were not supposed to turn over that document, based on case law.
And then IBM says something particularly noteworthy, that "simply because a witness's testimony is unfavorable for SCO does not mean that SCO has been 'sandbagged'." The witness they were discussing, we know from the June hearing, was David Frasure, who was an AT&T employee with knowledge of the contracts. Presumably, he would be in a position to testify as to the intent of the parties signing the contract, particularly with respect to derivative works. I gather his testimony was favorable to IBM, not SCO, judging from this footnote.
Frasure was also deposed in the BSDi case, as you can see from a footnote in the linked-to BSDi Memorandum of Law filed in that case. It's a fascinating document, if only because of the wave of deja vu you will feel on reading it. Here is their description of what USL was up to back then:
"In short, with this motion, USL seeks to exclude a legitimate
competitor from the marketplace by attempting to invoke a
nonexistent copyright, by relying on commonly used industry
standards as evidence of copying, and by falsely claiming generally
known information as its trade secrets."
Eighth, from day one, SCO has not been impeded in any way from deposing whoever it wishes. IBM's contributors to Linux are publicly listed. Nothing blocked them from deposing those people, except perhaps their own desire to delay. Yet they have not deposed them, and now they would like a delay so they can. By the way, I collected SCO's discovery delays in this article, if you are curious.
Ninth, it's really SCO who is delaying discovery, IBM states. They still have not told us, despite two court orders to do so, what UNIX System V code Linux allegedly copies. They told this story to the media and even in the Red Hat court, but where is the specificity to back up the charge that SCO is aware of "significant instances of line-for-line and 'substantially similar' copying of code from System V into Linux? If they are aware of it, why don't they produce it in discovery here? For that matter, they haven't produced the reports of all those deep-diving MIT guys and the other two teams they told the world about and that IBM has asked them to produce in discovery.
Tenth, worse, SCO has been instructing third parties subpoenaed by IBM not to produce documents to IBM until after SCO can review them first, IBM alleges. And they told S2 Consulting to withhold documents subpoenaed by IBM, claiming attorney-client privilege and the work product immunity, which IBM believes is inappropriate, as well as causing delay. This, I am positive, we'll be hearing more about in the future.
And finally, to show how it is SCO delaying, not IBM, they remind the judge that it was SCO that moved to prevent depositions that had been set up a month earlier just three days before they were due to occur.
This current motion, IBM sums up, is more of the same. They just want to keep IBM busy gathering "unnecessary and irrelevant discovery" and delay some more. So for all these reasons, they ask that the motion be denied.