decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

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

To read comments to this article, go here
SCO's Reply Memo Supporting its Motion to Depose The Open Group et al - as text
Thursday, February 23 2006 @ 11:34 AM EST

Here's SCO's Reply Memorandum in Support of its Motion for Leave to Take Certain Prospective Depositions [PDF], as text, thanks to Laomedon. The motion is here. We haven't done the exhibits, which are all of SCO's tries at sending subpoenas to Intel, Oracle and the Open Group. That's why it's 73 pages long.

SCO makes the brash argument to the court that its defective subpoenas and notices were actually perfectly adequate for notice and that the three entities had a duty to either produce a witness or to file for a protective order from the defective subpoenas and notices. That's a new one. Anyway, they argue, the defects were later fixed, and the entities served should have been able to figure out that they were going to be deposed on January 27 by reading between the lines of the defective subpoenas and notices they received. What's a few technical defects between SCO and a third-party witness?

SCO claims it sent notices with topics for deposition to all three, and that is sort of true, but you can look at Exhibit A, the first subpoena to Intel, and it isn't attached. Ditto for the Open Group's, Exhibit B. No topics. Ditto for Oracle's, Exhibit C. No big deal, SCO argues, saying they faxed them the next day, and the entities acknowledge they got them. We haven't actually heard from the Open Group in any court, so you'll just have to take SCO's word for it, if that is your inclination. Another odd thing. Look at Exhibit D. The Certificate of Service on Intel, the first time they tried to serve them, says the notice with topics was served by mail, not by fax or fax and mail. And the next try has no certificate of service, Exhibit G. Neither does Open Group's 2nd, Exhibit H, or the repeats on Oracle, Exhibit I.

And if you read Oracle's Motion to Quash, you'll find that Oracle says SCO never did fix all the defects in that subpoena and notice, despite two tries. And Intel says SCO failed to follow local California rules to meet and confer and didn't send a subpoena along with the first faxed notice, and failed to send a notice or a list of topics for deposition when they sent the second try at serving a subpoena, and only after Intel explained all the defects did SCO send a third try, which cured the defects but gave Intel less than 24 hours to show up with documents, ready for deposition, so even if SCO were right that defective notices don't matter a whit, they still have uncorrected issues. Also, Intel argues that even if SCO had served Intel with a proper subpoena on its first attempt in mid-January, it would not have provided sufficient time to allow Intel to identify and prepare witnesses for deposition.

Oracle makes similar arguments:

A mere two weeks is not adequate time for any counsel to identify the witnesses who would be required to testify, prepare those witnesses, and also determine a host of other issues such as whether any testimony would breach any nondisclosure obligation or whether any testimony would constitute Oracle confidential information that Oracle might wish to seek to protect even given that a protective order may be in place in this action. That is especially true in because Oracle is not a party. Oracle cannot be expected to drop everything and in two weeks, prepare and produce what would likely be the several witnesses that would be necessary in order for Oracle to meet its Rule 30(b)(6) obligations. And needless to say SCO cannot possibly claim that it had no choice on the timing because of the discovery cutoff. SCO has had ample time to notice these depositions — two years, to be precise. SCO's tactics are not allowed under the Federal Rules.

It therefore seems unlikely that SCO's bold assertion that its failures should be shrugged off will fly.

SCO also disputes IBM's account of what happened at the telephone conference. Here's what Pacer notes say happened:

Docket Text: Minute Entry for proceedings held before Judge Brooke C. Wells : Telephone Conference held on 1/26/2006. The Court hears arguments as to depositions as rules as follows: The depositions of Otis Wilson and Ted Kennedy ONLY may be extended by 30 days (by 2/26/05). Counsel are to agree on the date and time. As to Mr. Wilson - he is not to be subjected to any questions other than reasonable inferences re: new information ONLY. As to the depositions of the three corporations addressed by SCO, the Court will not address this except via motion, which SCO may file.

Pacer notes are not always accurate. They are written by the court clerks, but the judge will remember what she said. Here's what SCO says they remember:

Second, as counsel for SCO recalls the teleconference, this Court did not rule that the three Rule 30(b)(6) depositions at issue could not go forward. Counsel for SCO explained that if the three corporations had been put on proper and sufficient notice of the depositions on January 27, they should have produced a witness on that date, and their failure to do so should not work to SCO's detriment. Counsel for SCO asked the Court for leave to file a submission to the Court on the issue, and the Court consented.

About the Open Group

I've been busy researching, of course, as we all have been here at Groklaw, particularly in regard to the Open Group, because SCO seems to be circling them in what appears to be preparation for an attack, and I think we've probably found enough already to undermine SCO's claims regarding The Open Group. But because SCO sealed its list of allegedly misused materials, and because I like to keep going until I find everything there is to find, I've continued to look around for more evidence.

The Open Group has a collection of documents that chronicle all its specifications, by the way, which you might enjoy looking through, if you would like to help. You'll find all their certifications programs here, listed on the left. Here's the Single UNIX Specification, version 3 page, which makes a good jumping off point for research.

I've been going through the records of Linux Standards Base Meetings, most particularly looking at the year 2001, because that is the year SCO is talking about. I started looking there because one of the things SCO listed on the Open Group's subpoena and notice, which you can find here, that it wanted to discuss was "The Open Group's policies and procedures for obtaining legal permission to obtain and use material from third parties in any standard." I've found some things I don't think SCO will like. The Open Group tells us this about the LSB:

The Linux Standard Base (LSB) certification program was developed and is operated by The Open Group on behalf of the Free Standards Group (FSG). The specification facilitates the creation of a standard application binary platform for Linux systems.

It turns out they kept detailed records of these meetings, who was in attendance and exactly what needed doing, who was assigned to do it, and to what degree the person followed through, and I see oldSCO, Santa Cruz, is in attendance regularly. I see a notice in 2001 that Caldera's Ralf Flaxa was supposed to get permission from oldSCO to publish ELF and gABI specs from them. See for example this page, where, in the list of tasks, under Ralf Flexa's name, there is this:

Ask SCO for documentation of ELF specs and to obtain permission to publish.

and under Doug B./David P. (standing for SCO's Doug Beattie, who was in attendance at this meeting, as was a representative from Caldera):

SCO to provide a gABI "final" spec with version number

Obviously, no one was trying to "steal" ELF or anyone's property in any way. Nor did either the oldSCO or the Caldera representative raise objections to the tasks as outlined or say that the specs could not be used for Linux. This whole meeting was about Linux, so listing two tasks, asking oldSCO for documentation of ELF specifications and permission to publish and for gABI specifications for Linux use is significant, in that oldSCO does not object at all.

Then in February, we find a link to this notation on Sourceforge, showing progress:

write draft spec: library/include naming
Ralf took the action item with help from Stuart. - 2001-02-27 12:43

At this March 13, 2001 meeting, both SCO and Caldera attended, as did the Open Group, and one item on the list was:

get new gABI from SCO

So, they continue to discuss getting the *new* gABI, and neither SCO nor Caldera says it isn't proper. At the same meeting, they discussed: Testing: Tasks

* Task 27918: ABI test suite using dev environ

* Task 27919: Wrap ABI tests

Again, both SCO and Caldera were there. If they had any objections, that would have been the time to raise the issue. On the contrary, we find them helping make it happen. In March, I see a note that they needed to get the new gABI from oldSCO:

17034 dbb spec Get new gABI from SCO [creating file for reference] 2001-03-19 80%
23709 flaxa spec wrapper library [Stuart provided lsbdev] [Ralf at Cebit]

The figure 80% means the task was almost complete. And then the issue is marked Closed as of a meeting on March 18, 2001 (note that the first part of the notes misspells Dave Prosser's name):

Dave Processor getting status on gABI from SCO...

I've just polled the business person owning this issue--I've got this as an action from the IA-64 "tools" group--and he sees no problem with rereleasing the current gABI with SCO copyright for appropriate use BUT still needs a few days to get "the I's dotted and the T's crossed".

Then getting it updated on SCO's web site will take a little while, but will not be an issue.

I don't see any problem with the LSB referencing the current gABI specification on SCO's web site until the time that it is updated. The changes between what's there and the current specification are fairly minor in comparison to the whole.

Start Date:
End Date:
Assigned To

The specific Dave Prosser discussion was about oldSCO giving explicit permission (regardless of whether it was actually required in a strict legal sense) for the gABI spec to be used as a reference/starting point/whatever for LSB.

However, at the same time the LSB group were defining the standard system library calls for Linux. For example, the poll() call is standardised by LSB, and its definition is taken (currently) from POSIX 2003.

The LSB process was completely transparent. So, suppose the LSB had attempted to specify a system call for Linux (I'll call it scocall()) that oldSCO or anyone else at the table wanted to claim rights over. As soon as it went into the draft, oldSCO could have cried foul. But nothing of that sort ever occurred. And remember, LSB was entirely about Linux, and we have seen the note saying that there was no problem with LSB referencing SCO's gABI. Note too that there didn't need to be a copyright transfer; all that was needed was oldSCO's license, or permission, and it was both sought and obtained.

How do we know permission was sincerely sought and obtained? Take a look at the next notes from March 23, 2001:

Dave Processor and Doug Baettie delivered on gABI. 2001-03-23 08:43 - gk4

Dan wrote:
> I think the problem is that they changed the value of USER_CS and
> USER_DS (the selectors used when running in 32-bit mode). We use these
> to switch from 16 to 32-bit code, and their value is hardcoded in the
> relay code at compile-time.
> So it will work as long as you also compile on a win4lin-patched
> kernel. But if you compile when running a normal kernel and run on the
> patched one, or the other way around, it will break.
> --
> Alexandre Julliard

Eeek. Does the LSB say anything about binary interoperability (I think it does) and if so, can it mandate values like those selectors? If not, we may have serious problems down the road in installing Wine executables as binary packages.

- Dan 2000-10-30 09:23 gk4
Dave Prosser status on gABI from SCO...

Apparently it's not quite so easy to get official use of the updated gABI as I thought. I've been asked to provide a list of those groups wishing to use/derive from/etc. the gABI specification including a contact.

We're still working out what it takes to get the recent updates to the gABI to show up on SCO's web site.

So, what I know of so far is that the IA-64 C++ ABI group and the LSB (Linux Standard Base) want it. Both groups wish (at least) to make reference to the specification and possibly to build off of it (as one might do for a psABI). As I find out about others, I'll let you know.

For the LSB, I've got two names:
Dan Quinlan
George Kraft IV

For the IA-64 C++ ABI group, the main contact I have is Jim Dehnert

If you need anything else, Steve, please let me know.
Dave Prosser (908)790-2358 Rm A332, SCO, Murray Hill, NJ

As you can see from the email address, Dave Prosser was an oldSCO employee, so he was tasked with getting oldSCO's permission. This notation says he did. In April, we find Caldera and oldSCO making the gABI available on their web sites, and you'll see that both oldSCO and Caldera were represented at the meeting where that was discussed and arranged for:

LSB Telephone Conference: 04/25/2001


* George Kraft, IBM
* Stuart Anderson, Metrolink
* Doug Beattie, SCO
* Kevin Caunt, IBM
* Dirk Hohndel, SuSE
* Scott McNeil, VA Linux
* Raymund Will, Caldera
* Matt Wilson, Red Hat

... Doug reports that there is a new gABI from SCO and that it will be moving to the Caldera web site.

Here's another tidbit for you from another meeting, in December of 2001, with Doug Beattie in attendance, then with Caldera, formerly with oldSCO, and a representative from the Open Group is there as well:

Task 27939, Stuart asked if someone could review the LSB's RPC and compare it to the SVID. We need to determine if we are missing anything.

The SystemV interface definition (SVID) is a different beast from POSIX. There are some bits and bobs in SVID that aren't in SUS. Nevertheless, SVID was being used as the model for specifying Linux's RPC. This was the perfect place for Doug to say "Sorry, we don't like you using anything from SVID that isn't in POSIX," but nothing like that occurred. Instead, we see them taking it that SVID was just another spec to be used as input to the LSB.

So, that is what the records say really happened. Oh, and while SCO failed to mention this to the court, SCO was a member of The Open Group up to at least March of 2005, as you can see on Wayback. And you can see how the Open Group works. It's a consensus process, one that both Caldera and oldSCO participated in with respect to LSB.

Another thing SCO lists it wanted from the Open Group was "Documents concerning the inclusion of the following header files in the Single UNIX Specification 2001: ... * statvfs.h "

Um. I have a theory as to why this header file was in the Single UNIX Specification 2001. I think it's because it was in the Single UNIX Specification in 1997. Look for yourself. It's right there. SCO just cracks me up sometimes. What SCO doesn't know about UNIX is a lot, which is certainly odd for a company claiming to be USL, Novell, and Santa Cruz. For that matter, they don't seem to even know what Caldera did, let alone Santa Cruz.

Let me help them out. The Open Group's authority with regard to specifications is explained on its web site thusly:

In 1994 Novell (who had acquired the UNIX systems business of AT&T/USL) decided to get out of that business. Rather than sell the business as a single entity, Novell transferred the rights to the UNIX trademark and the specification (that subsequently became the Single UNIX Specification) to The Open Group (at the time X/Open Company). Subsequently, it sold the source code and the product implementation (UNIXWARE) to SCO. The Open Group also owns the trademark UNIXWARE, transferred to them from SCO more recently.

Duh. Sometimes I reflect on how much trouble we've all had to go through in this very costly education of the SCO Group.


Brent O. Hatch (5715)
Mark F. James (5295)

Stuart H. Singer (admitted pro hac vice)

Robert Silver (admitted pro hac vice)
Edward Normand (admitted pro hac vice)

Stephen N. Zack (admitted pro hac vice)

Attorneys for The SCO Group, Inc.




Plaintiff/Counterclaim Defendant,






Case No. 2:03CV0294DAK
Honorable Dale A. Kimball
Magistrate Judge Brooke C. Wells

Pursuant to Rule 26 of the Federal Rules of Civil Procedure, Plaintiff The SCO Group, Incorporated ("SCO"), requests the Court to grant SCO leave to take certain prospective depositions of Intel Corporation ("Intel"); The Open Group, Incorporated ("The Open Group"); and Oracle Corporation ("Oracle"). SCO submits this Memorandum


further to its same-styled Motion dated January 27, 2006, and in reply to Nonparty Intel's Response to SCO's Motion for Leave To Take Certain Prospective Depositions.


SCO now asks this Court for leave to take the Rule 30(b)(6) depositions of Intel, The Open Group, and Oracle (collectively, the "corporations") for the reasons set forth below. The topics of the Rule 30(b)(6) depositions that SCO seeks to take of the corporations relate directly to SCO's claims in this litigation.

SCO developed the following information primarily as a result of substantial discovery taken of IBM. Accordingly, toward the end of its period of fact discovery (ending on January 27), SCO issued and served on January 12 subpoenas on Intel, The Open Group, and Oracle for deposition on January 27. (Exhs. A, B, C.) SCO also faxed to each of the corporations on January 13 a notice of Rule 30(b)(6) deposition that included the list of deposition topics. (Exhs. D, E, F.) Each corporation acknowledges that it received the list of topics at that time, thereby placing it on notice - fourteen days before the proposed deposition date of January 27 - that SCO intended to question a representative or representatives of the corporation on those topics on that date.

After sending the subpoenas and notices, counsel for SCO informed the corporations of counsel's willingness to discuss the nature and scope of the subpoena and deposition topics, and counsel's expectation that each corporation would file a motion for protective order if it did not intend to produce a witness. In the interim, considering certain technical defects in the subpoena and notice, SCO served a corrected subpoena on each corporation on January 26 with the same deposition and document-return date as the earlier


subpoena and notice. (Exhs. G, H, I.)1 The corporations declined to produce any witness on January 27. While Oracle timely filed a motion for protective order in the Northern District of California,2 neither The Open Group nor Intel produced a witness on January 27 or filed any motion for a protective order or to quash by that date.

SCO presents the following arguments to this Court in the interests of efficiency. SCO has spoken with counsel for or a representative of each of the three corporations regarding the scope of the proposed Rule 30(b)(6) topics. SCO respectfully submits that before seeking to reach an agreement (if possible) with the corporations regarding the precise scope of the topics at issue, SCO should first seek from this Court the right to take any such depositions at this time.

A. Intel

The discovery sought from Intel is directly related to resolution of the claims at issue in the instant case. The discovery seeks information about code and specifications copied from SCO's UnixWare by IBM and The Open Group for use in Linux. The requested discovery largely relates to specific items identified in SCO's Disclosure of Material Misused by IBM, filed with the Court on December 22, 2005 ("SCO's Dec. 22 Disclosure")





Intel representatives participated significantly in this Open Group committee and therefore discovery from Intel is material and necessary to discover issues related to: (a) this disclosure of SCO's copyrighted materials; (b) its intended use in and for Linux; and (c) the bases, if any, upon which The Open Group and its committee members contend that a copy assignment exists from SCO for use of this interface in The Open Group's specifications.

On numerous occasions, IBM has represented to this Court that no UnixWare or System V code has been copied into Linux. As demonstrated by SCO's Dec. 22 Disclosure, those representations are simply untrue. Because of Intel's involvement in the process resulting in the


copying of SCO's code into Linux, SCO is entitled to discover from Intel its knowledge of any such instances of unauthorized copying.

B.The Open Group

SCO alleges (among other things) that IBM has breached its UNIX software agreements by publicly disclosing, via contributions to the "open source" UNIX-derivative operating system called "Linux," numerous technologies that IBM was obligated to hold in confidence for SCO. SCO also alleges (among other things) that IBM misappropriated SCO's UNIX technology and engaged in unfair competition in connection with a joint project between IBM and SCO from 1998 to 2001 called "Project Monterey." IBM entered into Project Monterey to create a joint 64- bit operating system with SCO, and to help SCO expand its market share in the 32-bit operating system market for UNIX on the Intel microprocessor architecture ("UNIX-on-Intel"). During the Project (and without full disclosure to SCO), IBM shifted its focus and resources toward developing the Linux operating system to replace the SCO operating system as the preferred UNIX-on-Intel alternative, and used SCO's code and proprietary specifications to build up the Linux alternative.

In connection with its shift in focus and resources, IBM sought to make Linux a UNIX- on-Intel operating system capable of commercial use. To that end, IBM enlisted the help of The Open Group. By its own description (, The Open Group is a consortium that (among other things) has sought to develop common, "open" standards and specifications to enable multiple sectors of the information-technology community to use so-called "open-source" software -- referring to the general practices in production and development which promote access to the end-product's sources. "Open source" software, for example, refers to computer software and the general availability of its source code (as under an open source license) to


study, change, and improve its design. Among the members of The Open Group are Fujitsu, Hitachi, Hewlett-Packard, NEC, Sun Microsystems, and IBM.

Seeking to make Linux a viable, commercial-ready UNIX-on-Intel alternative, IBM misappropriated UNIX technology from SCO and provided that technology to The Open Group for purposes of The Open Group's "Single UNIX Specification 2001" and The Open Group's efforts to work on "UNIX Developer Guide - Programming Interface" (or "UDG-PI"). The Single UNIX Specification 2001 was the update on the collective name of the family of standards that an operating system must meet to qualify for the name "UNIX" (where The Open Group owns the trademark to that name). The UDG-PI are guidelines that software developers and system manufacturers needed to create UNIX interoperability with Intel-based processors, and were intended solely for use in support of Project Monterey, and were not intended for use in support of Linux. The Open Group participated with IBM to use SCO's protected source code and specifications to create an open standard for support of Linux-on-Intel processors, with the knowledge and intent that the Linux product would replace SCO's UnixWare product as the market leader in the UNIX-on-Intel market. IBM hired the key programmer at The Open Group, Andrew Josey, under a secret work-for-hire agreement with IBM to accomplish this work, using SCO's code and specifications, to launch Linux ahead of UnixWare in the marketplace.

C. Oracle

The discovery sought from Oracle involves actions taken by Oracle against SCO that, if induced by IBM, demonstrate a prima facie case of interference by IBM with SCO's business relationship with Oracle. Oracle is a software company that develops and sells the leading database software products used by medium-sized and large corporations. Oracle's database products are in high demand. Database products must be configured to operate on particular


operating systems. After a particular Oracle product release is so configured and released for sale to customers, Oracle issues a public "certification" that its new product will operate on particular operating systems. If Oracle refuses to certify its product for a particular operating system, customers have a disincentive to continue use of that operating system product, and have an incentive to switch to a new operating system product to continue using the latest versions of Oracle's database products. Thus, it is important for an operating system company such as SCO to receive an Oracle certification for new Oracle product releases.

Until recently, Oracle had certified every major version of its Oracle database software releases for use on SCO's OpenServer UNIX operating system and SCO's UnixWare operating system. After SCO filed this lawsuit against IBM, however, Oracle stopped issuing certifications for SCO's operating system products and has not certified a single release by SCO since March 2003. SCO contends that this action by Oracle has been induced, in material part, by IBM. SCO needs and is entitled to discovery on this issue.


On January 12, 13, and 26, 2006, SCO served Rule 30(b)(6) subpoenas and notices (as well as document requests) on each of the foregoing corporations for depositions scheduled for January 27, 2006. (Exhs. A-I.) The operative subpoenas and notices were those dated January 12 and 13; the January 26 subpoenas and notices simply corrected technical defects in the earlier subpoenas and notices.

As SCO explained in its January 27 Memorandum and had previously explained to this Court by teleconference, SCO submits that it would be entitled to take the foregoing Rule 30(b)(6) depositions at this time to the extent that (1) the January 12 and 13 subpoenas and notices, although containing certain technical defects nevertheless operated


to require the corporations either to produce a Rule 30(b)(6) witness or to file a motion for protective order; and (2) the January 12 and 13 subpoenas and notices gave the corporations adequate notice of the January 27 deposition date (so that even if a corporation did file a motion for protective order, SCO had nevertheless given the corporation sufficient time to warrant the noticed deposition on January 27).

First, the January 12 and 13 subpoenas and notices provided the corporations with actual and proper notice of the January 27 deposition date and of the topics at issue. See, e.g., Sandstead Fin. Consultants Ltd. v. Fed. Home Loan Bank Bd., 878 F.2d 875, 882 (5th Cir. 1988) (subpoena improperly served to principals of a corporation nonetheless provided corporation with "actual notice of the subpoena" and was enforceable); Kupritz v. Savannah Coll. of Art & Design, 155 F.R.D. 84, 88 (E.D. Pa. 1994) (subpoena issued from incorrect court provided third party with adequate prior notice of scheduled deposition). Indeed, having decided not to produce a Rule 30(b)(6) witness, Oracle filed a motion for a protective order in the District of Northern California on January 26 - the day before the noticed January 27 date.

Second, the fourteen (14) days of notice that SCO provided to the Open Group was reasonable. See 8A C. Wright, A. Miller & R. Marcus, Federal Practice & Procedure § 2111 (2005); Pearl v. Keystone Consol. Indus., Inc. 884 F.2d 1047, 1052 (7th Cir. 1989) (six days' notice of deposition of defendant's general sales manager was reasonable); FAA v. Landy, 705 F.2d 624, 634-35 (2d Cir. 1983) (four days' notice of deposition of third party reasonable); Jones v. United States, 720 F. Supp. 355, 366 (S.D.N.Y. 1989) (eight days' notice of third-party deposition reasonable); see also Davidson v. Dean, 204 F.R.D. 251, 256 (S.D.N.Y. 2001) (eight days' notice of plaintiff reasonable); C & F Packing Co. v.


Doskocil Companies, Inc., 126 F.R.D. 662, 680-81 (N.D. Ill. 1989) (order requiring seven calendar days' notice of third-party depositions was reasonable).3

SCO further submits that none of the grounds that IBM offers to preclude the depositions at issue is correct. First, counsel for SCO never remotely forfeited SCO's right to pursue depositions for which deponents were obligated to appear by January 27. The agreement was that SCO would not argue that by producing certain witnesses for deposition after January 27 IBM had somehow conceded that there was no discovery cut-off. There was no agreement among counsel on the issue here - namely, whether SCO is entitled to take depositions that were properly noticed for January 27 but did not take place.

Second, as counsel for SCO recalls the teleconference, this Court did not rule that the three Rule 30(b)(6) depositions at issue could not go forward. Counsel for SCO explained that if the three corporations had been put on proper and sufficient notice of the depositions on January 27, they should have produced a witness on that date, and their failure to do so should not work to SCO's detriment. Counsel for SCO asked the Court for leave to file a submission to the Court on the issue, and the Court consented.


Third, IBM's newly disclosed reliance on the Court's Order regarding the January 27 cut-off is unreasonable. IBM now interprets the Order as a shield to preclude SCO from deposing even those deponents who were properly noticed but did not appear for deposition by January 27. Indeed, IBM now takes the extraordinary position that SCO is not even permitted to depose those Rule 30(b)(6) witness who were indisputably properly noticed for deposition by that date but whom IBM did not adequately prepare for their depositions. SCO submits that in the Order the Court did not intend, as IBM would have it, to modify the Federal Rules of Civil Procedure to preclude SCO from taking depositions properly noticed before the discovery cut-off.

Fourth, IBM argues that there were no subpoenas served on these third parties prior to January 26 (it is unclear if IBM means that literally or figuratively), but the foregoing case law demonstrates that the mid-January subpoenas and notices served to put these third parties on notice.

DATED this 14th day of February, 2006.

Respectfully submitted,
Brent O. Hatch
Mark F. James
Robert Silver
Stuart H. Singer
Stephen N. Zack
Edward Normand

By [Signature]
Counsel for The SCO Group, Inc.


1The corporations collectively asserted as technical defects that the subpoenas did not include a witness fee; that although The Open Group notice included the topics for the deposition, the subpoena did not; that although the subpoenas specified the location of the deposition within a permissible area, the notices did not, and that although The Open Group subpoena had been served, the notice had been faxed.

2The Northern District of California subsequently set a schedule for briefing on Oracle's motion (without a hearing date), but counsel for SCO and counsel for Oracle have agreed to adjourn the briefing schedule pending this Court's resolution of SCO's instant request for relief.

3In its opposition brief, IBM cites In Re Sulfuric Acid Antitrust Litig., 231 F.R.D. 320 (N.D. Ill. 2005), for the proposition that ten days' notice of a deposition can be insufficient under certain circumstances. In Re Sulfuric Acid was a "multi-district, antitrust case," id. at 322, in which the plaintiffs attempted to depose two Canadian witnesses at plaintiff's counsel's offices in Chicago. The Court found that while normally "ten business days' notice would seem reasonable," id. at 327, the "analysis is necessarily case-specific and fact-intensive." Id. Specifically citing the travel concerns of the witnesses and their attorneys, the court found "in the context of this case, the notices were not reasonable." Id. at 327-28. The context of this case is markedly different. SCO has noticed each of the depositions in a location near the corporate deponents' headquarters and thus foreclosed any travel concerns. Because it cannot, IBM does cited any case finding notice was insufficient under circumstances similar to those present in this case.


Plaintiff, The SCO Group, Inc., hereby certifies that a true and correct copy of the foregoing redacted version of SCO's Reply Memorandum in Support of Its Motion for Leave to Take Certain Prospective Depositions was served by U.S. Mail on Defendant International Business Machines Corporation on the 17th day of February, 2006:

David Marriott, Esq.
Cravath, Swaine & Moore LLP

Todd Shaughnessy, Esq.
Snell & Wilmer LLP

Donald J. Rosenberg, Esq.



  View Printable Version

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 )