|
DAY CASEBEER MADRID
WINTERS & BATCHELDER LLP
LLOYD R. DAY, JR. (90875)
VERNON M. WINTERS (130128)
JAMES R. BATCHELDER (136347)
DAVID J. ESTRADA (168105)
ROBERT M. GALVIN (171508)
JULIE S. TURNER (191146)
20400 Stevens Creek Boulevard, Suite 750
Cupertino, CA 95014
Telephone: (408) 255-3255
COOLEY GODWARD LLP
JANET L. CULLUM (104336)
JAMES DONATO (146140)
Five Palo Alto Square, 3000 El Camino Real
Palo Alto, CA 94306-2155
Telephone: (650) 843-5133
Attorneys for Plaintiff
SUN MICROSYSTEMS, INC.
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN JOSE DIVISION
|
SUN MICROSYSTEMS, INC.,
a Delaware corporation,
Plaintiff,
v.
MICROSOFT CORPORATION,
a Washington corporation,
Defendant,
|
No. C 97-20884 RMW (PVT) ENE
SUN MICROSYSTEMS, INC.'S REPLY IN
SUPPORT OF ITS MOTION FOR
PRELIMINARY INJUNCTION UNDER 17
U.S.C. § 502
Date: September 10, 1998
Time: 9:00 a.m.
Judge: Hon. Ronald M. Whyte
Ctrm: 6
|
Refiled Pursuant to
10/21/98 Order of the Court
TABLE OF CONTENTS
| I. |
SUN IS LIKELY TO SUCCEED ON THE MERITS OF ITS COPYRIGHT INFRINGEMENT CLAIM. |
1
 |
| |
A. |
MICROSOFT DOES NOT DISPUTE THAT IT COPIED SUN'S JDK SOURCE CODE OR THAT ITS PRODUCTS FAIL THE JCK 1.1A TEST SUITE. |
1 |
| |
B. |
MICROSOFT HAS NOT REBUTTED THE PRESUMPTION OF VALIDITY OF SUN'S COPYRIGHTS OR SUN'S SHOWING THAT ITS COPYRIGHT EXTENDS TO THE MATERIAL WHICH MICROSOFT COPIED. |
3 |
| |
C. |
THE TLDA GRANTS SUN THE RIGHT TO TEST FOR JNI. |
4 |
| |
|
1. |
Because JNI falls within the definition of "AAPI," the "Java Test Suite" may test for compliance with Sun's specification of JNI. |
4 |
| |
|
2. |
The term "AAPI" is not limited to the Java classes listed in Section I(A) of Exhibit A of the TLDA. |
6 |
| |
|
3. |
The draft agreements exchanged by the parties during negotiations confirm "AAPI" is not limited to the Java classes listed in Section I(A) of Exhibit A of the TLDA. |
7 |
| |
|
4. |
Section 1.1(a) of the definition of "AAPI" is not limited to "only the Java applet interfaces." |
8 |
| |
|
5. |
"Sun's specification of the AAPI" is not limited to the Documentation listed in Section 1.1(b)-(d) |
9 |
| |
|
6. |
Since JNI is not a Supplemental Java Class, Microsoft does not have discretion whether to distribute JNI with its Products. |
10 |
| |
|
7. |
Microsoft does not have the "sole right" to define native code interfaces like JNI. |
10 |
| |
D. |
THE TLDA DOES NOT GRANT MICROSOFT THE RIGHT TO DISTRIBUTE COMPILER PRODUCTS WHICH FAIL SUN'S TEST SUITES. |
12 |
| |
E. |
SUN'S COPYRIGHT INFRINGEMENT CLAIM IS BASED ON MICROSOFT EXCEEDING THE SCOPE OF ITS LICENSE, NOT ON BREACH OF CONTRACT. |
13 |
| II. |
EVEN THOUGH SUN IS LEGALLY ENTITLED TO AN ORDER ENJOINING THE SALE OF ALL INFRINGING MICROSOFT PRODUCTS, SUN IS WILLING TO MODIFY ITS REQUESTED RELIEF TO MINIMIZE THE INCONVENIENCE TO THIRD PARTIES REGARDING WINDOWS 98. |
14 |
TABLE OF AUTHORITIES
| Cases |
Page
|
A. Kemp Fisheries, Inc. v. Castle & Cooke, Inc.,
852 F.2d 493 (9th Cir. 1988) |
6 |
Apple Computer, Inc. v. Formula Int'l, Inc.,
725 F.2d 521 (9th Cir. 1984) |
15 |
Cadence Design Sys., Inc. v. Avant! Corp.,
125 F.3d 824 (9th Cir. 1997),
cert. denied, 118 S. Ct. 1795 (1998). |
14 |
California State Auto. Ass'n Inter-Ins. Bureau v. Antonelli,
156 Cal. Rptr. 369 (Ct. App. 1979) |
7 |
Forry, Inc. v. Neundorfer, Inc.,
837 F.2d 259 (6th Cir. 1988) |
15 |
Rano v. Sipa Press, Inc.,
987 F.2d 580 (9th Cir. 1993) |
14 |
S.O.S., Inc. v. Payday, Inc.,
886 F.2d 1081 (9th Cir. 1989) |
14 |
Sun Microsystems, Inc. v. Microsoft Corp.,
999 F. Supp. 1301 (N.D. Cal. 1998) |
4 |
Triad Sys. Corp. v. Southeastern Express Co.,
64 F.3d 1330 (9th Cir. 1995) |
3, 15 |
United States v. King Features Entertainment, Inc.,
843 F.2d 394 (9th Cir. 1988) |
14 |
| Statutes |
|
| 17 U.S.C. § 410(c) |
3 |
| Cal. Civ. Code § 1625 |
6 |
| Cal. Civ. Proc. Code § 1856 |
6 |
INTRODUCTION
Microsoft does not dispute that it copied the source code for
Sun's JAVATM Development Kit ("JDK") computer program. Nor does it
dispute that Sun has registered copyrights for the JDK. Instead,
Microsoft twists beyond recognition the terms of the Technology
License and Distribution Agreement ("TLDA") in a vain attempt to argue
that the TLDA bars Sun's copyright infringement claim. The license
granted to Microsoft under the TLDA, however, authorizes Microsoft to
distribute only such products which first pass Sun's compatibility
test suite. Microsoft does not dispute the fact that its products
fail to pass Sun's JAVATM Compatibility Kit ("JCK") 1.1a test suite.
Consequently, Microsoft's distribution of incompatible products is
unlicensed and infringes Sun's registered copyrights. Nonetheless,
Microsoft asks the Court to rewrite the terms of the TLDA, excuse its
failure to comply, and hold that Microsoft cannot be held liable for
copyright infringement even if it exceeds the scope of its license
from Sun.
Sun's preliminary injunction motion for copyright infringement is
not about denying "innovation" or "choice." The issue is whether
Microsoft will be required to honor the terms and limits of its
license with Sun, or whether, because of its size and market
dominance, Microsoft will be allowed to ignore its contractual
obligations, infringe Sun's copyrights, and debase Sun's JAVATM
technology.
I. SUN IS LIKELY TO SUCCEED ON THE MERITS OF ITS COPYRIGHT
INFRINGEMENT CLAIM.
A. Microsoft Does Not Dispute That It Copied Sun's JDK Source Code Or That Its Products Fail the JCK 1.1a Test Suite.
Unlike most copyright infringement cases, the accused infringer in
this case does not deny copying. Given the massive, literal copying
of Sun's JDK source code into Microsoft's Internet Explorer 4.0 ("IE
4.0") and Software Development Kit for JAVATM ("SDKJ") 2.0 products,
which Sun demonstrated in its opening papers, Microsoft does not
contest that it copied Sun's JDK source code and incorporated Sun's
source code into IE 4.0, SDKJ 2.0 and 3.0, Visual J++ 6.0 and Windows
98 products.
Microsoft also does not contest that it fails to pass all of the
tests in Sun's JCK 1.1a test suite-- the test suite which accompanied
Sun's JDK 1.1 upgrade. Specifically, Microsoft does not dispute that
IE 4.0, SDKJ 2.0 and 3.0, Visual J++ 6.0 and Windows 98 fail to pass
any of the 214 tests for JAVATM
Native Interface ("JNI") contained in the JCK 1.1a test suite.1
Instead of showing that it passes Sun's compatibility test suite,
Microsoft argues that it, unlike any other licensee, is exempt from
any requirement to pass the JNI tests in the JCK 1.1a test suite. See
infra pp. 4-11.
Besides failing the tests regarding JNI, Sun has also shown that Microsoft's SDKJ 2.0 and 3.0 and Visual J++ 6.0 products fail to pass the Compiler Output Requirement of the JCK 1.1a Test Suite. These products have compilers which utilize unauthorized keywords and compiler directives, causing these incompatible compilers to generate output that will not execute or "run" as intended by the programmer with Sun's standard JDK 1.1 Virtual Machine as required by the JCK 1.1a Test Suite. Schroer Reply Decl., ¶¶ 4-8; Hankinson Decl., ¶¶ 4, 6-8, 21-27, 34-38.
Microsoft does not dispute that its compiler generates output
which runs on Microsoft's, but not Sun's, virtual machine. Instead,
Microsoft claims the "execute properly" requirement of the JCK 1.1a
Test Suite only requires Microsoft's compilers to produce output that
complies with the Java Language Specification and the Java Virtual
Machine* Specification, regardless whether it will execute as intended
by the programmer on Sun's JDK 1.1 Virtual Machine. Opp. at 12.
According to Microsoft, if its compiler recognizes unauthorized
keyword or compiler directives and outputs a program which causes a
box to appear upon execution using Microsoft's virtual machine, that
same output "properly executes" on Sun's JDK 1.1 virtual machine even
if the box fails to appear and an error message is generated. Deutsch
Reply Decl., ¶¶ 17-20; Schroer Reply Decl., ¶¶ 8-13.
Microsoft's argument is nonsensical. One important purpose of the
Compiler Output Requirement in the JCK 1.1a test suite is to ensure
that a licensee like Microsoft does not impermissibly alter the JAVATM
language with unauthorized commands or syntax that cause its compiler
output to execute as intended only with its virtual machine and no
others. Schroer Reply Decl., ¶ 12; Hankinson Reply Decl., ¶¶ 25-27.
By requiring a licensee's compiler to generate output which executes
properly on Sun's standard JDK 1.1 virtual machine, Sun protects
source code and binary code compatibility among all of its licensees.
Id. Like the JNI test failures, Microsoft unsuccessfully argues this
failure should be excused as well. See infra pp. 11-13.
B. Microsoft Has Not Rebutted The Presumption Of Validity Of Sun's Copyrights Or Sun's Showing That Its Copyrights Extend To The Material Which Microsoft Copied.
Microsoft acknowledges that Sun has received certificates of
registration from the Copyright Office for various versions of its JDK
computer program. Microsoft also acknowledges, as it must, that Sun's
copyrights are therefore entitled to a presumption of validity. See
17 U.S.C. § 410(c); Triad Sys. Corp. v. Southeastern Express Co., 64
F.3d 1330, 1335 (9th Cir. 1995).
Microsoft's only contention is that, since Sun's JDK source code
has a small amount of code developed by third parties, either Sun's
copyrights are of dubious validity or Sun has not shown that its
copyrights extend to the material Microsoft copied. Microsoft's
argument is half-hearted at best, and with good reason. Sun told the
Copyright Office about third-party code in the JDK computer program,
and, after examination, the Copyright Office still issued certificates
of registration. See Crean Decl., Exhs. D-E; Supp. Crean Decl.,
Exhs. A-C. The fact that less than 10% of the source code files for
JDK 1.1 may contain third-party code does not rebut the presumption of
validity of Sun's copyrights. Lindholm Reply Decl., ¶ 44. The vast
bulk of the JDK source code is original source code developed by Sun.
Id. If it were not, companies like Microsoft surely would not have
paid millions of dollars to license the technology.
Microsoft also argues, again without much force, that Sun has not
shown its copyrights extend to the material Microsoft copied. Even if
the files which potentially contain third-party code are completely
excluded from consideration, Sun still has submitted evidence that at
the very least hundreds of files contained in Microsoft's products are
identical or contained less than 10% lines of different source code,
and that tens of thousands of lines of code are identical. Deutsch
Reply Decl., ¶¶ 30-35. Microsoft has offered no evidence
demonstrating it independently developed all of the source code in its
products or that it only copied the small portion of Sun's JDK based
on third-party files. Microsoft surely would have presented the Court
with such evidence if any existed. Based on this record, Sun has
shown that Microsoft copied material protected by Sun's copyrights,
and Microsoft has failed to rebut the presumption of validity attached
to Sun's copyrights.
C. The TLDA Grants Sun the Right To Test For JNI.
Given the failure of Microsoft's products to pass the JCK 1.1a
test suites and the undisputed evidence of copying, Microsoft's core
defense to the charge of copyright infringement is its argument that
it is not required to pass the JCK 1.1a tests relating to JNI. Not
only is Microsoft's argument wholly lacking in merit, it is predicated
on an attempt to replace the actual text of the TLDA with new,
unwritten limitations based solely on inadmissible parol evidence.
1. Because JNI falls within the definition of "AAPI," the
"Java Test Suite" may test for compliance with Sun's specification of
JNI.
This Court previously considered arguments regarding testing for
JNI and found that "Sun has raised a serious question as to whether
its tests for JNI compliance are appropriate under the TLDA." Sun
Microsystems, Inc. v. Microsoft Corp., 999 F. Supp. 1301, 1310
(N.D. Cal. 1998).
Sun's position is based on the plain text of the TLDA:
- Section 1.15 of the TLDA defines "Java Test Suite" as "SUN's
publicly available test suites for validating that products which
interpret Java bytecodes comply with the SUN specification of the AAPI
as of the date of the test suites." TLDA at § 1.15.2
- Section 1.1 of the TLDA defines "AAPI" in relevant part as "the
public application programming interface to the Java Applet
Environment (JAE) reflected in the Technology as identified in Exhibit
A . . . as modified by SUN during the term of this Agreement." Id. at
§ 1.1.
- Exhibit A of the TLDA states the JAE consists of certain Java Classes and the "Java Runtime Interpreter, which implements the Java Virtual Machine." Id. at Exh. A.
Based on these definitions, any "public application programming
interface" to the "Java Runtime Interpreter" falls squarely within the
definition of AAPI. Since "Technology" is expressly defined in
section 1.25 to include "Upgrades," "AAPI" encompasses "the public
application programming interface . . . as modified by SUN," and the
"Java Test Suite" tests for compliance with the specification of the
AAPI "as of the date of the test suites," Sun's Upgrades to the "Java
Runtime Interpreter" also fall squarely within the definition of
"AAPI." The Java Test Suite therefore may test for compliance with
Sun's specification of Upgrades to the Java Runtime Interpreter.
On the critical issue of whether JNI is a public application
programming interface to the Java Runtime Interpreter, there is no
dispute. Sun has submitted evidence from other licensees, such as
IBM, Inprise and Netscape, as well as experts attesting that JNI is a
public application programming interface to the Java Runtime
Interpreter. See Sueltz Decl., ¶ 7; LeFaivre Decl., ¶ 5; Day Reply
Decl., Exh. A [Hennesey Tr. at 193-99], Exh. B [Joy Tr. at 122],
Exh. C [Deutsch Tr. at 290-91]; Gosling Reply Decl., ¶ 15. Sun
distributed JNI in its JDK 1.1 upgrade as an enhancement of an earlier
native method interface contained in the Technology originally shipped
to Microsoft. Sueltz Decl. ¶ 7. In response, Microsoft offers no
evidence that JNI is not a public application programming interface to
the Java Runtime Interpreter, nor does it argue the point in its
papers. Amidst the plethora of distractions raised in Microsoft's
opposition, its silence on this critical point is telling.
Given the text of the TLDA and the deposition testimony of its own
witnesses, Microsoft's silence is understandable. Microsoft's expert
concedes JNI is an application programming interface. Huhns Decl., ¶
40. He also concedes JNI provides a "mechanism . . . to invoke a Java
virtual machine within a native code program." Id. Similarly, Brad
Silverberg, Microsoft's former Senior Vice President of the
Applications and Internet Client Group, admitted that he considered
JNI "an interface to the VM." Day Decl., Exh. D [Silverberg Tr. at
38]. Since the Java Runtime Interpreter "implements" the Java Virtual
Machine or "VM," an "interface to the VM" such as JNI is, by
definition, an "interface to the Java Runtime Interpreter" according
to Microsoft's own admissions. Indeed, the TLDA specifically
describes "interfaces to the Reference Implementation VM" as including
"native code interfaces." TLDA at § 2.9(e).
Based on this plain reading of the TLDA, Sun has demonstrated a
likely success of establishing that Sun's Java Test Suite may test for
compliance with Sun's specification of JNI. Since Microsoft fails
those tests, Microsoft is acting outside the scope of its license, and
is liable for copyright infringement.
2. The term "AAPI" is not limited to the Java classes listed
in Section I(A) of Exhibit A of the TLDA.
Not content with the definition of "AAPI" in the contract,
Microsoft argues that the term should be construed in light of the
"contemporaneous definition" of AAPI found in various "white papers"
and "readme" files collected by Microsoft's expert. Opp. at 7. Based
on these sources, Microsoft argues "AAPI" should be interpreted to
mean "Java Applet API" or "Java Base API" and be limited to the Java
classes or "packages listed in section I(A) of Exhibit A of the TLDA."
Id.
Microsoft should not be allowed to contradict the unambiguous
definitions contained in this carefully negotiated agreement. The TLDA
is an integrated contract reflecting the "final, complete and
exclusive agreement between the parties." TLDA at § 12.3. "If a
contract is integrated, the parol evidence rule operates to exclude
evidence that is not relevant to prove a meaning to which the language
of the instrument is reasonably susceptible." A. Kemp Fisheries,
Inc. v. Castle & Cooke, Inc., 852 F.2d 493, 495 (9th Cir. 1988)
(internal quotations omitted); see also Cal. Civ. Code § 1625;
Cal. Civ. Proc. Code § 1856. Extrinsic evidence is not admissible "to
add to, detract from, or vary the terms of a written contract."
A. Kemp Fisheries, 852 F.2d at 495. "If, after considering the
evidence, the court determines that the contract is not reasonably
susceptible to the interpretation advanced, the parol evidence rule
operates to exclude the evidence." Id. at 496 n.2.
Here, the TLDA expressly defines AAPI as comprising "the public
application programming interfaces to the Java Applet Environment."
"Java Applet Environment" is in turn defined in Exhibit A of the TLDA
as consisting of two elements: (1) the Java Classes listed in section
I(A); and (2) the Java Runtime Interpreter. By arguing that "AAPI"
should be limited to the Java Classes listed in section I(A),
Microsoft is directly contradicting an express, unambiguous definition
and giving no effect to the term "Java Runtime Interpreter." The
definition of "AAPI" is "not reasonably susceptible" to Microsoft's
proposed interpretation. Microsoft's parol evidence must be excluded.
See California State Auto. Ass'n Inter-Ins. Bureau v. Antonelli, 156
Cal. Rptr. 369, 374-75 (Ct. App. 1979) (holding contract term is not
ambiguous simply because "commonly understood meaning" of term
conflicts with express, unequivocal definition in contract).
3. The draft agreements exchanged by the parties during
negotiations confirm "AAPI" is not limited to the Java classes listed
in Section I(A) of Exhibit A of the TLDA.
Even if Microsoft's parol evidence-based argument were reasonable and admissible, which it is not, Sun has still shown a likelihood of success in establishing that the definition of "AAPI" is not limited to the Java Classes listed in Exhibit A of the TLDA. Not only is Sun's construction supported by the text of the TLDA, the negotiation history confirms Sun's construction as well.
Microsoft originally proposed defining "AAPI" as "the application
programming interface to the Technology, including the interface to
the Applet Classes," and defining "Applet Classes" as "the Java
classes listed in Exhibit A." Patch Reply Decl., ¶ 18. Sun
specifically rejected this definition, explaining that it wanted to
make clear that the definition of "AAPI" was not limited to just the
Java classes in Exhibit A of the TLDA -- precisely the argument
Microsoft is now making. Id. Sun thus proposed a definition of
"AAPI" based on the broader term, Java Applet Environment, which
expressly included the Java Runtime Interpreter. Id., ¶ 19. Sun's
proposed definition, not Microsoft's, was incorporated in the final
TLDA. Id., ¶¶ 19-20. If the parties wished to limit the definition
of "AAPI" to just Exhibit A(I)(A)'s Java Classes, as Microsoft now
contends, they would have adopted Microsoft's proposed definition, not
Sun's.
4. Section 1.1(a) of the definition of "AAPI" is not limited
to "only the Java applet interfaces."
Microsoft argues that JNI does not fall within the definition of
"AAPI" because JNI is not a "Java applet interface" or a "Java
interface." Opp. at 9-10. Since neither "Java applet interface" nor
"Java interface" is a term used or defined in the TLDA, Microsoft
appears to be tilting at windmills that only it can see. The TLDA
does not use the terms, and Microsoft has not provided a clear
explanation of their meaning in its brief.
Microsoft seems to argue that section 1.1(a) of the AAPI
definition is limited to "Java applet interfaces," which Microsoft
says are interfaces to be invoked by an "applet programmer" writing an
applet in the Java language. Opp. at 9-10; Huhn Decl., ¶ 43.
Microsoft apparently believes the presence of the word "applet" in the
term "Applet Application Programming Interface" or "AAPI," creates
this limitation. Opp. at 16. Because applet programmers supposedly
cannot "ask to load libraries of native methods when their applet is
run," Microsoft claims JNI is "irrelevant to an Applet programmer" and
thus not a "Java programming interface." Id. at 10.
Microsoft's argument suffers from two fatal flaws. First, as a
legal matter, the TLDA expressly and unambiguously defines "AAPI."
The presence of the word "applet" in the term "AAPI" does not limit or
modify the express definition of "AAPI," as the actual definition in
the TLDA makes plain. Regardless how third-party programmers might
interpret the term "AAPI" by itself, the parties gave the term a
particular, express meaning which controls. Microsoft cannot be
permitted to use parol evidence to contradict the simple, explicit
definition found in the TLDA.
Second, as a factual matter, Microsoft's argument is built on the
false premise that applets cannot load native code when they run. To
the contrary, applets can load native code, depending on the security
context. Lindholm Reply Decl., ¶ 23. James Allchin, Microsoft's
Senior Vice President for Personal and Business Systems, admitted that
applets could load native code when digitally signed. Day Reply
Decl., Exh. E [Allchin Tr. at 57]; see also Huhn Decl, ¶ 24. Even
before the signing of the TLDA in March 1996, applets could load
native code in a variety of security contexts. Lindholm Reply Decl.,
¶ 23.
5. "Sun's specification of the AAPI" is not limited to the
Documentation listed in Section 1.1(b)-(d).
Based on a quote from an internal Sun document discussing
compatibility testing prepared by a Sun engineer before the execution
of the TLDA, Microsoft claims that the Java Test Suite may not test
for JNI because " the SUN specification of the AAPI" is limited to
"the three Documentation excerpts listed in TLDA sections 1(b), (c)
and (d)." Opp. at 15.
Microsoft's argument that the phrase "SUN specification of the
AAPI" excludes section 1.1(a) from its scope is without support. The
TLDA expressly defines the "Java Test Suite" as validating compliance
"with the SUN specification of the AAPI as of the date of the test
suites." TLDA at § 1.15. Section 1.1 of the TLDA defines "AAPI" as
consisting of four elements: (a), (b), (c) and (d). Sun's
specification of the AAPI is therefore Sun's specification for these
four elements as of the date of the test suites. If the parties
intended to limit the Java Test Suite to validating compliance with
section 1.1(b), (c) and (d), they would have defined Java Test Suite
as validating compliance only "with the SUN specification of sections
1.1(b)-(d)," not the broader term "SUN's specification of the AAPI."
The term "SUN specification of the AAPI" is not reasonably susceptible
to Microsoft's strained interpretation. Microsoft should not be
allowed to rely on unrelated, parol evidence which contradicts the
plain text of the TLDA.
Even if parol evidence were considered, Sun has shown that the
parties never expressed any intent to exclude the subject matter of
section 1.1(a) from the specification of AAPI or compatibility
testing. Baratz Reply Decl., ¶ 6. In fact, such a construction would
deny the parties' acknowledgment of the need for the test suites to
evolve with the JAVATM technology. Id.
Microsoft's last argument for excluding section 1.1(a), and thus
JNI, from the definition of "the SUN specification of the AAPI" is
that Sun's testing must be prevented from being "arbitrary and
unconstrained." Microsoft's musings about images of Mr. Lindholm's
mother being packaged with the Java Runtime Interpreter miss the mark.
Opp. at 15. Mr. Lindholm's mother surely has many wonderful
qualities, but we doubt anyone would consider her a public interface
to the Java Runtime Interpreter.
By contrast, JNI certainly is an interface to the Java Runtime
Interpreter -- a point Microsoft does not contest. JNI's predecessor,
a native method interface called "NMI," was part of the JAVATM
technology when the TLDA was executed and was included in Sun's first
shipment of the JDK to Microsoft. Sueltz Decl., ¶ 7; Lindholm Reply
Decl., ¶ 8. Also, unlike Mr. Lindholm's mother, native code
interfaces are specifically referenced in the Java Virtual Machine
Specification. Lindholm Reply Decl., ¶¶ 14-19. Microsoft has no
valid argument: JNI is part of an Upgrade within the scope of the
definition of "AAPI."
6. Since JNI is not a Supplemental Java Class, Microsoft does
not have discretion whether to distribute JNI with its Products.
Microsoft suggests that it is has "sole discretion" whether to
include "enhancements to the AAPI," such as JNI, based on Section
2.7(a) of the TLDA governing Supplemental Java Classes. Opp. at 9-10.
Section 2.7(a) of the TLDA, however, is inapplicable. Microsoft has
"sole discretion" only whether to include "one or more Supplemental
Java Classes in its Products." TLDA at § 2.7(a). "Supplemental Java
Classes" are defined as "the Java classes that SUN delivers to
Licensee after the Effective Date." Id. at § 1.23. JNI is not a
"Java class," and thus, cannot be a "Supplemental Java Class."
Microsoft presents no evidence indicating that JNI is a Java
class; it does not even claim JNI is a Java class. In fact,
Microsoft's Brad Silverberg admitted JNI is not a Supplemental Java
Class:
Q. . . . . Is JNI a class?
. . . .
A. My understanding is no, it's not a class.
Q. (By Mr. Batchelder) And therefore, it's not a supplemental class?
A. That was my understanding.
Day Reply Decl., Exh. D [Silverberg Tr. at 61]. Microsoft's suggestion that Section 2.7(a) justifies its exclusion of JNI is therefore without merit.
7. Microsoft does not have the "sole right" to define native
code interfaces like JNI.
Emblematic of Microsoft's effort to elevate self-serving parol
evidence over the text of the TLDA, Microsoft claims: "The final
agreement grants Microsoft the sole right to define the native
interfaces to Microsoft's Java Reference Implementation." Opp. at 11.
Microsoft fails to cite any TLDA provision to support this claim,
instead relying exclusively on after-the-fact recollection of its own
employee about Microsoft's intent and Sun's alleged statements during
the negotiations. Id.
Microsoft's failure to cite the contractual basis in the TLDA for
its supposed "sole right to define the native interfaces" exposes the
fallacy of its argument. Nowhere does the TLDA state that Microsoft
has the "sole right" to define native interfaces like JNI. Patch
Reply Decl., ¶ 33. Nor has Microsoft identified any provision of the
TLDA that is "reasonably susceptible" to such an interpretation.
Microsoft's "evidence" about what Sun allegedly said during the
negotiations or what Microsoft employees thought or intended consist
entirely of self-serving, after-the-fact "recollections" that must be
excluded as a matter of law.
Even if the Court were to consider Microsoft's evidence, it would
not withstand scrutiny. Microsoft agreed that "the Reference
Implementation VM, and any upgrades thereto, shall include the
necessary source code to implement the functionality of the Java
Runtime Interpreter." TLDA at § 2.9(b) (emphasis added). The TLDA
describes "Interfaces to the Reference Implementation VM" as including
"native code interfaces," and provides for situations where "SUN may
wish to suggest that [Microsoft] modify the ... interfaces to the
Reference Implementation VM in a substantive way which cannot be
adequately expressed through the Test Suites." Id. at § 2.9 (e) & (f)
(emphasis added). Since Section 2.9(f) specifically addresses
situations where the Test Suites do not "adequately express" Sun's
modifications to the Reference Implementation VM, the parties must
have intended that interfaces to the Reference Implementation VM, such
as native code interfaces like JNI, would be subject to Sun's Test
Suites.
The draft agreements and final TLDA support that conclusion, and
demonstrate that while Sun granted Microsoft the right to create
interfaces to its Java virtual machine, Sun always retained the right
to test for conformance to native code interfaces that Sun specified.
Patch Reply Decl., ¶¶ 30-50. As reflected in the final TLDA as well
as the drafts proposed by Microsoft, the parties understood that
Microsoft's right to define its own interfaces was always subject to
the requirement of passing Sun's Test Suites. Id., ¶¶ 49-50.
D. The TLDA Does Not Grant Microsoft The Right To Distribute
Compiler Products Which Fail Sun's Test Suites.
Even if the compilers in Microsoft's SDKJ 2.0 and 3.0 and Visual J++ 6.0 products fail the JCK1.1a Test Suite, Microsoft claims its failure is excused because "Microsoft's products do in fact have a mode that enables them to pass the Java Language Test Suite." Opp. at 17. Section 2.6(b)(iv) of the TLDA states in relevant part:
. . . Licensee agrees that any new version of a Product that includes the Java Language compilation function that Licensee makes commercially available to the public after the most recent Compatibility Date shall include a mode which a Tool Customer may use to permit such product to pass the Java Language Test Suite that accompanied the Significant Upgrade.
According to Microsoft, this "mode" language gives it the unfettered
right to make any changes to the JAVATM language it wants, as long as
its compilers also contain a mode which will pass the Test Suite.
Opp. at 17. Microsoft's argument is wrong on two scores. First,
Microsoft's interpretation of section 2.6(b)(iv) conflicts with the
stated purpose of the TLDA and Microsoft's representations during the
negotiations. Second, even were the Court to adopt Microsoft's
strained construction, the mode switch contained in Microsoft's
compilers does not enable them to generate output that passes the JCK
1.1a test suite. Hankinson Decl., ¶¶ 8, 37-38.
The mode language in section 2.6(b)(iv) does not grant Microsoft a
license to change the JAVATM language. It only allows Microsoft to
include in its compilers the ability to compile code for prior,
compatible versions of the JAVATM technology that were incorporated in
earlier products. Baratz Reply Decl., ¶¶ 15-21; Patch Reply Decl., ¶¶
62-68.
Section 2.6(b)(iv) supports this construction because it is
limited to instances where a Significant Upgrade has occurred. If
Microsoft distributes a Product with a compiler function "after the
most recent Compatibility Date," it shall include a mode that permits
the Product to pass the Java Language Test Suite "that accompanied the
Significant Upgrade." TLDA at § 2.6(b)(iv). By limiting § 2.6(b)(iv)
to the context of Significant Upgrades, the parties indicated the
"mode" language was to allow Microsoft's compilers to support earlier
versions of the JAVATM technology.
The negotiation history supports this construction. During
negotiations, Sun repeatedly emphasized the need for Microsoft's
contractual commitment to upgrade each of its products to conform to
the latest version of the JAVATM technology as and when released by
Sun. Baratz Reply Decl., ¶ 19. In response, Microsoft initially
proposed that it would agree to incorporate in its runtime and
compiler implementations a "mode" that would pass the latest
compatibility test. Patch Reply Decl., ¶ 62. Sun expressed "great
concern" to Microsoft about this language and rejected Microsoft's
proposal, insisting that Microsoft upgrade each runtime product to
include only the latest version of the technology. Id., ¶ 63.
Microsoft ultimately agreed, as reflected in section 2.6(a)(vi) of the
TLDA. Id., ¶ 65.
As to compiler implementations, however, Microsoft argued that it
may wish to continue to distribute compilers that could compile for
prior, outdated versions of the technology to support products
Microsoft had previously distributed (i.e., earlier versions of its
browsers and operating systems). Id., ¶ 66. After Microsoft assured
Sun that the purpose of the "mode" language was to let Microsoft
include a mode that would pass Sun's current compatibility test suite,
as well as modes that had previously passed the prior test suites for
earlier versions of the technology, Sun agreed to the language in
section 2.6(b)(iv). Id., ¶ 67; Baratz Reply Decl., ¶ 20. Microsoft
never suggested to Sun that the "mode" provision would allow Microsoft
to modify, pollute, or "extend" the JAVATM language. Patch Reply
Decl., ¶ 68; Baratz Reply Decl., ¶ 21. The failure of Microsoft's
SDKJ 2.0 and 3.0 and Visual J++ 6.0 products to pass the JCK 1.1a Test
Suite is not excusable.
In any event, even if the Court were to adopt Microsoft's
construction, Microsoft's compiler products still fail to pass Sun's
JCK 1.1a test suite. Hankinson Decl., ¶¶ 37-38.
E. Sun's Copyright Infringement Claim Is Based On Microsoft
Exceeding The Scope Of Its License, Not On Breach Of Contract.
Microsoft claims that Sun's motion is based on a "breach of a
covenant" and that "[t]o state a copyright infringement claim, Sun
must show that the breach is a condition precedent to the license."
Opp. at 17. Microsoft misstates both Sun's position and the law.
As Sun's opening brief made clear, Sun's motion is based on
Microsoft's unlicensed distribution of infringing product, not on
breach of a covenant or condition precedent. Motion at 13. Section 2
of the TLDA defines the scope of Microsoft's license. Unlike other
provisions of the TLDA (e.g., payment of licensee fees), the
compatibility requirements of section 2.6 expressly limit the scope of
Microsoft's license. By failing to comply with the provisions of
section 2.6, Microsoft acts outside the scope of its license and is
treated like any other copyright infringer.
Sun is not required by law to show Microsoft breached a condition
precedent to the license. Microsoft's opposition completely ignores
S.O.S., Inc. v. Payday, Inc., 886 F.2d 1081, 1087 (9th Cir. 1989),
cited in Sun's opening brief, which plainly holds, "A licensee
infringes the owner's copyright if its use exceeds the scope of the
license." Similarly, when citing the authority for the alleged
requirement that Sun must show breach of a condition precedent,
Microsoft curiously does not cite the three-part test from Rano
v. Sipa Press, Inc., 987 F.2d 580, 586 (9th Cir. 1993):
Under well-settled copyright law, Rano would be able to claim
copyright infringement if Sipa exceeded the scope of the licensing
agreement, breached a covenant or condition, or breached the agreement
in such a substantial and material way as to justify rescission.
(emphasis added; internal citations omitted). Microsoft's extended
meditations on implied versus express conditions, rescission,
reversion and termination are therefore utterly irrelevant.3
II. EVEN THOUGH SUN IS LEGALLY ENTITLED TO AN ORDER ENJOINING THE
SALE OF ALL INFRINGING MICROSOFT PRODUCTS, SUN IS WILLING TO MODIFY
ITS REQUESTED RELIEF TO MINIMIZE THE INCONVENIENCE TO THIRD PARTIES
REGARDING WINDOWS 98.
Since Sun has made a strong showing of likely success on the
merits of its claim of copyright infringement, Sun is entitled to a
presumption of irreparable harm, and "the balance of hardships issue
cannot be accorded significant -- if any -- weight in determining
whether a court should enter a preliminary injunction to prevent the
use of infringing material." Cadence Design Sys., Inc. v. Avant!
Corp., 125 F.3d 824, 830 (9th Cir. 1997), cert. denied, 118
S. Ct. 1795 (1998). Microsoft "cannot complain of the harm that will
befall it when properly forced to desist from its infringing
activities." Triad, 64 F.3d at 1338; see also Cadence Design, 125
F.3d at 830.
Microsoft has not rebutted Sun's presumption of irreparable harm.
Microsoft's massive distribution of incompatible (and therefore)
infringing products threatens to rob Sun and all of its other
licensees of the substantial time and capital invested in developing
the JAVATM technology. See Apple Computer, Inc. v. Formula Int'l,
Inc., 725 F.2d 521, 525-26 (9th Cir. 1984). Microsoft's actions
exceed the scope of the license in a manner that directly frustrates
Sun's central objective -- maintaining compatibility among JAVATM
language based products. By distributing incompatible products,
Microsoft fragments the JAVATM programming environment and destroys
cross-platform compatibility. Sueltz Decl., ¶¶ 2-11; Burton Decl., ¶¶
3-7.
Sun has not unreasonably delayed in seeking relief. Sun filed
this motion as soon as it had an opportunity to review Microsoft's
source code for evidence of copying and before both Microsoft's Visual
J++ 6.0 and Windows 98 were in final release. See Forry,
Inc. v. Neundorfer, Inc., 837 F.2d 259, 267 (6th Cir. 1988) (holding
22-month delay in filing copyright infringement action did not rebut
presumption of irreparable harm).
Since Sun filed its motion, Microsoft has begun shipment of
Windows 98. Although Sun believes it is legally entitled to an order
enjoining the distribution of Windows 98, Sun appreciates that the
retail channels have been flooded with this incompatible product and
that it is now in the hands of many innocent retailers and customers.
To minimize the harm to these third parties, Sun is willing to modify
its requested relief with respect to Windows 98 and IE 4.0. Sun
requests an order enjoining Microsoft from distributing copies of its
Windows 98 and IE 4.0 products 90 days after the date of the Court's
order unless each such product includes a JAVATMtm) runtime
implementation that passes Sun's compatibility test suite. For
Windows 98 and IE 4.0, this means that Microsoft must implement JNI in
a manner that passes the JCK 1.1a test suite. In the interim,
Microsoft would be enjoined from distributing its incompatible Windows
98 and IE 4.0 products unless and until it takes reasonable steps to
notify its customers of the Court's order and prominently posts notice
of the corrective steps to be taken on its website. If Microsoft
could show good cause that more than 90 days was needed, Microsoft
could seek a reasonable extension from the Court.4 Sun does not seek
recall of Windows 98 and IE 4.0 products which previously were
distributed.
As for Microsoft's tool products, Visual J++ 6.0 and SDKJ 2.0 and
3.0, Sun seeks an order immediately enjoining further distribution
until such products successfully pass Sun's compatibility test suites,
including the tests for JNI, the Compiler Output Requirement test, and
any other required test or requirement these products currently fail.5
| Dated: October 20, 1998 |
DAY CASEBEER MADRID
WINTERS & BATCHELDER LLP
By:__________________________________
Lloyd R. Day, Jr.
Attorneys for Plaintiff
SUN MICROSYSTEMS, INC.
|
FOOTNOTES
1 Microsoft also does not
dispute that all of these products generated 107 failures when Sun
performed the JCK 1.1a "Signature Test" in May of this year. While
Microsoft has since corrected the Signature Test failures, its
products still do not pass the JCK 1.1a test suite. back to text
2 The
TLDA is attached as Exhibit A to the Reply Declaration of Lee Patch.
back to text
3 Microsoft's half-hearted
claim of waiver based on Sun's acceptance of licensee fees also can be
quickly dispatched. The TLDA provides that the Agreement may not be
"waived, in whole or in part, except by a written instrument signed by
the parties." TLDA at § 12.3; see also United States v. King Features
Entertainment, Inc., 843 F.2d 394, 399 (9th Cir. 1988). back to text
4 The
90-day period is based on Microsoft's own estimate of the time
required to develop, test, document and redistribute a revised version
of Windows 98, Opp. at 22; Akerlind Decl., ¶ 12, as well as the time
required by Microsoft to develop implementations that passed the
Signature Test following the Court's March 24, 1998 Order. back to text
5 Since
Microsoft's Developer Tools Division Marketing Manager estimates that
the annual sales for its JAVATM tool
product have been less than 10 million dollars and Visual J++ 6.0 has
not been placed in "final release," Microsoft will suffer little
disruption from such an order. back
to text
*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
|