decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
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
The Transcript of Oral Arguments Friday, Dec. 5, 2003 SCO v. IBM
Thursday, December 11 2003 @ 11:53 PM EST

Here is the completed transcript as text of Friday's oral arguments in the SCO v. IBM lawsuit. You can get the PDF here. The most surprising statement is one by Kevin McBride, which I would never believe he had said if I were not reading it with my own eyes:

"The -- what we need to get our arms around collectively, on our side and on IBM's side, is a clear definition of what source code is at issue, what source code is potentially an infringement."

The only appropriate response to that is, "Amen, brother."

**************************************************
Salt Lake City, Utah, Friday, December 5, 2003, 10:00 a.m.
(Proceedings)

THE COURT: Good morning, ladies and gentlemen.

MR. MARRIOTT: Good morning, Your Honor.

THE COURT: Let's go forward in the matter of the SCO Group versus
International Business Machines Corporation. The record should reflect that
plaintiff SCO is represented today by Mr. Brent Hatch and Mr. Kevin
McBride. Defendant IBM is represented at counsel table by Mr. David
Marriott and Mr. Todd Shaughnessy.

Gentlemen, let me indicate, as we begin, that I have reviewed your
submissions, I have reviewed what I believe to be the pertinent case law in
this matter and I have reviewed the affidavit that was submitted by Mr.
Shaughnessy. And I've also taken note of the statements that are included
in the submissions which indicate that certain representations have been
made by SCO to the media.

Based upon my review of those items, I would tell you what my intention is
today so that we can then focus the argument towards that particular end.
As I've stated, and based upon my review of those items mentioned, it would
be my intention to grant defendant IBM's motion to compel answers as to both
sets of interrogatories, and to require plaintiff SCO to file responses to
these interrogatories or affidavits indicating that they are unable to do so
and why within 30 days of the entry of this order. I would further intend
on directing that IBM's responses should correct those deficiencies that are
set forth in the defendant's addendum which was filed on 11-4 of this year,
and that is to include answers to Interrogatories No. 12 and 13. Now, in
the interim, it would also be my intention to otherwise postpone all other
discovery until such filings have been and compliance has been achieved.

Let me ask counsel first, is there a protective order in place?

MR. MARRIOTT: There is a protective order.

MR. MCBRIDE: Yes, Your Honor.

THE COURT: All right, that answers that question then. All right, given
that as my intended plan today, then I would ask counsel to focus your
arguments as to why or why not I should not implement that plan.

MR. MCBRIDE: Would you prefer that I go first, Your Honor?

THE COURT: Well, we --

MR. MCBRIDE: Mr. Marriott's pretty much got the day so far, it would
appear.

THE COURT: It's up to you, counsel. You both have matters. Maybe, Mr.
McBride, it does make some sense for you to go forward.

MR. MARRIOTT: That's acceptable, Your Honor.

THE COURT: All right.

MR. MCBRIDE: Thank you, Your Honor. Frankly, we can appreciate the
intention of the Court based on the submissions and understand the basis for
it. We think, Your Honor, however, that in a few minutes this morning we
can convince you that the more appropriate path is to follow a rule or an
outline of the rule in Rule 33 that basically says that because the issues
involved in this discovery involve a complex interplay between facts and
law, that instead of granting the motion, what the Court should simply do is
put the motion on hold until very specific discovery has been identified and
produced and then make a ruling. And before I address this -- yes, Your
Honor?

THE COURT: No. What I was going to say, Mr. McBride, is that in reviewing
all the submissions and reviewing the pertinent case law, it appears to me
that what is happening is somewhat circular in that defendant indicates that
it cannot answer plaintiff's interrogatories until plaintiff has identified
the source codes, et cetera, but the manner in which those have been
submitted make it, I believe, unduly burdensome on the defendants and so we
go 'round and 'round. And I find also that it appears to me that if there's
any argument to be made on the failure to confer under Rule 37 that -- that
there has been a good faith effort to comply, but that because we can't get
off the ground because of this circular problem, that I would not find that
a sufficient basis for, you know, further postponing.

MR. MCBRIDE: May I have a few minutes to try to convince you otherwise,
Your Honor?

THE COURT: Absolutely.

MR. MCBRIDE: All right. And I simply set this out at the beginning because
this is what I think we can convince you of in a few minutes this morning.
And what I think we can convince you of is that rather than entering an
order, what really should happen is specified discovery should be
identified, we should have time to take that discovery, then we should
revisit this and respond more fully to the interrogatories submitted by IBM.
Now, I would like to explain why.

This case, Your Honor, at a very fundamental level, involves infringement.
Infringement is a very broadly defined category in the law. It can include
copyright infringement, trade secrets infringement or plain old confidential
information that's taken without permission. Those are all very differently
defined areas of the law that all have very differently defined rules of
proof. The -- what we need to get our arms around collectively, on our side
and on IBM's side, is a clear definition of what source code is at issue,
what source code is potentially an infringement. Before we discuss whether
it's a trade secret or a copyright or anything else, the most important
thing is for both of us to come to grips with the universe of source code,
the documentation and methods and concepts that we believe are at issue so
we can argue about them. And once we have an understanding of what that
universe is, the very complex rules -- this is a complex case, Your Honor.
There's going to be some of this code and some of these methods that are
trade secrets, and some are going to be copyright and some are going to be
contract violations and some are going to be nothing. I submit, Your Honor,
that's the very first step that needs to take place before we start worrying
about whether there is trade secret burdens met or not met.

Certainly, Your Honor, the cases cited by the defendant in this case with
respect to trade secrets and the need to make some affirmative
representation of what those are, that makes complete sense. We have no
argument with that general proposition of law. What we are simply saying is
this case involves deeper level complexities than the cases cited by the
defendant. This is not the Muna case. This is not a case where we're
talking about identity of employee records or customer records that you
would normally see in a trade secrets case. This involves an
interrelationship between, as I said, copyright, trademark and contract law.

Now, Your Honor, I would like to proffer a case for the Court's review that
is a pretty well known case but it's not in our briefs. It is Sun against
Microsoft
, a Ninth Circuit case decided in 1999, and the reason -- would it
be appropriate to. . .

THE COURT: Certainly.

MR. MCBRIDE: The reason --

THE COURT: Excuse me, Mr. McBride.

MR. MCBRIDE: Yes.

THE COURT: Do you have an extra copy of that?

MR. MCBRIDE: Oh, sorry, Your Honor.

THE COURT: Hand it to Mr. Willey. He's the brains behind this operation.

MR. MCBRIDE: The reason this is an interesting case is because it
underscores the point that I just made to the Court. The -- there are some
paragraphs here worth reading, but the -- and I'll get to those in just a
moment. The case in Sun against Microsoft involved claims of
misappropriation of derivative works. A derivative work is a work that was
licensed from one party to another party, and then the other party made some
improvements to it. In copyright law that's a derivative work. And in the
Sun against Microsoft case, Sun licensed Microsoft its Java technology,
Microsoft made a bunch of changes to it, which is derivative work, and then
there was an argument about how that should be used.

The reason this is an important case and an interesting case is the Court
goes right to the issue of -- that we are -- this particular case is in the
intersection between contract law and copyright law that is a frontier,
literally, of judicial interpretation. Even for the Ninth Circuit in 1999,
this was deemed a case of first impression insofar as identifying the
interrelationship between contracts and copyrights. That -- and the
language in this case, for example, if I could turn the Court's attention to
page 5. It's not 5 in the case. It's five on the printed page up in the
upper right-hand corner. I simply would like to read a little language to
underscore the points just made. In the bottom left-hand corner, the Ninth
Circuit, upon review of the issues, says, in affect, five lines up from the
bottom of the page, We agree with Microsoft that the issue turns upon
whether the terms Microsoft allegedly breached were limitations on scope of
the license, which would mean there is copyright infringement by acting
outside the scope, or whether the terms were merely separate contract
covenants, which would make this a contract dispute.

Now, the Court -- the Ninth Circuit goes on, and I'll ask the Court to
kindly turn to page 6, the following page, for additional highlighting. The
bottom right-hand corner at the very -- at the top of the sentence, the Ninth
Circuit continues to explain, Whether this is a copyright or a contract case
turns on whether the compatibility provisions help define the scope of the
license.

And one last reference I would like the Court to consider, and then I'll
leave this case, is further on page 7, bottom left-hand corner, picking up
in headnote no. 8, The enforcement of a copyright license raises issues
that lie at the intersection of copyright and contract law, an area of law
that is not yet well developed. We must decide an issue of first
impression, whether -- and the Court goes on to explain what the issue of
first impression is. Essentially, it has to do with licensing a derivative
work, whether it's a copyright or contract case and what are the issues that
flow therefrom.

Now, Your Honor, we would submit that if this was a case of first impression
for the Ninth Circuit, it underscores -- this is an undeveloped area of law
that turns on issues of law and fact and they're intertwined. That's
getting us back to the Rule 33 question that we were making.

I would like to give the Court a little bit of the background of the
licensing relationship between our parties that relates to the Sun against
Microsoft
case.

May I move to that or does the Court have any particular questions?

THE COURT: Certainly. Go ahead.

MR. MCBRIDE: Thank you. May I put up a chart here?

THE COURT: If you can find a place to put that chart up, go for it.

MR. MCBRIDE: I'll tell you what I have.

MR. WILLEY: We have an easel right here if you want, sir.

MR. MCBRIDE: Would you mind. . .

THE COURT: We are spacially challenged. We just do the best we can.

MR. MCBRIDE: Well, that's all right.

THE COURT: And, counsel, if you wish to move around --

MR. MCBRIDE: Your Honor, I have a smaller, obviously --

THE COURT: Nonetheless, feel free and you need not ask permission to move,
even up behind the bench area if you wish to in order to be able to see.

MR. MCBRIDE: May I, Your Honor?

THE COURT: Yes. Certainly.

MR. MARRIOTT: Thank you, Your Honor.

MR. MCBRIDE: This case is an interesting and important case because it
involves, really, the genesis of computer software for large corporations.
You can judge somewhat by the fact that we have a variety of people in the
audience here, none of whom, I believe, are affiliated with either party,
but are people who have general interest in the area. And that really
speaks to this issue, Your Honor.

In the beginning of the corporate software world, there was AT&T. AT&T
created Unix. Unix is the corporate operating system of choice that all
corporations use at the Fortune 1000 level and significantly below that. It
just works better than Microsoft Windows when you have a large distributed
environment. So companies have used Unix for 20 years or more. AT&T made
all this stuff.

Then AT&T wanted to create larger markets for it and
licensed Mr. Marriott's client, IBM, and a number of other companies,
Hewlett Packard and all those large software vendors, allowing each company
to create its own derivative work based on top of Unix. And so, thus, we
have in the chart, Your Honor, in the upper left-hand side just a really
description that points out that IBM software product that we're trying to
get produced in this case and that is at issue in this case is part stuff
that came from AT&T and part stuff that it made by itself. The derivative
work is stuff it made by itself.

Now, under the contract with IBM, and now SCO -- actually, we have two roles
in this relationship, but in the particular law I'm talking about now SCO's
in the shoes of AT&T. We have acquired all of AT&T's rights of license
and copyrights relating to Unix. And so we now have a situation where the
contract we have with International Business Machines provides the
following, in the scope clause, the clause that the Court in Sun against
Microsoft
addresses, the scope clause was really the clause that identifies
what you can use the software for. It is the heart of the intended and
allowed use for the software. The scope clause of our license, that is to
say AT&T -- SCO's license to IBM says the following: You may use this
software product. You may modify it. You may create derivative works based
thereon provided that your derivative works are treated as part of the
original software product.

Now, Your Honor, that becomes a very interesting question. Is that a
contract interpretation that this Court will ultimately have to make? Is it
a copyright issue? But the bottom line is this, IBM is obligated to maintain
some confidentiality under some law, copyright, contract and trade secrets,
with respect to not just the Unix that licensed -- was licensed from AT&T
but also the derivative work that IBM created on top of that. IBM owns the
derivative work. We don't contend anything to the contrary. But what we do
contend is that we have a license agreement that says even though you own
your derivative work, you don't own Unix, you don't own the stuff we
licensed to you and you can't use your stuff in ways that violate our
license scope. And our license scope says the following: You have to use it
for internal business purposes only. You cannot use it for the benefit of
others. You can't let others use it for their benefit. You can use it for
yourself. You can make money on it. You can license it. And that's what
its intended use is, but the second you step outside that license scope and
you use this for other people, you've violated the scope of this license.
That's what this case is rooted in, fundamentally. That's the beginning
point of this case, Your Honor.

Now, that leads us to a very interesting point. Do we have again -- and
I'll only do this once more and I won't repeat it after that -- do we then
have a contract case? Do we have trade secrets? Do we have confidential
information which is neither a trade secret or a copyright? And if so, what
proportion do those fall out or shake out in and how is the Court going to
deal with that? Your Honor, that is precisely the interrelated issue of law
and fact that ought to be addressed appropriately under Rule 33 and should
not -- should not be allowed -- this discovery needs to be framed -- in the
Court's wisdom and appropriate oversight, this discovery needs to be framed
in a way that allows us to identify just first what is all this stuff that
IBM put into Linux? And I'll explain this in just a minute. We will need to
identify all the -- everything that's at issue before we start giving it a
legal label. That's why this Rule 33 ruling that we are requesting is
appropriate in this case.

Now, we go to the question of, okay, IBM licensed a software. What's
this -- and agreed, you know, that they would keep it confidential and they
wouldn't use it for other people and would only use it internally. What
those words mean, Mr. Marriott and I or other lawyers are going to be
arguing about ad nauseam. That should not be the inquiry today. We know --
and the reason this case got launched in the first place, we know IBM gave a
lot of source code, development methods and sequences of source code usage
into Linux. Linux is a free operating system that's distributed free of
charge and is literally undermining, totally, the entire operating system
environment for Unix users in the corporate world of Fortune 1000 and
thereabouts. And Linux, as I'm sure the Court knows from general knowledge,
is developed under an open source model where many people contribute, many
people make wonderful improvements. And, again, I'm willing to guess that a
number of the people in the audience are probably software developers who
have a very intense interest in this case being decided rightly, because
there are many people who like the Linux model, like participating in a
community and -- a development community, and that's kind of a big issue
that's underlying this case.

We don't have issue with the non-infringement part of it. This particular
case has to do with IBM's infringement. IBM, by its own admission -- and
what I would like to do, if I may, Your Honor, just so you know I'm not
making this stuff up, or at least I am not making it up new, because there
are numerous references in the complaint that I think are appropriate to
just generally address. I'm sorry. This is my copy. If you don't mind
I'll trade you.

THE COURT: Have you got two? Give them to me, please.

MR. MCBRIDE: Yes, Your Honor.

Now, where we are so far, in at least my line of reasoning, is I want to
walk the Court through enough of our complaint to help the Court understand
that IBM clearly did contribute a lot of the Unix-related information into
Linux. We just don't know what it is. And I would refer the Court, to
start with, to paragraph 51 -- no. I'm sorry. We are going to back track
to that -- paragraph, please, 95. Actually it's 96. Now, the reason I'm
using this complaint is we've included in the complaint news articles
published about IBM's contributions into Linux and quotes attributed to IBM
about its involvement into Linux. So we're not guessing here. We're not
making this story up that IBM has put a lot of Unix information into Linux.
IBM had told everybody they've done that.

THE COURT: But isn't SCO also saddled with, for lack of a better term,
having made public statements itself concerning this case? I mean, it's not
just IBM making comments about the contributions to Linux.

MR. MCBRIDE: Right.

THE COURT: Isn't it also SCO making comments about trade secrets and what it
would show in court?

MR. MCBRIDE: There is -- yes. Certainly.

THE COURT: I guess, Mr. McBride, my only concern about this is I
acknowledge that this is here, but I want to focus you back on to the
question of whether or not motions to compel should be granted.

MR. MCBRIDE: Well, if the Court wouldn't mind, I'll try to hurry up my
chain of reasoning here that I think gets me to where I think the
appropriate ruling is and I'll try to do it more quickly. If I might, just
very briefly, in paragraph 96, there's a quote here attributed to an IBM
executive that for the purposes of this hearing certainly is sufficient for
discovery to go forward on the issue, that IBM admits -- and I've grown a
little older since I was last looking at this and need my glasses.

THE COURT: I understand.

MR. MCBRIDE: In the bold in paragraph 96, it simply says, While they admit
Linux has a long way to go before it can compete with the functions
available on many flavors of Unix --

(Whereupon, the reporter asked Mr. McBride to slow down.)

MR. MCBRIDE: I'm sorry. While they admit Unix still has a way to go before
it can compete with the functions available on many flavors of Unix, IBM
officials said Linux can prove more cost effective.

And the next paragraph says, We are happy and comfortable that Linux can
become the successor, not just for AIX but for all Unix operating systems.

Now, there's only one last quote I would like to refer to and that's in
paragraph 97, Your Honor. The quote was attributed to a senior executive
vice-president, Mr. Steven Mills at IBM, who in the bold stated in January
2003, IBM will exploit its expertise in AIX to bring Linux up to par with
Unix.

Then continuing in the bold only, Mills acknowledged Linux lags behind Unix
in scalability, SMP support, failover capabilities and reliability but not
for long. The pathway to get there is an eight-lane highway, Mills said,
noting that IBM's deep experience with AIX and its 250-member open source
development team will be applied to make the Linux kernel as strong as that
of Unix. The road to get there is well understood.

Now, SCO has made public statements about Unix and I'm not suggesting we
want a moratorium on all of these interrogatories. And perhaps what I
should do is address it in much more specificity right now. The things that
we have said, or that our executives have said, or quotes attributed to our
executives, we have to live with just the way IBM does, and we're happy and
willing to do that. But I believe, Your Honor, those issues are most
appropriately included in Interrogatories No. 12 and 13, and if I read them
correctly, where in Interrogatory 12 IBM requests all of the contributions
made by other people, not IBM, into Linux. And in paragraph 13 -- in
Interrogatory 13 IBM requests -- and I'm sorry. I may not be saying it
precisely right. But IBM wants the universe of all contributions made to
Linux inappropriately that we allege and then wants us to specify which of
those are attributed to IBM, and I think that's a fair characterization of
Interrogatories 12 and 13.

And, Your Honor, if you want us to answer those, Interrogatory No. 12, and
that appears to be a fair thing to do, we'll do that. We'll do that. It, to
us, appears that it's not part of this case, but if in fairness of putting
everything in front of this Court, we'll certainly do that.

I'm more focused on Interrogatories No. 1, 2 and 4 that IBM has submitted
to us, because those go to the heart of my arguments over here. We need,
Your Honor, to have Mr. Marriott produce all versions of AIX. We need them
to produce all the development notes of their developers from AIX. Then we
will have the capability of being able to compare what IBM's contributions
are lined up against our codes, and then we'll make a very clear
specification of where the violations are, and then we'll end up at that
point arguing about what kind of violations they are. This becomes really
important because of, we're back to now legal definitions, the Copyright Act
allows companies or any copyright holder to copyright expressions that are
written down on paper, expressions, including in the computer software world
sequences, structure and organization. The Copyright Act does not allow
anyone to copy a method or an idea or a concept. That's specifically
outside the realm of copyright law.

Well, back to the beginning, Your Honor, AT&T recognized this, and in the
Unix agreement that was licensed to everybody else, although IBM has its own
deal a little different, but Sequent has the standard agreement, IBM made
every company hold methods and concepts as confidential information,
recognizing that that was not protectable by copyright law, but they wanted
to make sure they had it in the contract law. So what I'm saying, Your
Honor, is if IBM will produce and answer our discovery, staying the
discovery I think will do tremendous injustice. It really gives IBM an
advantage to strategically pursue motions that would be dispositive without
a full vetting of our ability to be able to then explain to the Court what's
what and why.

Now, Your Honor, let's take the area of confidential information, and I'll
explain to you why I think that is the case.

THE COURT: Before we do that, Mr. McBride, you know, tell me why the rulings
in the cases of Utah Medical Products, decided, you know, from this
District Court and the Leucadia versus Applied Extrusion Technologies
case, decided out of the District of Delaware, should not apply to this
circumstance which indicates that the burden is on the plaintiff to prove
the existence of the trade secrets assuming that that's part of it, all
right, and that it is appropriate to postpone discovery in those
circumstances until such time as the plaintiffs have acknowledged what the
trade secrets may be, and otherwise this Court cannot determine, as the
other party cannot determine, what is relevant as to future discovery.

MR. MCBRIDE: Thank you. Yes. I will, Your Honor.

THE COURT: None of us know.

MR. MCBRIDE: Right. And future discovery is up in the air because it's in
one of the three categories. The Medical Products case that Your Honor
is referring to, in my reference, was a summary judgment case, not at the
beginning of the case but at the end of the case. The Leucadia case the
Court is referencing, specifically I would call the Court's attention to,
says that trade secrets do not embody a Rule 9 kind of specificity
requirement. It is, in fact, notice pleading required under trade secrets
law. That's what the Leucadia Court said. So I'm saying there's give
and take in both of those cases because neither of those cases addresses our
specific facts. The facts of our case go deeper than both those cases,
number one, and, number two, both of those cases were decided at a different
moment in the case than ours. And what I believe is a very correct
statement, Your Honor, is we won't know what part is trade secrets, what
part is contract, what part is copyright until we've seen all of IBM's
contributions. And I can explain why, unless you want to stop on that for a
minute.

THE COURT: No. Go ahead.

MR. MCBRIDE: The reasons why, Your Honor, remember the explanation I gave
about IBM's preparation of its derivative works. IBM owns those derivative
works. We don't dispute that. Not for a second. What we argue is they
can't give them away, the contract -- the terms of the contract, and that's
a decision that at some point summary judgment will be brought on to
interpret. No question about it. And we are simply saying, Your Honor,
because IBM only was involved in preparing that derivative work and we
weren't, we don't know what they've prepared. And part of what they've
prepared is going to be confidential information, mandated to be kept secret
under the license agreement and a breach of the scope clause, according to
us, but we don't know what they've done with the derivative work so we can't
point out what we don't know.

Now, I'll go to the trade secrets, but you can talk if you have anything on
that. I'll go to trade secrets specifically because that's a different set
of facts.

THE COURT: No. Go ahead.

MR. MCBRIDE: The cases the Court is referring to, and the cases that IBM
cite, aren't trade secret cases. That is the thrust of that case. I'm
saying our case is more -- it's an infringement case that may be one of
three different. And by the way, Your Honor, I will proffer to the Court
that we are filing a second amended complaint that has copyright
infringement claims, and will be filed within the coming few days or no less
than a week. And we'll put then fully in front of the Court the three
buckets we have outlined here, contract, trade secrets and copyright. But I
would like to the address trade secrets for a minute and explain to you what
is the genesis of our trade secrets claim. And at that point, I think most
of my argument is going to come back to some sort of a summary.

THE COURT: Let's do that because we need to be finished by --

MR. MCBRIDE: All right.

THE COURT: -- before 12.

MR. MCBRIDE: All right.

THE COURT: Giving all parties ample time to argue.

MR. MCBRIDE: If -- I'm going to use just as an aid, again, the complaint,
because this helps set out the issues. In paragraphs 50 -- starts at 51.
Now, what I'm about to refer to here really is only information addressing
the trade secret -- well, I guess that's not even true.

This addresses all the areas, but it really does go to the heart of trade
secrets, and, I believe, explains why the Court should rule according to the
way I'm requesting as opposed to entering a motion that Mr. Marriott is
requesting. Paragraph 51 through paragraph 57 -- and I will just generally
characterize those for the Court. This explains a background information
that goes to the heart of our trade secrets claim. And if we have not done
a good job of articulating that, then I guess shame on us and we better do
it better. But our trade secrets claim really is embodied in and arises out
of the joint development agreement between our two companies that started in
the 1997 time frame.

Now, Your Honor, IBM, as I mentioned, prepared its derivative work of Unix
that it calls AIX, but SCO also prepared its own derivative work of Unix
that it calls Unixware. And so we have two distinct positions in this case,
number one, we're in the shoes of AT&T as the original licensor, but, number
two, we were a licensee of AT&T. We prepared a version of Unix which was
designed to run on Intel-based machines, which is the kind of stuff that is
in pretty much all of our offices are Intel-based processors, the cheap
processors that make our computers much more inexpensive to run. Intel
processors are compared to what are called RISC, R-I-S-C, processors, which
are much more expensive and those are the processors used by large
corporations and they pay a lot more money for them.

SCO, in the early days, carved out a little niche in the Unix world that it
would develop a version of Unix only for Intel processors. Nobody else
wanted that space because Intel's processing power wasn't very good back
then. But Intel's processing power got better and better, and lo and
behold, in about 1995, SCO found itself in a really great position. Intel
was now being -- Intel chips were now becoming powerful enough that
corporations actually wanted to use them for large functions. And here we
were at SCO, lo and behold, the only company that had an operating system
running on Intel. And so, Your Honor, the SCO Company, as it delineated in
paragraph 51, from and after September 1995 spent a lot of money, for us.
I've heard the numbers 30 to 50 million, and I can't remember which, so I
better not represent too much. But for a small company, this company spent
a lot of money in making sure that its version of Unix would run very, very
well on Intel-based machines. IBM had none of that information, none
whatsoever.

The other thing that our little company did was to make our version, SCO's
version, of Unix called Unixware, run on 64-bit Intel processors. Now, the
stuff we all use right now is a 32-bit Intel processor, and that's really
not that complicated a thing. It's just that if you envision a pipe that
water flows through, or in the computer world bits flow through, a bit that
our computers all use -- or, excuse me, the processor, the Intel processors,
that our computers all use, can process 32 bits of data at a time. And so
it stands to reason that if you have a 64-bit processor, you just have twice
as wide a pipe through which water can flow and you can do stuff a lot
faster.

Our little company in 1997 and 1998 had spent 18 months, as outlined in our
allegations in the complaint, developing the technology for 64-bit Unix
processing on Intel. IBM had none of that technology. IBM had no ability
to convert anything from its operating system onto an Intel-based machine.
They had no available technology. They couldn't do it. And yet Intel
processors were becoming the thing every company wanted to run their systems
on. So IBM was being left out in the cold without an operating system that
they could sell.

Well, in traditional IBM fashion, they came to us and asked us to partner,
because that's what they do with companies, they partner and that makes a
lot of sense. But in the process of this partnership, things went awry. We
gave IBM all of our knowledge that we had spent 16 months developing about
how to run Unix on Intel processors. We had that. That's trade secret
stuff. IBM didn't have any of that. We gave it all to them in the joint
development project. And at the same time, IBM is developing Linux without
telling us. So we sail along. We give them all this trade secret
information. This is the core of our trade secrets case, the joint
development agreement between the companies that started in the 1997 time
frame called Project Monterey. We gave them more knowledge than they had as
a company about how to run Unix on Intel processors. They needed that.
They took that from us. They then went and said, Thank you very much. We
decided not to do the joint development project. Have a nice life. Took
all of our technology and gave it to Linux. IBM now is marketing this great
new Linux product, that 64-bit Linux, and it's the greatest thing ever.
They got that from us. That's a heart -- that's at the heart of our trade
secrets violation. That's in the complaint and, again, we're back to the
problem that, technically, we've already produced it, Your Honor, because we
gave them the source code of Unixwork so it's in there.

THE COURT: Didn't you give it to them in hundreds of thousands of pieces of
paper, though, without specifically identifying it?

MR. MCBRIDE: I'm quite certain we fixed all that. If we haven't, we'll do
it in sooner than 30 days. And, Mr. Marriott, do you know? Have we not
given that to you in machine readable format?

MR. MARRIOTT: I'm not sure that was Your Honor's question. The question,
Your Honor, is has the SCO Group identified the specific trade secrets they
say we've stolen and dumped into the open source? The answer is absolutely
not and I'll address that when I have the opportunity.

MR. MCBRIDE: That is correct. We haven't specific -- I admit that.
There's no question we haven't done that. And I'll tell you why and then
I'll sit down and let Mr. Marriott have his say.

We're saying this is sufficient for the Court to assume or view that trade
secrets are involved in this case. But the trade secrets are so
interrelated with the other code you can't separate out one. You can't do
it. You have to have the discovery of the universe, then we can argue about
where the code falls in what bucket. That's the way to proceed in this
case, we believe, Your Honor, and that's why a ruling under -- and I'll
finish this by reading it and then I'll sit down. What we are asking the
Court to do is under Rule 33(b) -- I'm sorry. It's at the end of Rule 32(c),
it simply says, An interrogatory that relates to facts or applications
of law or fact, the Court may order that such an interrogatory need not be
answered until after designation of discovery has been completed or until
pretrial conference. The reason for this ruling is really explained in
the -- or this rule is explained in the advisory committee notes on the
following page, that since -- it says very practically, Since
interrogatories involving mixed questions of law and fact may create
disputes between the parties which are best resolved after much or all of
the other discovery has been completed, the Court is expressly authorized to
defer an answer. We're asking the Court to defer an answer until we have
had enough discovery to be able to say what is what in the trade secret,
confidential information, copyright arena and then we'll fully answer and
live with whatever the answer is. And that relates to, really,
Interrogatories 1, 2 and 4. Interrogatories 12 and 13, Your Honor, we'll
answer those as best as we can, if that's what the Court wants us to do.

THE COURT: Thank you, Mr. McBride.

MR. MCBRIDE: Thank you, Your Honor.

Excuse me, Dave, you don't need this, do you?

MR. MARRIOTT: No. It's all yours.

Good morning, Your Honor.

THE COURT: Good morning.

MR. MARRIOTT: We appreciate the direction that Your Honor has given us, and
let me, if I may, in the few moments that I have do three things. First,
Your Honor, let me say just a little bit, because I think it's helpful to
the Court and important to the issues, about operating systems and source
codes. Those are sort of fundamental to what we're talking about on these
motions. Second, let me tell you what is at issue and that I think what you
have tentatively ruled is exactly the right ruling. And, three, let me
describe for you just briefly some of the shortcomings of the responses we
have received from the SCO Group. I won't take you through all the detail
but I would like to describe at least some of them.

If I may approach, Your Honor, we have a couple of exhibits, like the SCO
Group, that I think may facilitate the discussion.

THE COURT: Thank you.

MR. MARRIOTT: All right. So, first, Your Honor, by way of a little
background, it is important, I think, to understand the issues presented
here to understand a little bit about operating systems. And if you'll
take a look at page 1 of our book, you'll see a little table which
undertakes to describe that. Without its software, Your Honor, a computer
is essentially a useless lump of metal. With its software, however, an
operating system can do a lot of important things.

There are basically two types of programs. There are systems programs and
there are application programs. The most important of the systems programs
is the operating system. And it's the program which controls the
functioning and the operation of the hardware itself. It controls the
resources of the machine, and it is the base on which the applications sit.
So when Your Honor sits down at her desk and when you write a letter, you
communicate with the hardware via the operating system. You might use a
program like Microsoft Word or Word Perfect to write the letter. Those are
applications which sit on top of the operating system.

Computer programs, Your Honor, and operating systems are written in a
language called source code. Source code is a set of statements with
comments that represent the instructions that are ultimately translated by a
device called the compiler into ones and zeroes that the computer executes.
And if you take a look at pages 2 through 9 in this book, what you'll see,
Your Honor, is a sample of source code. In fact, this is source code from a
particular file in the 2.5.69 version of the Linux operating system. What
you'll see in red are the comments, programer's notes, and what you'll see
in black are the set of programming statements which are actually ultimately
translated into ones and zeroes that can be executed by the machine.
Essentially, Your Honor, the programer writes the language and saves it to a
file. The file is like the chapter in a much larger book of source code.
This is one little chapter in a much larger book of source code.

Unix is a family of operating systems. It was developed originally by AT&T.
Linux also is an operating system. Linux was pioneered in 1991 by an
undergraduate student at the University of Helsinki by the name of Linus
Torvalds. He posted a note on the internet saying, I'm writing an operating
system, and solicited help. What has followed, Your Honor, is a massive
collaborative exercise by which thousands of developers worldwide have
written this operating system. And if you take a look at page 10 of the
exhibits, Your Honor, you'll see a brief diagram which describes the process
by which the Linux operating system is developed. Developers worldwide make
contributions. They make the contributions to expert developers known as
subsystem maintainers. Those individuals review -- subject the code to a
massive process of peer review. Thousands of developers have input, and
when the subsystem maintainers are satisfied that the code is in an
acceptable form, it's passed up the hierarchy to Mr. Torvalds himself and
another developer by the name of Andrew Morton. Those individuals then make
judgments about what should be in the production version of Linux and what
should be in the development version of Linux and eventually it gets to the
market place.

What Your Honor needs to understand here is that whereas many operating
systems are developed behind closed doors and the source code is secret,
with respect to the Linux source code, it has been developed publicly. It
is, essentially, Your Honor, developed on the internet. Your Honor can log
on to any number of web-sites at which you will see the Linux operating
system being written before you. We have included, as the next exhibit in
the book, Your Honor, at page 11, an e-mail that was sent from a developer
of the SCO Group to the mailing list by which contributions are made to
Linux. This is the way the operating system is built. Individuals make --
write codes. They suggest it for inclusion in the Linux operating system.
It's passed through a rigorous process of peer review, all public, Your
Honor. And as a result of this process, if the contribution is deemed
acceptable, it's included into the operating system right before everyone's
eyes.

What you ought to know here as well, Your Honor, is that the plaintiff here
began in 1994 as a Linux distributor and has, over the course of the
approximately last 10 years, distributed thousands of Linux products. Now,
having said that, let me tell you the second thing I want to make sure you
understand, which is what really, I think, is at issue in this case. The
crux of SCO's case, Your Honor, is set up at paragraph 101 of their
complaint. And we've replicated it here in the book. What they say at
paragraph 101 is the following: They say IBM is affirmatively taking steps
to destroy all value of Unix by improperly extracting and using the
confidential and proprietary information it acquired from Unix and dumping
that information into the open source community. That is the case in its
essence, Your Honor. They say we took something out of a Unix book over
here, a secret Unix book, and we dumped it over here into the Linux public
book.

And if I may, Your Honor, approach, what I'm handing you is a collection
of source code.

MR. MCBRIDE: Is this AIX you're finally producing us?

MR. MARRIOTT: Let me tell you what you have here, Your Honor. You have two
books. The little book, which is highly confidential under the terms of the
protective order in the case, is Unix source code. This is the -- this is
an example of the secret book that we are alleged to have taken parts of and
dumped into the open source community. The other file that you have, the
larger book, is a single file, a single file of thousands of Unix source
code. What we're said to have done is to have taken something out of this
little skinny book and dumped it into this book right here. That's the
essence of this case.

Now, we asked the SCO Group in discovery, Your Honor, to tell us very simply
what it was, specifically, that we took out of this book and that we dumped
into this book. We asked them the basics of their case. We asked them for
the evidence that they have that we've done what they allege in their
complaint that we've done. Now, SCO objected to the requests. They said
that we didn't need to know what they took from here and what we put into
here because we did it, after all, we should know. That's the first
objection. Then they say to us, You don't need to know, IBM, because we are
going to produce to you millions of pages of paper and you can figure out
for yourself where in those millions of pages of paper what it is you
supposedly took from here and supposedly put into here is found. They tell
us that we took methods, Your Honor. They tell us that we took trade
secrets from here, but they won't tell us precisely where they are. We get
that response despite the fact that in order to file its complaint they had
to have the evidence they allege to have. We get that response despite the
fact that the case law is abundantly clear that the order of things is that
a plaintiff first tell the defendant what the trade secret at issue is, and
then the defendant provides the discovery.

If Your Honor takes a look at page 13 of the book, we summarize here the
upshot, essentially, of the case law and the rules, which is that you may
not dump on a party undifferentiated documents and expect them to find from
those documents the answers. And at paragraph -- at page 14 you see some of
the cases, Your Honor, which address the question of what the proper order
of proceedings is here. In the Porous case, Your Honor, for example,
which case concerned canisters, the Court there granted a motion to compel
specificity in answers. The Court said that failure to identify trade
secrets with sufficient specificity renders the Court -- and that was what
the Court was referring to earlier -- powerless to enforce any trade secret
claim. The same is true in the Lynchval case, and the same is true in
the Xerox case. The Court in the Xerox case, Your Honor, said
the defendant is entitled to know the basis for the plaintiff's charges against
it. The burden's on the plaintiff to specify the charges. It's not on the
defendant to guess what they are.

Now, we move to compel, Your Honor, after trying unsuccessfully for four
months to get answers to our questions. Following our motion, we received
supplemental responses. Those supplemental responses respectfully give the
impression of compliance. They are in no way compliant with what it is we
requested. I am going to lay that out for Your Honor here momentarily.
Basically what SCO says, Your Honor, is that in this giant haystack of code
over here, there are some trade secrets which we took and we dumped over
here, but they won't tell us where in this haystack it is, and they won't
show us where in this haystack that it's found.

If you take a look, Your Honor, at page 15 of the book, now, what you need
to know is a little bit about the size of the haystack and how small the
needles are. And at the risk of mixing my metaphors, let me go back to the
book metaphor. In this Unix book, Your Honor, this is actually not the Unix
book. This is just a chapter in the book. Unix System 5, which is the set
of code which they say is at issue in this case, consists of multiple
releases and multiple sub-release. Release 4.2, release 3.2, release 4.0,
those books of codes are immense. Each of those books, Your Honor, consists
of many chapters. It's not just one chapter here we're talking about. Unix
4.0, for example, has 14,548 chapters. This is a chapter. This isn't the
book. 14,548 chapters, files in these releases. Within, Your Honor, the
files in a given release, there are millions of lines of source code. If
you look here, Your Honor, you will see a number on the left margin of the
code. In this particular file, there are 11,891 lines of code, in one of
the files, in one of the chapters of which there are 14,548 in just one
release, just one release of Unix.

The same, Your Honor, is true with respect to Linux, and, indeed, there are
actually many more books of Linux than there are books of Unix. Linux has
multiple versions. There is version 2.5, there's version 2.4. Within each
of those versions there are multiple releases. Versus 2.5, for example, has
76 different releases, from 2.5.0 to 2.5.75. In other words, the
book is enormous. Within those books, Your Honor, in Linux, just as in
Unix, there are multiple chapters. Each release includes a large number of
files. If you look only at 2.5.69, Your Honor, there are 14,086 files.
This is one of the files. This is one chapter in this immense Linux book
which has been written effectively over the internet into which we're
supposed to have dumped code that they won't identify for us. In these
files, Your Honor, collectively, there are millions and millions and
millions of lines of code. This is one chapter in the book. In this
chapter, Your Honor, there are 31,597 lines of code. Where is the secret?
Is it line 17,656? What is it about it that's secret? That's what our
discovery requests, Your Honor, are all about.

Now, what makes SCO's responses here -- let me say this, what do we have
from SCO by way of responses? We asked them to tell us where over here, Your
Honor, lies the material that we put into Linux. There are many books, all
right. They have identified for us not a single Unix book, not a single
book. There are thousands of chapters of Unix from which we're supposed to
have taken things. They haven't identified for us a single Unix chapter,
not a single one. There are millions of lines of code. We've asked for
them. They haven't identified a single Unix code -- piece of code that
we're supposed to have taken from here and put over here. With respect to
Linux, they have not told us in which -- from which -- into which Linux book
we are supposed to have taken this Unix material and placed their secrets.
We don't know what book it is though there are hundreds of books at issue.

As to the chapters, they told us, finally, Your Honor, in their supplemental
responses that there are 591 Linux files, Linux chapters, into which we can
find some secret, which they won't identify, which comes from over here,
which secret they've took and they put over here in 591 files. Now, 591
files, the 591 they've identified, Your Honor, aren't associated with any
book, so we don't know into which of the more than a hundred books or
potential at issue those 591 files reside. And even if we did, even if we
knew that it was 2.5.69, Your Honor, even if we knew that, there are 335,000
lines of code in the files they've identified. They haven't identified for
us a single line of code. Worse still, Your Honor, what they say in their
supplemental responses is, We may or may not have trade secrets in those
files. Figure it out for yourself. If you read their supplemental responses
carefully, they don't say, These are our trade secrets and I swear under oath
that those are trade secrets. What they say is, They might be in there.
We'll let you know later whether they are or whether they aren't in there.
That is not, Your Honor, I submit, what it is the rules here require of a
plaintiff in a case of this kind.

Now, what makes SCO's approach to discovery here particularly troubling is
that from the beginning of the case they have touted far and wide their
evidence against IBM, the strength of their case. And I refer the Court,
just by way of example, to pages 16 and 17. The additional book I've just
given Your Honor is back up for these statements and for more statements.
Let me just focus you on the four that are included here in this exhibit.
The CEO of the SCO Group, Mr. McBride's brother, who's in the courtroom
today, has said, Your Honor, far and wide, there is line by line code in
Linux that is matching up to our Unixware code. In other words, We got you.
We found the code in here. It matches up to the code in here, but we're not
going to tell you what it is. He says, We feel very good about the evidence
that's going to show up in court. We'll be happy to show the evidence at
the appropriate time. The appropriate time, Your Honor, was four months ago
when they received our responses which were submitted to them in June. It's
now been five months.

If you look at the next bullet point, IBM has donated some of their high-end
technologies into open source. We have examples of code being lifted
verbatim. Not just a line or two, it's an entire section and in some cases
an entire program. Where is the code, Your Honor? We haven't seen it. It's
not in their discovery responses.

The next bullet, Portions of derivative works of Unix System 5 code are
found in Linux. We have begun the process of showing parts of the violating
code to appropriate parties under nondisclosure agreements. That's June
6th. That's before we served our discovery responses. We haven't seen that
code, Your Honor. We shouldn't have to have a non -- we have a protective
order in this case. We ought to be able to have at least access to what it
is everybody else is supposedly seeing.

If you look at the last bullet point, Your Honor, The month of June is show
and tell time. We're not going to show just two lines of code. We're going
to show hundreds of lines of code and that's just the tip of the iceberg.

Take a look, if you would, please, Your Honor, back at page 14 of our book,
alleged misappropriated trade secrets or confidential information must,
under the case law, be specified. The Lynchval case concerned computer
programs. The Court there affirmed a decision of the magistrate judge to
strike an expert report because the plaintiff in the case had failed to
adequately disclose the trade secrets. The trade secrets there are
disclosed with more particularity than are the trade secrets here. The
plaintiff in that case said to the defendant, There are four documents. In
those four documents there are 40 functions of the computer. Nineibiblio of
those 40 are ours. Figure it out yourself. The Court in this case said
that's unacceptable. By comparison here, Your Honor, we've been given
haystacks of millions of lines of code and been told to figure it out for
ourselves. We know, after all, they say, we're the bad guy. We supposedly
dumped their Unix property into Linux. But they won't tell us what it is.

Notably, Your Honor, notwithstanding the case cited by Mr. McBride, the SCO
Group has not cited a single case to contradict these cases. The case to
which Mr. McBride refers from the Ninth Circuit does not contradict these
principals. Indeed, it's a copyright case, which at present at least is
entirely irrelevant to the SCO Group's claims against IBM that they've
asserted no copyright claim, and even when they do, as they're now
apparently going to do, the copyright law has absolutely no bearing, Your
Honor, on whether or not they are required to tell us what the supposed
trade secret here is.

Now, why does this matter so much to IBM? Putting aside the fact that we
need to know what it is that we supposedly did so that we can defend
ourselves, the SCO Group's activities are not limited, Your Honor, to
telling the world how great their case is. They are threatening Linux users
with lawsuits. It's like they're standing outside the Barnes and Noble,
Your Honor, and a customer walks out having purchased a new Linux book, and
the SCO Group says, Wait a minute. Stop right there. That Linux book
includes our Unix property. You pay us or we're going to sue you, and if
you have a problem with it, go talk to IBM. They know what they did. They
took the secrets out of Unix and they stuck them into Linux. Take it up
with them. We showed them what the evidence is.

Your Honor, they haven't showed us what the evidence is. That's what these
motions are about. Your tentative ruling, I think, is right on the mark and
we would urge you to endorse it as your final ruling.

I don't contemplate, Your Honor, walking through the shortcomings of each of
SCO's requests. I think they're laid out adequately in our briefs. Let me
say simply this, according to SCO's CEO, in a November 12th television
interview with KSL, This is, he says, the biggest issue in the computer
industry in decades. The balance of the software industry is hanging on
this. This, Your Honor, is, as you can read for yourself, one of many
statements made by this company about its great evidence against IBM, and
yet it refuses to give us the evidence on which it's based its present
business model. Some of the responses give the impression of providing
specificity. In fact, they don't provide any. The rules don't permit this
approach to discovery, Your Honor, and it is particularly troubling to us,
since SCO's CEO has publicly stated that he's glad to see the case drag on
since, in his view, delay merely increases the SCO Group's damages against
IBM.

It is undisputed that we're entitled to the information that we've requested
here. SCO hasn't even argued otherwise, Your Honor. The only question on
these motions is whether they've given us what we've asked for, and the
answer to that is they have not. And I would submit, Your Honor, that no
reasonable person could conclude, in view of our requests and their
responses, that they've given us what we've asked for. We think their
allegations are meritless. We don't believe they had any evidence at the
time they filed this case, and we don't think they have any evidence now.
And we submit we're entitled to hear from them what it is they think they
have that IBM has done. If they're not required, Your Honor, now to provide
the answers to these questions, then we're going to be in the dark as to
what the case is about, we're not going to be in a position to defend
ourselves and we're not going to advance this case to a just and a prompt
resolution.

THE COURT: I understand your position.

MR. MARRIOTT: Thank you, Your Honor.

THE COURT: Thank you for you comments.

Mr. McBride, I'll give you 10 minutes.

MR. MCBRIDE: Thank you, Your Honor.

I think my rebuttal is going to be a best effort in open court to answer the
questions posed by Mr. Marriott at the broad level, and I believe that if I
do this at the broad level, I think that the requests that we are seeking of
fact and the methods that we are seeking is going to come clear and that that
should be the basis for the Court's ruling.

There is no trade secret in Unix system files. That is on the record. No
problem with that. There are trade secrets from Unixware, which is SCO's
version of Unix that was given to IBM in the joint development project.
Now, this may not be as much detail as we all need to get into, but I'll
clearly say that System 5 is in the book that Mr. Marriott referred to and
properly so. There's nothing secret in there. There may be copyrighted
code in there and we assert that there is, but that's not trade secret.
Their trade secrets are in Unixware that emanate from the joint development
project. And as we move forward in discovery, we should focus our efforts
on the trade secret claims relating to that joint activity between our
companies that started in 1997 and ended abruptly in 2000.

Now, confidential information, Your Honor, is a very different animal.
Confidential information is not treated as a trade secret, necessarily,
under the law. We have a unique case here. The confidential information
we're talking about is stuff that Mr. Marriott's client created but we
didn't ever get to see.

THE COURT: The protective order addresses that. There's a protective order
in place.

MR. MCBRIDE: No, Your Honor, excuse me. The confidential information is in
the derivative works prepared by Mr. Marriott's client that we hope to
receive under the -- under the -- our discovery requests but we haven't seen
one word of yet. We hope to see that. And once we see AIX and all versions
of it, then we will be in a position to be able to say, Huh, you know what?
This stuff you did in derivative works, you own it, but you contributed to
Linux improperly, and, therefore, we have a claim in state law contract for
breach of confidential information, which is completely separate from trade
secrets. So it's just really important that we get a scalpel here and
understand what we are looking for. Trade secrets, nothing in Unix System 5
that exists in Unixware with respect to the joint development project.
Confidential information emanates from IBM's own development of AIX that we
never got to see, but we, nevertheless, have the contractual right to
control the use of in very limited instances, which is involved in this
particular case. So, hopefully that clarifies, and maybe even for Mr.
Marriott's arguments, if we haven't done a good job of putting that
information to him.

Now, if -- we're spending a few more minutes on public statements made by
our executives. And, Your Honor, there are other companies that have
contributed code to Linux, the biggest one of which is Silicon Graphics.
Silicon Graphics Company has taken direct lines of Unix System 5 code, not a
derivative work code, Unix System 5 and distributed it to Linux. I'll
represent to the Court in just broad terms that SGI has, at some level,
acknowledged that occurred. I won't characterize SGI's own writing, but, in
fact, wrote an open letter acknowledging, at some level, that that occurred.

The evidence that our executives have talked about in the public has had to
do with Unix System 5 code contributed by Silicon Graphics. Has nothing to
do with IBM. Now, the evidence against IBM that our executives have talked
about, Your Honor, that we know IBM has contributed into Linux,
specifically, and we've talked about this, relate to the code that came from
Dynix, that is the NUMA code and the RCU code. IBM advertises the fact that
they contributed this. We have produced those files in discovery saying, We
think you contributed. We know you contributed NUMA and RCU. We think it's
a violation. Now, whether it is a violation or not is not of moment in this
particular hearing. That's something that we will argue about at a
different day and a different time. But, Your Honor, just at least in
support of the statements made by our executives, that's what they have
talked about is that IBM has taken the Dynix code and wholesale contributed
very important parts of it relating to multiprocessor code, and IBM has
taken the methods learned and really improved the multiprocessing
capabilities of Linux in a way that violates either the confidential
information or some copyrighted code. That's what we've been saying all
along, and that's consistent with what we continue to say.

So, I don't know if my 10 minutes are up, but here's what I think, Your
Honor, is the appropriate order that we would request is entered, that we,
in fact, take a scalpel out, and we -- and, Your Honor, just for fun here, I
brought the last CD's produced by both sides in this particular case of
information. Ours is numbered 126 and theirs is numbered 21. This morning
we actually received 22 and 23, as I understand it. Which is simply to say
we've produced a hundred more CD's of documents than they have. What we
want and what we need is all versions of AIX, all versions of Dynix. We
have repeatedly asked for it since June. We have not seen one line of any
of that until, apparently, this morning two CD's of a version of Dynix were
produced. So the appropriate order, Your Honor, is simply this, that first
of all, IBM produces all of the Dynix and AIX, and we then compare it with
our Unixware code to be able to draw more concrete allegations, more
concrete answers to the interrogatories, and that once IBM has produced its
code so we can compare it, and we have 30 days to do that, we'll take
another crack at answering the interrogatories in another fashion. But we
just think that's the fair way of doing this, and, Your Honor, to stop
discovery would be absolutely unjust in this case because then, again,
remember, the derivative works, we never saw them in the first case. We're
not saying they're trade secret. We're saying IBM had a contractual
obligation to not disclose those, so it would tie our hands, absolutely
improperly, and give IBM strategic advantages that would be not right in
this case, as far as how discovery should proceed. So that's our request in
terms of how this ought to be handled, Your Honor.

THE COURT: Thank you, Mr. McBride.

Mr. Marriott, anything in brief response?

MR. MARRIOTT: Sure, Your Honor.

Unless the Court wishes, I won't respond in full to SCO's motion to compel
IBM except, Your Honor, to say this, IBM has produced what amounts to the
equivalent of more than a million pages of paper. We have not refused to
provide discovery. We have said the discovery must be tailored to the
allegations in the complaint. We've provided the discovery that we think can
fairly be provided in view of their allegations. We have provided Dynix code
as of last night. We would have provided it earlier, Your Honor, but for the
third party notice process that's required. We intend to provide AIX code to
them. We intend to provide the code when the process of third party
notification is compete.

What we don't intend to do, unless this Court makes us do it, is to produce
every conceivable iteration and version of AIX and Dynix. As we lay out in
our papers, that amounts to somewhere in the order of 40 million pages of
paper. There's no cause for that. It bears no relevance to the case as we
presently know it. And we would respectfully ask that the Court adhere to
its tentative rulings, grant IBM's motions in their entirety and either deny
or hold in abeyance the SCO motion.

Thank you, Your Honor.

MR. MCBRIDE: One very brief sur-reply, Your Honor? We want the 40 million
pages. We'll digest it.

THE COURT: Are you yourself going to review them by Sunday, Mr. McBride?

MR. MCBRIDE: Your Honor, if we have it in computer readable form, our
experts can analyze it. Unless we have it from IBM, we can never know the
ways they've improperly taken their derivative work code and made Unix
better in violation of our contract. That would be an injustice, Your
Honor.

MR. MARRIOTT: May I just --

THE COURT: Last word.

MR. MARRIOTT: -- respond briefly to that one, Your Honor? If you take a
look at the little book that we provided Your Honor of the Linux development
process, what makes this -- independent of the fact that there are no case --
there is no case law authority for what Mr. McBride suggests, independent
of that, if you take a look, Your Honor, at the chart, you will see that the
Linux development process is an open process. That's what makes Linux
great. It Mr. McBride and any of the SCO executives want to know what
anybody's contributed to the Linux operating system, they can find it out
for themselves by getting on the internet at any one of the number of sites
that exist there and doing a search for IBM.

Thank you, Your Honor.

THE COURT: Counsel, I am ready to rule in this matter. I think it is
essential to get the ball rolling in this circumstance, and I'm convinced
that my initial intended order is appropriate in this case. And I say that,
acknowledging, Mr. McBride, that at the conclusion of what will be required
of SCO, then we will visit your issues to determine the breadth and
specificity that will be allowed you. We're going to do this both ways.

At this time, however, I will grant defendant IBM's motion to compel answers
to both sets of interrogatories, and that would include, I think, 12 and 13,
if those are the ones that are questionable. SCO is to file its responses
within 30 days of the entry of this order, and if, for some reason, it is in
good faith unable to obtain a particular portion of that, then it must file
the appropriate affidavits indicating why it cannot. It is to respond -- it
should file its discovery and respond in order to comport with the -- or
correct the deficiencies that are set forth in the defendant's addendum
that's filed November the 4th.

Mr. Marriott, I would ask you, if you are able to at this time, to identify
those particular documents which you are requesting. Are you able to do
that?

MR. MARRIOTT: I can begin that, sure, Your Honor.

THE COURT: All right, let me just indicate further that those responses are
to identify, with specificity, the source codes that you are claiming form
the basis for your action.

Now, with regard to the documents.

MR. MARRIOTT: Your Honor, I'm happy to, by way of supplement, to provide a
full list. We have a number of document requests, somewhere in the order of
50. Of course, we want answers to all of those. The principal problem here
has not been that SCO has objected to providing them. It's said that it
would provide them, but it simply hasn't done it. We think that the process
is being gamed in the sense that we're told, Well, we're in a rolling
production. You'll get them eventually. We know there are important
documents that are missing, and let me try to itemize them for the Court, if
I may, some of those.

MR. MCBRIDE: Do you have a list?

THE COURT: I don't want to take -- perhaps if they're in written form, you
can provide that to Mr. McBride and --

MR. MARRIOTT: I'm happy to do that, Your Honor.

THE COURT: -- the same requirement will be enforced. In the meantime, all
other discovery is postponed. And the -- you -- both parties will be
expected to abide by the protective order that is currently in place. I
will set this matter for a hearing.

Mr. Marriott, I would ask that you prepare the order in this matter and
submit it to me no later than Wednesday of next week. Assuming that it is
an appropriate order, then your 30 days would begin to run, Mr. McBride,
from that period of time. We will set a hearing, then, for approximately
two weeks thereafter, so we are talking about the middle of January, all
right. Does anybody have a period of time, let's say, in the week of
January 12th when you could not be present for a morning hearing?

MR. MARRIOTT: No, Your Honor.

THE COURT: All right. Does that give you sufficient time? I am holding you
to the 30 days, but if we get this order signed by Wednesday of next week,
let's make it even the fourth week of January, which is after the 19th. Why
don't we do it Friday, then, the 23rd at 10 o'clock, again, and then we will
address the remaining motions of SCO, all right.

MR. MCBRIDE: So Your Honor is not ruling on our motions at this point in
time; is that correct?

THE COURT: No. I'm not ruling on your motions, and that is inherent in my
order that further discovery be postponed.

MR. MCBRIDE: Very good, Your Honor.

THE COURT: We'll address them then.

MR. MCBRIDE: So and we'll, in this next -- the January hearing then we will
address the -- our pending motions as well?

THE COURT: Yes.

MR. MCBRIDE: Thank you, Your Honor.

THE COURT: All right. That's with the assumption that the discovery that
SCO is to complete has been completed, all right, and with the required
specificity. So what my intention is, then, is to then address the motions
of SCO.

MR. MCBRIDE: Just -- I'm just thinking procedurally whether we will have
time to actually brief and agree upon whether we -- the specificity is
required in advance of the hearing or whether we will be doing that at the
hearing.

THE COURT: No. I would think that should be in place prior to the hearing.
If you want a date later than that, that's fine. I don't care.

MR. MCBRIDE: Let's hold that date for the time being, and then if, for
whatever reason, it appears problematic, we'll notify the Court Does that
seem appropriate?

THE COURT: It does.

MR. MARRIOTT: That's fine by us, Your Honor.

THE COURT: If there's nothing further, counsel, we'll be in recess in this
matter.

(Whereupon, the hearing was concluded.)


  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 )