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
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:
* 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.
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
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 firstname.lastname@example.org 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 email@example.com
George Kraft IV firstname.lastname@example.org
For the IA-64 C++ ABI group, the main contact I have is
Jim Dehnert email@example.com
If you need anything else, Steve, please let me know.
Dave Prosser firstname.lastname@example.org (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.
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
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)
HATCH, JAMES & DODGE
Stuart H. Singer (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
Robert Silver (admitted pro hac vice)
Edward Normand (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
Stephen N. Zack (admitted pro hac vice)
BOIES, SCHILLER & FLEXNER LLP
Attorneys for The SCO Group, Inc.
IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF UTAH
THE SCO GROUP, INC.
SCO'S REPLY MEMORANDUM IN
SUPPORT OF ITS MOTION FOR
LEAVE TO TAKE CERTAIN
FILED IN REDACTED FORM
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.
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
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 (www.opengroup.org), 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.
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.
HATCH, JAMES & DODGE, P.C.
Brent O. Hatch
Mark F. James
BOIES, SCHILLER & FLEXNER LLP
Stuart H. Singer
Stephen N. Zack
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.
CERTIFICATE OF SERVICE
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.