These are the two where SCO asks for identical relief from both Judge Wells and Judge Kimball simultaneously, so IBM handles them both singly and together, at one point telling Judge Wells to read their arguments made to Kimball. Let's start with the opposition to the Motion to Compel Discovery. This is the one Wells has to rule on.

Opposition to SCO's Motion to Compel Discovery

IBM argues in the Opposition to the Motion to Compel Discovery that SCO just didn't like Judge Wells' October 7 hearing ruling (later memorialized in the October 12th Order), so it is, in essence, asking Wells for a reconsideration of her Order while at the same time it is appealing the Order to Judge Kimball. You have two courts considering the same thing at the same time, with the possibility of conflicting decisions, which leads to "the inevitable review of the issue by Judge Kimball" and that means delay. So they say the motion should be denied.

What do they mean that it would lead to delay? I'll try to explain. Let's say Wells grants their reconsideration motion, and she then alters her Order. She will state on what grounds she did so. Then let's say Kimball simultaneously in the district court rules on SCO's appeal (the Objection), and he gives his reasons. Let's say they don't match. Now what? Obviously the new Wells Order would then be appealed by IBM or somebody, and it ends up on Judge Kimball's desk, whereupon he has to consider the identical issue, all over again. Meanwhile, tempus fugit. Or more exactly, tempus stops fugiting, and SCO gets yet another delay.

SCO doesn't call this a request for reconsideration, but that is what it really is, IBM says, and the rules to ask for reconsideration are that SCO would need to have identified some clear error of law or fact on Judge Wells' part, some mistake, and there aren't any. The implication is that SCO is trying to bypass the rules. No! SCO? You think they'd do such a thing? They call their document a Motion to Compel Discovery, instead of a request for reconsideration, so as to squeeze past the rules for reconsideration, which they can't meet, because there was no clear error. Wells didn't fail to rule on SCO's motion. She listened to their considerable arguments, considered them, and told them no. She decided to limit the Linux discovery they get to do to the 20 developers IBM volunteered at the hearing to provide. So any request for reconsideration is unsupported and unsupportable.

Furthermore, at the hearing she announced her ruling and then asked the parties if there was anything else of a substantive nature she needed to address, and SCO said no. Later, SCO had another opportunity to raise this issue, and again there was no peep out of them at the time. What happened was this: IBM won the hearing, so they got to draw up the order. That's typical. The party that wins the motion usually draws up the order, but they don't do so without sending it to the other side to get them to sign off that the wording is correct. If there is a dispute about it, the parties take it to the judge to decide. SCO was sent the Order by IBM to approve as to form, and they argued over some wording in the Order. The parties couldn't work it out, so they had a telephone conference with Judge Wells, IBM tells us. That wording dispute was resolved in IBM's favor. On that occasion, SCO didn't raise any issue about the judge failing to consider one of SCO's arguments in her Order, and that would have been an ideal time.

This argument might not sound like much to you, if you are not a judge, but to the judge it is significant, because a party can lose certain legal rights if it lets chances to assert those rights go by. There are certain defenses, for example, that you have to raise the first time you speak, or you lose the chance forever more. There's a reason for this. It is supposed to prevent litigants from being blindsided by 11th hour Hail Mary passes. There is supposed to be an orderly progression toward resolution of a case, believe it or not, so sometimes doors slam on you, if you don't walk through them when you are first given the chance. This isn't exactly like that here, because there isn't a rule but just a principle, but it's one the judge will certainly note. Why didn't SCO raise this issue before on either occasion, if it is really so vital? This is our first hint that IBM is arguing, under all the words, that SCO is not really seeking the relief it states; what it really wants, they say, isn't Linux development materials. What it wants is more delay, and this is all just an excuse to get some. They want to put off their looming Doomsday by dragging out discovery past the fast-approaching final day for discovery to end.

This train has left the station, IBM argues, and they're just cunningly trying to find a novel way to get the same matter heard again while simultaneously appealing an order they don't like to Judge Kimball.

But, IBM states, even if they get their new Motion to Compel Discovery heard, IBM would like to underline that SCO is not raising any issue with regard to Judge Wells' order on the following points:

1) that IBM did not previously agree to produce all documents relating to the development of Linux;

2) that the Court did not agree to order IBM to produce such documents;

3) that IBM appropriately interpreted the Court's previous Orders; and

4) that SCO's interpretation of those prior Orders takes the clear language of the Orders out of context.

Wells considered SCO's arguments carefully and properly denied their motion because the request for more Linux development documents is contrary to the Court's discovery protocol, it's unnecessary and irrelevant, it would impose an undue burden on IBM, and it would delay the resolution of this case.

Opposition to SCO's Objection to Judge Wells' Order of October 12, 2005

IBM at this point incorporates by reference all the arguments in their Memorandum in Opposition to SCO's Objection to Judge Wells' Order of October 12, 2005. This is the appeal to Kimball. When they say they incorporate by reference they mean every word in it is part of the Memorandum in Opposition to the Motion to Compel too, but IBM doesn't have to type it up again for Judge Wells. She can just read it in the document for Judge Kimball. The same points are made separately, of course, to Judge Kimball, who will be going by the second document alone, although you'll note some duplication, and the points made are the following:

1. An order of a magistrate judge in a pretrial matter can only be set aside by the district court to the extent it is "clearly erroneous or contrary to law." Wells made no such mistakes.

2. The litigant who seeks to overturn such an order bears a heavy burden.

3. Judge Wells carefully considered SCO's motion. SCO asked that IBM be required to turn over documents about Linux development from the files of every developer in the Linux Technology Center. IBM opposed on the grounds that it violated the Court's discovery protocol -- and may I just say that whoever at IBM remembered to bring this up should be, in my opinion, given a bonus or at least a steak and champagne dinner -- and that the information was unnecessary and irrelevant, that it would result in undue burden on IBM, and it would cause delay. IBM offered the 20 just to seek an end to the dispute. Wells then deliberated and ruled and told SCO no, they couldn't get anything further except for the 20 IBM had offered. IBM then repeats also the points about the two opportunities they had to object. And it adds a telling point: if Judge Wells had failed to consider SCO's arguments, she would not have drawn the line at 20 additional developers.

4. Even if Judge Wells had failed to rule on SCO's argument, which she didn't, IBM goes on, she didn't rule in a vacuum. She ruled after the parties briefed and addressed SCO's arguments at a hearing. Then they quote from a ruling that says that "a district court's failure to address [a litigant's] arguments may be properly construed as an implicit denial of those arguments". Someone did some legal research to find that case, Hill v. SmithKline Beecham Corp. It's right on point. They're saying that even if SCO were correct that Judge Wells failed to mention one argument in her order, her silence automatically means the argument is denied.

5. Furthermore, SCO has had tons of info about Linux available to them from the time they filed this case. It's almost all public. As for any non-public materials, IBM handed over substantial amounts of information about the development of Linux. IBM has never argued that SCO should be denied all Linux information. The only question is whether they are entitled to make IBM search through the files of every single developer in the LTC. Wells said no for good reasons, and here are some good reasons that IBM presented that she considered in making her decision:

A. It's irrelevant and unnecessary. They have what they need to prove their case, if they even have one. Linux is developed in public view. So the development history, including proposed patches and comments, are available to SCO already. AIX and Dynix are in contrast developed confidentially. IBM turned over all non-public Linux contribution information. In fact, they already provided documents from a higher proportion of Linux developers than AIX and Dynix developers IBM was ordered to provide documents for. The court ordered IBM to turn over documents from the files of 100 of the latter when there are 7,000 developers of AIX and Dynix, or less than 2%. IBM has about 328 present or former employees who contributed to Linux, and IBM has turned over documents on 55 or has agreed to. That's 16%. It's not inconsiderable. And it's more than enough to enable SCO to evaluate the validity of its claims. The elaboration of the math is, I think, IBM showing some awareness that the judge might be tempted to just say yes to the perpetual whine of SCO on this one point.

SCO is again making an overbroad request, IBM says, and in footnote 5 IBM reminds the court of some of the silly and overbroad requests they already tried to make, such as asking for Linus Torvalds' "knowledge about the contributors and contributions to Linux since its inception, and the maintenance of any records about the development history of Linux." Can you imagine? Linus would be working on that request for years, I'd think, because he probably knows quite a lot about the contributors, including the names of some of their wives, what they kind of beer they like to drink at conferences, what they told him about their childhood after having a few beers, etc. I'm kidding a bit, but when you ask for all knowledge Linus has about contributors, that is the sort of thing he might have knowledge of. SCO didn't need all that to develop its case, yet SCO said it needed it all. IBM is saying to the judge: remember who it is who is claiming a need here.

B. What SCO needs, to prove its case, to establish copyright infringement, is to compare the source code IBM contributed to Linux to actual UNIX source code, and prove a substantial similarity. As for proving SCO's contract case, SCO is claiming IBM's contribution of any AIX and Dynix code is a breach of contract. So all they need for that is the AIX and Dynix code, which IBM already gave them and IBM's actual contributions to Linux, which are all public or have been handed over already. The development history isn't needed to prove the breach of contract. Either there is code in common or there isn't, and since *any* contribution, under SCO's "misguided contract theory," as IBM puts it, would be enough for them to state their case, there really is no need for development materials that never made it into Linux anyway or memos or whatever. All they need is the code, and they have it. As for SCO alleging that IBM acknowledged the relevance of what they are asking for when they volunteered to hand over papers from the 20 developers, IBM says in footnote 7 that SCO isn't being accurate, to put it politely. IBM's David Marriott just before making the offer explicitly said, "We really do believe these materials are irrelevant."

C. It would be a burden on IBM to make such a search. Linux isn't kept in any central repository inside IBM. It just isn't. It's developed over the Internet, in public view. And IBM's Linux people are in 9 different countries on four continents. Here IBM is showing the court what would be involved for the lawyers to make the search. IBM has never forgotten, I don't think, that Wells acknowledged when she granted IBM's request for reconsideration, that she had issued her order without fully understanding all that would be involved in obeying it. So I notice that since then, IBM spells everything out very clearly for her, to make sure she knows just what hoops SCO is asking IBM to have to jump through.

IBM can't just ask the guys to look in their files, as SCO has asserted. The lawyers have to be involved, and that means all the documents would have to be sent to the lawyers, who'd have to copy and then return them, and then figure out what can be turned over. Some of the people are no longer employees, so it would mean finding their last known manager to try to find any documents the manager still has.

To put it into perspective, SCO has so far produced documents from 65 people and IBM from 231. If IBM has to go through and produce documents from 328 developers, it's more than the two sides have produced in the entire case so far combined. And they'd have to do it in a couple of months instead of the nearly three years that have transpired in the case.

Good grief. Has it been that long? And some pretend to wonder that Groklaw has a point of view? How could we not, after watching this every day for nearly 3 years?

IBM would have to identify the various IBM servers where each of the developers maintains his or her project work. To do that, they'd need to interview all the individual managers, team leads, support staff and all programmers for each of more than 100 projects since 1999. To make sure Judge Wells realizes fully the magnitude of the task, IBM spells it out: it would be an estimated million pages and more of documents. After they collect all that, then they need to review it all for privilege and 3rd-party confidentiality. It's the critical final stage of discovery, and IBM has a full deposition schedule, as SCO knows only too well, and requiring them to set off on this fishing expedition would be time consuming and onerous and distracting.

D. Delay. Inevitable delay, if SCO gets what it seeks. Fact discovery is supposed to end on January 27, 2006. That's about 2 months away. If IBM has to produce another million plus documents, the time for discovery will undoubtedly have run out, because, for one thing, after IBM turns them over after review, who knows how many motions SCO will feel it wishes to file about these "irrelevant and unnecessary documents". Go ahead. Try to argue SCO would never do such a thing. Delay is inevitable, IBM says. Anyway, that's the whole point, they think. SCO waiting to ask for this points to a desire to delay resolution of the case, IBM states. If SCO really thought the Linux info was the core of its case and vital to obtain, why didn't it move to compel for it when it fought like a pitbull for the AIX and Dynix materials in May of 2004? "If this motion was truly about discovery SCO needs to prove its claims -- and not simply delay at any cost -- SCO would have raised it more than a year ago," IBM concludes.

For all those reasons, IBM tells both Judges Wells and Kimball that SCO motions should be denied.

IBM attaches the Judge Wells October 12, 2005 Order as an exhibit to its Memorandum in Opposition to SCO's Objection to Judge Wells' Order of October 12, 2005. This is for Judge Kimball's convenience. They don't need to add it to their Memorandum that goes to Wells, because she knows what she ordered already, as she ably demonstrated at the last hearing.

IBM is letting the courts know that it believes this is nothing but a nuisance request by SCO, and a delaying tactic, and they hope the courts won't be sucked into it as if it were about a legitimate need for discovery.