|
Tech Law Journal |
 |
| News, records, and analysis of legislation, litigation, and regulation affecting the computer, internet, communications and information technology sectors | |
|
|
|
| |||||
|
McDONALD & QUACKENBUSH, P.S. ORRICK, HERRINGTON & SUTCLIFFE LLP RUBY & SCHOFIELD MICROSOFT CORPORATION Attorneys for Defendant UNITED STATES DISTRICT COURT
FILED UNDER SEAL PURSUANT TO PROTECTIVE ORDER
TABLE OF AUTHORITIES FEDERAL CASES Brown Bag Software v. Symantec Corp., 960 F.2d 1465 (9th Cir. 1992) 20 Effects Associates, Inc. v. Cohen, 908 F.2d 555 (9th Cir. 1990) 18 Entertainment Research Group, Inc. v. Genesis Creative Group, Inc., 122 F.3d 1211 (9th Cir. 1997) 20 Fantastic Fakes, Inc. v. Pickwick International, Inc., 661 F.2d 479 (5th Cir. 1981) 17 Fosson v. Palace (Waterland), Ltd., 78 F.3d 1448 (9th Cir. 1996) 19 Peer International Corp. v. Pausa Records, Inc., 909 F.2d 1332 (9th Cir. 1990) 17 Rano v. Sipa Press, Inc., 987 F.2d 580 (9th Cir. 1993) 13, 17, 19 Sega Enterprises, Ltd. v. Accolade, Inc., 977 F.2d 1510 (9th Cir. 1992) 13, 21 USAR Systems, Inc. v. Brain Works, Inc., 887 F. Supp. 84 (S.D.N.Y. 1995) 23 Whittaker Corp. v. Execuair Corp., 736 F.2d 1341 (9th Cir. 1984) 23 STATE CASES Clement v. Smith, 16 Cal. App. 4th 39 (1993) 19 Plescia v. Plescia, 59 Cal. App. 4th 23 Whitney Investment Co. v. Westview Development Co., 273 Cal. App. 2d 594 (1969) 21 FEDERAL STATUTES 17 U.S.C. § 410(c) 20 STATE STATUTES Cal. Civ. Code §1641 16 Cal. Civ. Code §1643 16 MISCELLANEOUS 3 Nimmer on Copyright, § 10.15[A] (1997) 17, 19 I. INTRODUCTION Sun Microsystems, Inc.’s ("Sun") motion for preliminary injunction for copyright infringement is built on a theory that if Microsoft’s products do not pass a test in Sun’s JCK 1.1a test suite, Microsoft’s license is extinguished and its products are infringing. This theory ignores the fact that the Technology License and Distribution Agreement ("TLDA") specifically describes the tests to be passed and that Microsoft’s products do pass those tests. Sun does not have unlimited power to force Microsoft to adopt any Sun technology-Java based or not-merely because a test can be devised to check for it. While JCK 1.1a may include some tests that belong in the "Java Test Suite" or the "Java Language Test Suite" specified in the TLDA, other tests in JCK 1.1a exceed the TLDA’s scope of testing. Sun’s theory should be rejected and its motion denied. Despite its rhetoric, Sun’s motion is not about cross-platform compatibility. Microsoft’s products provide full compatibility for programs written in Java. Java programs written on Sun’s Java implementation run on Microsoft’s products, and programs written with Microsoft’s tools run on other Java implementations. By contrast, Sun’s Java Native Interface ("JNI")-which Sun tests for in JCK 1.1a-destroys cross-platform compatibility. Because JNI is used to write platform-dependent code, Sun’s JNI is for programs that will not be cross-platform compatible. Innovation by programmers is a matter of competitive free choice and has always been supported by the industry. Innovation in the Java programming language was expected and welcomed by both Sun and Microsoft in the TLDA. Sun’s motion seeks to deny software developers the tools they need to develop high performance programs for their customers’ needs. Since filing its original brief, Sun has filed declarations attacking Microsoft for adding new features to its Java implementations. Microsoft has not breached the TLDA. Even if it had, Sun could not establish copyright infringement. Because passing Sun’s tests is not a condition precedent to Microsoft’s license, failing to pass these tests gives rise to an action for breach of contract, but not for copyright infringement. Furthermore, Sun cannot establish an infringement claim because the presumption which attaches to its copyright registrations is rebutted. There is no evidence that Sun is being irreparably harmed by any action of Microsoft. Microsoft, its customers, and end users would be irreparably harmed if Sun’s motion were granted. Sun’s unjustified delay in bringing its motion rebuts any presumption of irreparable harm. II. BACKGROUND: CHANGES IN SUN’S Since filing its motions, Sun has substantially revised its original claims regarding JCK test failures and, in several cases, substituted new claims in their stead. The July 30, 1998 Supplemental Declaration of Carla Schroer, served one week before Microsoft’s Opposition was due, sets forth the latest version of Sun’s claims. For the convenience of the Court, the following is a summary of the changes in Sun’s contentions that have occurred since Sun filed its motion.
Sun filed this motion prematurely, against beta (pre-release) versions of Microsoft’s products. The TLDA specifically exempts Microsoft’s beta products from testing requirements. Ex. 1, §§ 2.6(a)(vi), 2.6(b)(iv) (TLDA). The final versions of Microsoft’s products pass Sun’s JCK Signature Test. Sun has conceded this fact. Supplemental Schroer Decl. (July 30, 1998), Ex. A. With the exception of Sun’s JNI tests, which are non-Java tests that Microsoft is not required to pass under the TLDA, Microsoft’s products pass every test that Sun’s motion alleged was failed.
On June 17, 1998, Sun served a new Schroer declaration claiming that Microsoft’s products were required to include a program, "rmic," referred to by Sun as an "RMI Compiler." Supplemental Schroer Decl. (June 17, 1998). Sun provided no prior notice of this claim, either in this litigation or pursuant to the TLDA’s notice requirements. Ex. 21 at 480:16-481:1, 481:17-482:15 (Schroer Depo.). The program was originally delivered to Microsoft with JDK 1.1 in February, 1997. Ex. 7 at pp. 51:13-53:5 (Bowen Depo.). The JDK 1.1 documentation identifies "rmic" as a "stub converter." Id. Sun now asserts that that there are 54 tests for "rmic" which are failed because Microsoft’s products do not contain "rmic." Sun did not in fact run the tests. Ex. 21 at 210:10-211:6 (Schroer Depo.). Furthermore, as Sun concedes, rmic consists of Java classes delivered after the TLDA. Id. pp. 422:19-423:3, 425:23-426:3 (Schroer Depo.). As such, "rmic" consists of Supplemental Java Classes and Microsoft is not required to include Supplemental Classes in its products. Ex. 1, §§ 1.23, 2.7(a); Ex. 2 at 16. Microsoft wrote Sun on July 1, 1998 to confirm that if Sun delivers "rmic" to Microsoft pursuant to TLDA section 2.7(a), Microsoft will post "rmic" as required by section 2.7(a). Muglia Decl. ¶ 32. Sun’s concession that its RMI Compiler constitutes Supplemental Java Classes renders moot Sun’s last minute contention that Microsoft fails RMI Compiler tests. Ex. 2 at 4:27-5:1, 16:4-7. If Sun disagrees, Microsoft requests an opportunity to file a supplemental response directed to the "RMI Compiler," inasmuch as it is also undisputed that compliance with the Java Language Specification does not require an "RMI Compiler." Ex. 21 at 252:24-253:12 (Schroer Depo.); Ex. 1 (TLDA), §§ 1.13, 2.6(b)(iv).
SDKJ 2.0, SDKJ 3.0 and VJ++6.0 contain Microsoft Java compilers. As is common in compilers, Microsoft’s compilers implement advanced languages features. In particular, Microsoft’s compilers have an enhanced mode in which the user has available three families of compiler directives and two keywords. On June 17, 1998, Sun asserted for the first time that the output of Microsoft’s compilers "failed to execute properly with the JDK 1.1 virtual machine." Although the test suite contained no corresponding test, Sun asserted the documentation implied such a requirement. Schroer Decl. (June 17, 1998). ¶ 5(a). Sun has not provided evidence of any test failure it attributes to Microsoft’s enhancements. Examination of the documentation referred to shows the "test" is to be used only "if applicable." Schroer Decl. (6/17/98), Ex. A, at 07001187. As explained in the declarations accompanying Microsoft's Opposition, Microsoft’s products have a mode switch to turn these enhancements on and off as contemplated by section 2.6(b)(iv). Contrary to Sun’s assertion, the output of Microsoft’s compilers execute properly whether or not the mode switch is set. Huhns Decl. ¶¶ 59-60; Lee Decl. ¶¶ 12-14.
Ms. Schroer’s June 17, 1998 declaration also raised for the first time test failures relating to Microsoft’s SDKJ 2.0. SDKJ 2.0 is an earlier version of SDKJ 3.0, and has been available to Sun since at least September, 1997. Ms. Schroer’s declaration identified the same claims against SDKJ 2.0 that had been asserted in regard to SDKJ 3.0. Thus, the arguments in this brief that apply to SDKJ 3.0 apply equally to SDKJ 2.0.
Ms. Schroer’s July 30, 1998 declaration asserts for the first time that the current SDKJ 2.02 product fails two compiler tests. One of these tests is in fact passed by SDKJ 2.02, and the failure of the other test is caused by a program bug that was fixed in SDKJ 3.0. Golde Decl. ¶¶ 3-4. Microsoft will fix this bug in SDKJ 2.02 as well. Id. III. THE ISSUE All of Sun’s claims based on Microsoft’s alleged test failures raise the fundamental issue of whether the test fits the TLDA’s requirements either (i) "for validating that products which interpret Java bytecodes comply with the SUN specification of the AAPI" (Java Test Suite, § 1.15) or (2) "for validating that products which compile the Java Language comply with the then-current Java Language Specification." (Java Language Test Suite, § 1.13). Sun contends its Java Native Interface ("JNI"), an interface for programming in languages other than Java, may be tested for as part of the "specification of the AAPI." Sun’s proposed interpretation of the definition of "AAPI" in section 1.1 is tortured and leads to an unreasonable and arbitrary result. The AAPI was understood by the parties to refer to the "Applet API," not an interface like JNI. For the reasons explained below, an "Applet API" and a native code interface are things entirely different. Sun does not dispute that Microsoft’s products have a mode which allows the products to pass Sun’s Language Test Suite. The TLDA permits Microsoft’s Java compiler implementation to include multiple modes, so long as at least one mode passes Sun’s tests. Furthermore, Microsoft’s evidence demonstrates that even in the absence of a mode switch, Microsoft’s compiler products do not violate either the Java Language Specification or the Java Virtual Machine Specification. IV. STATEMENT OF FACTS
Java Applets are small programs written in Java and embedded in a web page. Huhns Decl., ¶ 20. When the web page is downloaded over a net to an end user, the applet executes in a Java virtual machine contained in the end user’s web browser. Id. In 1995, applets had become hot Internet features. The primary use of Java was to write applets. Id. Java applets consisted of bytecodes and depended on the applet API, a Java API that the applet writer could assume would be available when the applet was downloaded. Id. Sun hoped to leverage its Java applet technology into an Internet operating system (to supplant Microsoft Windows) and computer processor (to supplant Intel chips). Exs. 67, 83. An important step in this process was to establish Java as the universal language of the Internet. Ex. 67 at 2, 10, 22. Gaining support from Microsoft for Java applets was a giant advance toward this goal. Ex. 48, Ex. 17 at 60:5-62:13 (Muglia Depo.). Microsoft wanted to provide its browser customers with the ability to run applets. Ex. 12 at 57:10-21 (Heinen Depo.). Microsoft was independently developing its own Java technology at this time, but was interested in licensing the Java applet technology from Sun to reduce its time to market. Ex. 12 at 143:12-144:8, 267:14-268:4 (Heinen Depo.); Muglia Decl. ¶ 3.
In December 1995, after extensive negotiations, Sun and Microsoft entered into a Letter of Intent ("LOI"). Ex. 36. The LOI provides that Microsoft would agree to AAPI compatibility. Id. Before signing the LOI, Microsoft was careful to determine what was meant by "AAPI." Bill Joy, one of Sun’s primary negotiators, assured Microsoft that the AAPI was the APIs needed by an applet. Ex. 63 at 2. According to Joy, the "applet APIs" and the "AAPI" are the same thing: Q.Well, did you mean to describe what was going to be contained in the AAPI? A.Well, the applet APIs are the AAPI, aren’t they? Applet-AAPI means applet application programming interface, so applet API is a partial contraction of that phrase. Ex. 13 at 286:18-23 (Joy Depo.). Mr. Joy reassured Microsoft: "[T]he applet api’s are by definition platform-independent, and this limits their size and scope." Id. Sun intended that Microsoft rely on these representations. Ex. 13 at 290:19-291:25 (Joy Depo.). The LOI acknowledged "Sun’s goal of maintaining compatibility with publicly available Java applets." Ex. 37 at 4 (emphasis added). The LOI also reflected a fundamental understanding about the limit of Microsoft’s compatibility obligation. Microsoft was concerned that Sun would use compatibility tests and the AAPI as a "trojan horse" to eventually force Microsoft to ship a competing operating system. Ex. 18 at 149:21-150:4 (Patch Depo.); Ex. 13 at 274:14-24 (Joy Depo.). To protect itself, Microsoft negotiated specific rights in the LOI: Q.Did you take steps to guard against there being a Trojan horse? AYes, I did. QDid those steps include making sure that Microsoft had sole control or sole discretion to decide what additions were made to its implementations and packaging of the AAPIs? AYes, . . . . Ex. 12 at 340:23-341:8 (Heinen Depo.). By its terms, the LOI was not a final agreement. The parties stated their intent, however, to "negotiate in good faith a definitive agreement consistent with what is outlined herein." Sun and Microsoft signed the TLDA on March 11, 1996.
The term "Applet API" had a general meaning in connection with Sun’s Java technology at this time. As used by Sun in describing its JDK 1.0, delivered by Sun to Microsoft soon after the TLDA was signed, "Applet API" referred to the Java packages listed in section I(A) of Exhibit A of the TLDA: This 1.0 release of the Java Developer’s Kit (JDK) lets you write applets that conform to the Java applet API . . . What is the final applet API? The final applet API consists of the following packages: java.lang, java.util, java.io, java.net, java.awt, java.awt.peer, java.awt.image, and java.applet. Huhns at ¶ 21, Exhibit B. In early 1996, Sun published a white paper for developers on its web site which emphasized the same thing. The Java Applet API, also known as the Java Base API, … includes all the classes in the java package: java.lang, java.util, java.io, java.net, java.awt, and java.applet. (Notice that the Java Applet API is the full set of APIs available in version 1.0.2 of the Java Development Kit from JavaSoft.) Huhns at ¶ 21, Exhibit C. It is not coincidental that Sun’s JDK documentation and its technical communications to developers define the Applet API the same way: Q."Write Once Run Anywhere" depends upon the operative meaning of all the developers being the same, doesn’t it? A.Yes. Q.And it’s that compatibility that you would be concerned about when you’re talking about AAPI compatibility, right? A.Absolutely. Ex. 11 at 124:17-24 (Gosling Depo.). This meaning of "AAPI" comports with the meaning of that term as understood by both Sun and Microsoft. Ex. 17 at 108:23-109:17 (Muglia Depo.); Ex. 13 at 277:11-278:3 (Joy Depo.).
On February 21, 1996, Microsoft sent a draft TLDA to Sun. The draft defined "Applet Application Programming Interface" or "AAPI" in language consistent with the LOI, i.e. as the Java Applet APIs. The proposed language read: 1.1"Applet Application Programming Interface or AAPI" means the application programming interface to the Technology, including the interface to the Applet Classes (as defined below). 1.2"Applet" means a Java application which (i) runs on the AAPI and (ii) consists of Java bytecodes executable by the Java Runtime Interpreter (but does not include or incorporate the Java Runtime Interpreter). 1.3"Applet Classes" means the Java classes listed in Exhibit A. Ex. 60. Sun thought this proposed AAPI language meant only the Java Applet APIs, just as Microsoft intended. Sun negotiator Mike Clary thought the proposed language too narrow because it failed to mention the Java Virtual Machine Specification and the Java Language Specification. Ex. 8 at 147:14-148:4 (Clary Depo.). Sun indicated to Microsoft: . . . it was not a definition that we were comfortable to accept because it might be interpreted as being too narrow . . . that the entirety of what was expressed in the 1.1 definition . . . as being too narrow because, primarily the specific reference to the interface to the applet classes left out a specific reference to the virtual machine or the runtime interpreter. Ex. 18 at 86:4-23 (Patch Depo.). This same language was submitted by Microsoft to Sun on March 5, 1996 with a cover letter that stated "as we discussed last night, this draft reflects the original terms of the LOI." Ex. 5 at 351:3-8 (Baratz Depo.). Microsoft’s March 10, 1996 draft included the same AAPI language. Ex. 62, § 1.1. In the final negotiations, the parties narrowed the language of section 1.1(a). In addition, the parties added new sections 1.1 (b), (c) and (d) to include relevant portions of Sun’s specifications. Section 1.1(b) referred to the "bytecode" specification in the Documentation entitled "OEM Virtual Machine Specification." Section 1.1(c) referred to the Java language specification in the Documentation entitled "OEM Java Language Specification." Section 1.1(d) referred to the OEM Java API Specification "as modified by Sun during the term of this Agreement." The language of section 1.1(a) was narrowed: First, "AAPI" was limited to "public" APIs. Second, "AAPI" was limited from the "Technology" to the "Java Applet Environment reflected in the Technology." Third, the definition was changed to refer only to Technology "as identified in Exhibit A." This last change had the effect of excluding any Upgrades from the public application programming interfaces encompassed by section 1.1(a) of the definition of "AAPI." Compare TLDA § 1.25 (defining "Technology" to include "Upgrades") with TLDA Ex. A (defining Java Applet Environment without reference to "Upgrades"). According to Sun’s Rule 30(b)(6) witness on the meaning of "AAPI," JNI is not included within the meaning of subsections 1.1(b), (c) or (d). Ex. 15 at 422:15-24 (Lindhom Depo.). Sun’s contention that JNI is within the definition of "AAPI" therefore rests solely upon a claim that section 1.1(a) includes JNI. However, JNI is not a Java interface, and it is not part of the AAPI. The history of the definition of AAPI set forth above shows that section 1.1(a) was intended to narrowly define only the Java applet interfaces. JNI simply cannot be shoehorned into the definition of AAPI. Huhns ¶¶ 44, 45. JNI tests do not belong in the JCK Test Suite.
The provision in the LOI giving Microsoft sole discretion to determine whether to include enhancements to the AAPI in its packaging and implementation became section 2.7(a) of the TLDA. Ex. 8 at 84:22-90:10 (Clary Depo.). Any Java class delivered to Microsoft after the effective date of the TLDA is a Supplemental Java Class. Ex. 1, § 1.23. Section 2.7(a) provides that Microsoft has no obligation to implement or ship such Supplemental Java Classes. Id., Ex. 1, § 2.7(a). Sun’s new Java classes must run on the then current Java Reference Implementation. Ex. 51. In order to add a new Java API to the AAPI, it is necessary to create a new Java class. Huhns Decl. ¶ 38. Consistent with the LOI, if Microsoft decides not to include the new Java classes in its products it must make them available through alternative distribution. Id.
JNI is identified in the Java Native Interface Specification as a "native programming interface." Deutsch Decl. (May 11, 1998), Ex. 28, p. 1. "If you use JNI, you destroy portability. The JNI should only be used as a last resort under special circumstances. Most programmers don’t need it and won’t use it." Ex. 32 (SunSoft publication), at 252. A native method is platform-dependent code. A method that is native is implemented in platform-dependent code, typically written in another programming language such as C, C++, FORTRAN, or assembly language. Ex. 30, § 8.4.3.4 Applet programmers cannot create new native methods in their applets or ask to load libraries of native methods when their applet is run. Huhns Decl. ¶¶ 24-27 & Ex. D; Ex. 32. JNI is irrelevant to an Applet programmer. JNI is a native programming interface not a Java programming interface. Huhns Decl. ¶ 3. Sun acknowledged: We definitely need an end of life story for the old native interface…Note that this doesn’t affect normal applets because they can’t load native code anyway. Ex. 54 (emphasis added). JNI is presently implemented as a native programming interface, generally as a C API. Ex. 11 at 55:8-14; Huhns 37. Programmers who want to write cross-platform compiler programs write in Java and do not use native methods. See Huhns Decl. ¶¶ 4, 22.
As part of the negotiation of the final TLDA, Sun proposed language granting it control of the interfaces to Microsoft’s Java Reference Implementation. Ex. 18 at 77:21-78:11 (Patch Depo.), Ex. 61. Sun’s language was rejected. The final agreement grants Microsoft the sole right to define the native interfaces to Microsoft’s Java Reference Implementation. Ex. 17 at 110:20-119:5 (Muglia Depo.). Microsoft would not have signed a TLDA that gave Sun control of the native interfaces. . . . Mike [Clary] came in from Alan [Baratz’] office, after having talked with Bill Joy. And he said, I just got done talking to Bill Joy. Bill believes that Sun should reserve the right to define its own native code interfaces. Now, when he said that, my heart sank. It’s 3:00 in the morning . . . This was a deal breaker to us. There was no question that we and only Microsoft retained the right to define these native face [sic] interfaces . . . Alan, to his great credit, said Mike, we have been over that many times before. We know that only Microsoft has the right to define these interfaces. Let’s move on. Whereupon, I breathed a sigh of relief . . . . Ex. 17 at 117:14-118:10 (Muglia Depo.).
Compiler vendors typically provide compiler-specific directives and language extensions to create a competitive product. Lee Decl., ¶ 13. Microsoft’s right to create competitive compilers in this fashion is recognized in section 2.6(b)(iv). Microsoft’s products will be deemed to have passed the Java Language Test Suite so long as the compilers in its products "include a mode" in which the products pass the Java Language Test Suite. Id. Microsoft’s compiler products contain a readily accessible mode switch that disables all Microsoft specific directives and keywords. Ex. 10 at 230:15-231:10 (Deutsch Depo.); Lee Decl. ¶¶ 12, 30 ; Huhns Decl. ¶ 58.
It is common in the computer industry for the compiler in a software development tool to contain multiple "modes." Lee Decl. ¶¶ 26, 29, 32. Before a programmer compiles a computer program, he selects the mode he wants to use. Typically, one mode allows programmers to use language enhancements not available with the other mode, permitting more efficient or robust programming. Id. ¶ 26. Microsoft’s compiler is of this type. It contains one mode for standard compilation. It has another mode which offer developers additional features - three additional compiler directives and two additional keywords - that programmers can use to add functionality to their programs. Id. ¶¶ 5, 13, 30-32. The Microsoft-specific compiler directives are carefully designed so that source code containing them will still compile on non-Microsoft Java compilers, and source code written with non-Microsoft development tools will still compile properly on Microsoft’s Java compiler. Id. ¶ 4. Similarly, the Microsoft-specific keywords are designed so that they will not accidentally be processed by a compiler that does not understand them (thus ensuring that they will not be used by programmers who wish to write cross-platform compatible implementations), and they do not prevent source code written with non-Microsoft development tools from compiling properly on Microsoft’s Java compiler. Id. ¶¶ 43-45. Furthermore, regardless of which mode is selected in Microsoft’s Java compiler, the compiler produces output that fully complies with the requirements of the Java Language Specification and the Java Virtual Machine Specification, id. ¶¶ 36-42, and thus complies with the compatibility requirements of the TLDA.
Sun and Microsoft agreed in the LOI and the TLDA on Applet compatibility. Microsoft has delivered on that promise. The high degree of Java-related compatibility between Microsoft’s products and Sun’s specifications is quite impressive. Microsoft’s implementations appear to be among the most, if they are not in fact the most, compatible Java implementations available in the marketplace. So, for example,…if IBM wrote a bug-free word processing application tomorrow in the Java programming language and compiled it using the Sun Java compiler, that program would run on the Microsoft Java Virtual Machine. If the same word processing application were compiled using the Microsoft Java compiler, it would run on the Sun Java Virtual Machine. Lee Decl. ¶ 4. The high degree of compatibility found by Dr. Lee has also been recognized by independent observers of the computer industry. Ex. 24 at 139 ("The Microsoft Java environment came close to a perfect score on our compatibility tests…"). V. ARGUMENT Sun is not entitled to a preliminary injunction unless it can show either (1) probable success on the merits and the possibility of irreparable injury or (2) that serious questions are raised and the balance of hardships tips sharply in Sun’s favor. Sega Enterprises, Ltd. v. Accolade, Inc., 977 F.2d 1510, 1517 (9th Cir. 1992). Sun fails both tests.
There is no dispute that Sun and Microsoft entered into a license agreement, the TLDA, under which Microsoft is licensed to use Sun’s Java Technology for commercial purposes. Sun admits that a license provides the licensee with a valid defense to a copyright infringement claim. See Sun Brf. at 13; Rano v. Sipa Press, Inc., 987 F.2d 580, 584-85 (9th Cir. 1993). Sun argues, however, that Microsoft has given up its license rights by distributing products which fail to pass compatibility requirements of the TLDA. See Sun Brf. at 14. Microsoft has not breached its compatibility obligations. Microsoft’s products pass the Java Test Suite and the Java Language Test Suite-the only test suites required by the TLDA.
The TLDA records an agreement in which Sun, for payment of fees (§ 4.1), grants Microsoft a license to Technology. Ex. 1, §§ 2.1-2.3. As additional compensation to Sun, Microsoft licenses to Sun an implementation of the Technology for the Windows 32 platform, known as the Java Reference Implementation. Id. § 2.5. Sun may distribute the Java Reference Implementation freely and, to the extent it wishes to promote interfaces to the Java Reference Implementation that are different than Microsoft’s, can change those interfaces. Id. § 2.9(a). Sun periodically delivers Upgrades of the Technology to Microsoft. Id. § 3.1. Provided those Upgrades meet certain criteria, Microsoft agrees to return to Sun a Compatible Implementation, which upgrades the Java Reference Implementation. Id. §§ 2.6(a)(iii), 2.6(a)(iv). The Compatible Implementation must pass a Java Test Suite. Id. § 2.6(a)(iv). Microsoft’s obligation to incorporate Sun’s Upgrades in the Compatible Implementation is limited by the Java Test Suite that accompanied the Upgrade. Ex. 5 at 281:5-11 (Baratz Depo.). Compiler products are held to a different standard. Compiler products must have a mode which enables them to pass the Java Language Test Suite. Ex. 1, § 2.6(b)(iv). Both the Java Test Suite and the Java Language Test Suite are intended to be limited in scope by publicly available, well-defined specifications. "Java Test Suite" is defined in section 1.15 of the TLDA to be: 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. "Java Language Test Suite" is defined in section 1.13 of the TLDA to be: Sun’s publicly available test suites for validating that products which compile the Java Language comply with the then-current Java Language Specification. Microsoft’s products are not required to pass any test which is not properly part of Sun’s specification of the AAPI or the Java Language Specification.
Microsoft’s exclusion of JNI from its Java implementations does not violate the TLDA unless the JNI tests created by Sun are part of the "Java Test Suite" or the "Java Language Test Suite," as defined by the TLDA. They are not.
Under the definition of "Java Test Suite," Sun may only test for compliance with "the Sun specification of the AAPI." Ex. 1, § 1.15; Ex. 5 at 69:2-8 (Baratz Depo.); Ex. 17 at 91:17-92:19 (Muglia Depo.). As discussed above, JNI is not part of the AAPI. See supra pp. 7-9.
The TLDA provides that Sun can only test for compliance with the Sun "specification" of the AAPI, which consists of the three Documentation excerpts listed in TLDA sections 1(b), (c) and (d), and the "Java Language Specification." Ex. 1, §§1.13, 1.15. "The purpose of compatibility testing is to determine if a Java implementation conforms to the Java specifications." Ex. 56. None of these documents contains a specification for JNI or any other native code interface. Huhns Decl. ¶ 49; Ex. 21 at 220:8-17 (Schroer Depo.).
Sun ignores its public specifications and argues that the source code to the Technology, including Upgrades, is a contract "specification" as that term is used in the definition of Java Test Suite. Ex. 14 at 230:3-231:19 (Kannegaard Depo.). Sun then argues that it can test for JNI because it is part of an Upgrade to the Runtime Interpreter. However, the Runtime Interpreter is defined to be the program that implements the Java Virtual Machine, "as specified in the Java Virtual Machine Specification." TLDA §1.11. As stated in the previous section, JNI is not specified in any of the Sun specifications in the TLDA, including the Java Virtual Machine Specification. The difficulty with Sun’s argument is evident to the author of the Java Virtual Machine Specification: The problem with redefining ‘Java Virtual Machine’ to ‘that hairball of C code previously known as the Java runtime’ is that apart from the bytecodes and class file format, this definition traces an almost arbitrary line between the stuff we want to call the runtime and the stuff we don’t. Ex. 50. Once the boundary set by the Java Virtual Machine Specification is ignored, anything can fit the definition. Ex. 15 at 346:22-348:15 (Lindholm Depo.) (it is technically possible to package an image of Mr. Lindholm’s mother with the Runtime Interpreter source code). Alternatively, Sun attempts to stuff JNI into the AAPI box by treating section 1.1(a) as referring to any application programming interface, not just Java interfaces, resulting in a meaning that is "arbitrary and unconstrained." Huhns Decl. ¶ 47. Sun reaches this unreasonable interpretation by simply ignoring the word "Applet" in the TLDA, which qualifies "application programming interface" in the definition of "AAPI." Ex. 10 at 284:3-285:1 (Deutsch Depo.); Ex. 15 at 431:5-13 (Lindholm Depo.). In naming an API it is typical to use a word that describes the nature of the API. Huhns Decl. ¶ 33. The API that the parties were defining was identified by them as the Applet API. Ex. 13 at 286:18-23 (Joy Depo.). In construing a contract, "The whole of a contract is to be taken together so as to give effect to every part, if reasonably practicable, each clause helping to interpret the other." Cal. Civ. Code §1641. Microsoft’s interpretation of the meaning of AAPI is the reasonable interpretation that is consistent with Sun’s contemporaneous public statements about the meaning of AAPI. Huhns ¶¶ 20-22, 41, 47. Microsoft’s interpretation is also consistent with the representations Sun made to induce Microsoft to sign the LOI and the negotiation of the TLDA. Sun is asking the Court to reject a reasonable interpretation that is supported by the language of the TLDA and the circumstances surrounding its execution. The Court should not reject such an interpretation in favor of an unreasonable contract interpretation. Cal. Civ. Code §1643.
Sun’s testing requirements must be uniformly applied to all of Sun’s licensees. The Java Test Suites do not just test for compliance by Microsoft; they are publicly available tests that verify compliance by all products which "interpret Java bytecodes" or "compile the Java Language." Ex. 1, §§ 1.13, 1.15. Thus, a test which other licensees are allowed to fail, cannot be part of a "Java Test Suite" under the TLDA. See Ex. 70; Ex. 8 at 134:6-10 (Clary Depo.). Sun does not uniformly require that other Java implementations implement JNI. First, Sun’s own Java OS operating system fails the JNI-related tests in the JCK 1.1a test suite. Ex. 21 at 403:13-404:13. In addition, Sun was willing to grant a JNI exemption to a licensee called and Sun’s Carla Schroer has recommended granting JNI exemptions to some of Sun’s other licensees. Ex. 21 at 243:11-18 (Schroer Depo.); id. p. 244:17-245:3; Exs. 55 , 52 and 75. Finally, it is still an open issue at Sun whether browsers such as Microsoft’s Internet Explorer should be required to support JNI. Ex. 21 at 562:14-564:16 (Schroer Depo.).
Sun’s assertions that Microsoft’s compiler products are incompatible are equally weak. In the first place, it is clear that Microsoft’s products do in fact have a mode which enables them to pass the Java Language Test Suite. Ex. 10 at 230:15-231:10 (Deutsch Depo.); Lee Decl. ¶¶ 12, 30; Huhns Decl. ¶ 58. That is all that is required. Ex. 1 (TLDA § 2.6(b)(iv)). In the second place, there are no tests in Sun’s test suite that it claims Microsoft’s compiler products fail. The simple fact is that Microsoft’s compiler products-whether or not Microsoft’s compiler directives and keywords are enabled-do not violate the Java Language Specification or the Java Virtual Machine Specification. Lee Decl. ¶ 14. The output of Microsoft’s compiler does not fail to "execute properly" as Sun’s expert Peter Deutsch and Sun’s testing manager Carla Schroer have charged. Huhns Decl. ¶ 60. Microsoft’s compiler directives and keywords provide value to Microsoft’s customers. They are carefully designed to avoid interference with other Java implementations. Lee Decl. ¶ 39. Microsoft is entitled to enjoy the freedom to innovate it bargained for.
Sun’s motion is based on an assertion that Microsoft has breached a covenant to make a particular use of the Technology in addition to any other use it makes. To state a copyright infringement claim, Sun must show that the breach is of a condition precedent to the license, not merely a covenant. Fantastic Fakes, Inc. v. Pickwick Int’l, Inc., 661 F.2d 479, 483-84 (5th Cir. 1981); Peer Int’l Corp. v. Pausa Records, Inc., 909 F.2d 1332, 1338-39 (9th Cir. 1990); 3 Nimmer on Copyright, § 10.15[A] (1997). Microsoft’s obligation to pass the Java Test Suite is not a condition precedent. The TLDA’s license grants, set forth in section 2, contain no express conditions. For example, section 2.1 gives Microsoft: [a] license . . . to make, access, use, copy, view, display, modify, adapt, and create Derivative Works of the [Java] Technology in Source Code form for the purposes of developing, compiling to binary form and supporting Products. Ex. 1, § 2.1. The other license grants are stated in similarly unconditional language. See id., §§ 2.2-2.4, 2.6(a)(i), 2.6(b)(i). Similarly, section 2.6(a)(vi), which Sun asserts as the basis of its claim, does not state a condition to the license. Rather, that provision uses the language of a covenant: Licensee agrees that any new version of a Product that Licensee makes commercially available to the public after the most recent Compatibility Date shall only include the corresponding Compatible Implementation . . . Id., § 2.6(a)(vi) (emphasis added). Implied conditions are disfavored under California law, "and will not be read into a contract unless required by plain, unambiguous language." Effects Assoc. Inc. v. Cohen, 908 F.2d 555, 559 n.7 (9th Cir. 1990). The language of the TLDA does not support finding an implied condition. First, when the parties wanted to create conditional license rights, they did so expressly. See Ex. 1, Ex. E, §§ 2, 3. Second, interpreting the compatibility requirements of section 2.6(a) as a condition precedent would be inconsistent with section 11.2(b) of the TLDA. Section 11.2(b) provides that Sun may terminate the license grants in section 2 only if Microsoft "willfully and intentionally breaches a material provision of section 2.6 of this Agreement and Licensee fails to cure such breach within a period of one (1) year after the date that SUN provides [Microsoft] with notice thereof . . . ." Id., § 11.2(b). If compliance with section 2.6 were a condition precedent to the license grants in the TLDA, Microsoft’s breach of that provision would prevent the license grants from ever entering into effect and there would be nothing for Sun to terminate. Because the TLDA does give Sun a right to terminate in case of such a breach - and then only to a limited extent - the license must come into being before Microsoft’s compatibility obligations under section 2.6 arise. Compliance with section 2.6 is not a condition precedent to the licenses. Because Microsoft’s alleged breach is a breach of a covenant, Sun has no copyright claim. A breach of a covenant gives rise to a copyright infringement claim only if (1) the license agreement contains an express reversion clause under which the licensee’s contract rights automatically revert to the grantor upon breach; or (2) the license agreement provides that the grantor may terminate the license upon breach and the grantor exercises its right of termination; or (3) the breach is so material as to create a right of rescission in the grantor and the grantor exercises this right of rescission. See Fosson v. Palace (Waterland), Ltd., 78 F.3d 1448, 1455 (9th Cir. 1996); Rano v. Sipa Press, Inc., 987 F.2d 580, 586-87 (9th Cir. 1993); see also 3 Nimmer on Copyrights, § 10.15[A] (1997). The TLDA does not contain an express reversion clause. Sun has not terminated Microsoft’s license. Nor has Sun rescinded the contract. The TLDA gives Sun a right of termination only in very limited circumstances. For the right to arise: (1) Microsoft must breach a material provision of section 2.6 of the TLDA; (2) the breach must be committed by a Microsoft officer, director, or General Manager of a product group; (3) the breach must be willful and intentional; (4) Sun must give Microsoft notice of the breach; (5) Microsoft must fail to cure the breach within one year after notice by Sun. Ex. 1, § 11.2(b). Even then, for Sun to have a copyright infringement claim: (6) Sun must terminate the TLDA and the license grants in section 2; and (7) Microsoft must continue to use the Java Technology. Sun has no right of termination here. There is no willful and intentional breach of section 2.6 of the TLDA. Sun’s own employees agreed that Sun is in breach of the TLDA, not Microsoft. See Microsoft’s Opposition re Unfair Competition; see also Clement v. Smith, 16 Cal. App. 4th 39, 46 (1993) (defining a negligent breach). Microsoft has not yet had a year after notice to cure its alleged breach. Sun has not terminated the TLDA. During the one year cure period, Sun cannot stop Microsoft from putting Products into the marketplace. Ex. 5 at 457:3-9 (Baratz Depo.). Even if Sun had attempted to terminate the TLDA, it could not terminate Microsoft’s license to use the Technology as to the Surviving Products identified in section 11.2(b). Q.So the answer is that Microsoft can continue to ship surviving products, as those are defined in 11.2(b)?. A.It is that Microsoft continues to be covered with a license grant under the terms and conditions of this agreement for those products, but under all of the terms and conditions of this agreement. Ex. 5 at 458:23-459:4 (Baratz Depo.) (emphasis supplied). As Sun concedes it could not ask Microsoft to recall products. Id. at 454:17-20. Sun cannot convert its breach of contract claim into a copyright infringement claim.
Finally, Sun has not demonstrated that any material which it alleges was copied by Microsoft is protected by a valid copyright. The burden of proving that protectable expression has been copied rests squarely on Sun. Brown Bag Software v. Symantec Corp., 960 F.2d 1465, 1475 (9th Cir. 1992). Although Sun’s certificate of copyright registration raises a presumption in Sun’s favor, 17 U.S.C. § 410(c), this presumption is rebuttable. Entertainment Research Group, Inc. v. Genesis Creative Group, Inc., 122 F.3d 1211, 1217 (9th Cir. 1997). "To rebut the presumption, an infringement defendant must simply offer some evidence or proof to dispute or deny the plaintiff’s prima facie case of infringement." Id. at 1217. The presumption can be rebutted with evidence that the plaintiff’s work is not original but copied from another’s work. Id. at 1218. There is clearly evidence that disputes the validity of Sun’s copyright and therefore rebuts the statutory presumption. First, there is testimony from Sun that "chunks" of its JDK 1.1 product were contributed by other sources. Ex. 11 at 35:6-19 (Gosling Depo.). Second, Sun expert Dr. Peter Deutsch observed third-party copyright notices in Sun’s source code for JDK 1.1. Ex. 10 at 204:6-205:1 (Deutsch Depo.). Thus, on the current state of the record, Sun has not met its burden of showing that its copyright extends to the material Sun alleges was copied.
Sun has waived any claim of breach by continuing to accept payments from Microsoft under the TLDA. It is well settled that where an injured party with knowledge of a breach accepts performance by the party in default, acceptance of performance constitutes a waiver of the innocent party’s right to complain of the breach. Whitney Inv. Co. v. Westview Dev. Co., 273 Cal. App. 2d 594, 603 (1969). Microsoft tendered payment to Sun of $3,750,000, pursuant to sections 4.1 and 4.2 of the TLDA, in May of 1998. Muglia Decl. ¶ 30. This amount represented payment for all of Microsoft’s license rights under the TLDA, as well as certain "support fees." Ex. 1, §§ 4.1, 4.2. There is no dispute that the payment was received. Moreover, Sun cannot deny that it knew about Microsoft’s alleged breach when it accepted the payment. Sun has waived its right to complain of the alleged breach.
The "balance of harms" standard applies here because Sun has not shown a likelihood of prevailing on the merits. Sega Enterprises Ltd., 977 F.2d at 1517 (movant must show that the balance of harm tips sharply in its favor, where serious question is raised). The balance weighs heavily in favor of Microsoft and the public. Unquestionably, the injunction requested by Sun would cause immense harm to Microsoft; distributors, retailers, and OEMs of Microsoft products; software developers; end users; and countless third parties who sell Microsoft-related products and services. The requested injunction would require that Microsoft delay shipment of Windows® 98 and other products until they could be reworked to incorporate certain Sun technology. The reworking process would take at least 12 weeks, during which Microsoft would lose hundreds of millions of dollars from lost Windows® 98 sales alone. Akerlind Decl. ¶ 14. Recalling product that has already been shipped would also be devastating to Microsoft. In July 1998, there were nearly one million units of Windows® 98 in the retail channel. Schiro Decl. ¶ 9. Over 7,000 retailers (Shiro Decl., ¶ 9) and 70,000 OEMs (Akerlind Decl. ¶ 8) are involved in the sale of Microsoft’s Java implementations. The recall itself would take several weeks, followed by another 4-6 weeks to re-write the code, documentation and product packaging, and several additional weeks for the current level of channel inventory to be restored. Schiro Decl. ¶¶ 9, 11. The resulting delay in the sale of Windows® 98 alone will cause Microsoft to lose millions of dollars in revenue due to delayed purchases, decreased volume, and wasted promotion and advertising. Akerlind Decl. ¶¶ 12-14. The primary distribution of Windows® 98 is through personal computer makers (called "Original Equipment Manufacturers" or "OEMs"), such as Compaq. OEMs and peripheral makers have specifically adapted their products to Windows® 98. Mitchell Decl. ¶ 3; Akerlind Decl. ¶ 14. These companies would likely attempt to find a way to go back to an earlier version of Windows until Windows® 98 became available, but they doubt it could be accomplished before the revised version is ready. Mitchell Decl. ¶ 7.
If the release of Microsoft’s Visual J++ 6.0 is delayed, Microsoft will lose revenue from the sale of this product, as well as the good will of independent software developers who are relying on its availability. Button Decl. ¶ 8. The developers will also be hurt. Approximately 400,000 developers have used the beta version of Visual J++ 6.0 during the last six months, and 80,000 ISVs are ready to distribute programs written using this product. Id. ¶ 9. However, the beta release license does not permit these developers to distribute their programs until Microsoft releases the final version of Visual J++ 6.0. Id. ¶ 3. Many other third parties will incur significant losses if an injunction is issued because they are preparing to sell products or services that depend upon the release of Windows® 98, Visual J++ 6.0, and other Microsoft products. For example, third-party publishers of Visual J++ 6.0 books and magazines will lose their anticipated profits, as well as forfeiting expenses incurred in anticipation of the release of the Microsoft development tool. Id. ¶ 4. The economic reverberations will have an incalculable effect on other companies, their employees and shareholders, consumers, and others. Sun, by contrast, will suffer no harm whatsoever. Sun’s opening brief identifies a loss of cross-platform compatibility as Sun’s only concern. Sun Brf. at 16. However, Microsoft’s products are fully compatible with Java. Huhns Decl. ¶ 11. In fact, independent testing has shown that Microsoft has the most compatible Java virtual machine on the market. Ex. 24. Sun cannot base its concern on JNI, because the use of JNI destroys cross-platform compatibility. See supra, p. 10. Likewise, the Microsoft language extensions and compiler directives do not interfere with JNI because developers who want to write cross-platform compatible programs can disable these features with a simple compiler command. See supra, pp. 11-12. Thus, Sun has shown no threat to cross-platform compatibility. Even if "irreparable injury" were the test, Sun’s motion fails to meet the standard. First, because the copyright infringement alleged by Sun is merely incidental to a breach of contract claim, Sun cannot claim a presumption of irreparable injury. See USAR Systems, Inc. v. Brain Works, Inc., 887 F. Supp. 84, 85 (S.D.N.Y. 1995). Second, the only basis for Sun’s claim of irreparable injury is the alleged threat to cross-platform compatibility posed by Microsoft’s products. Sun Brf. at 16. However, there is no such threat. See supra. Third, Sun’s claim of irreparable harm is contradicted by Sun’s unreasonable delay in seeking a preliminary injunction. JNI has been an issue between the parties since early 1997. Muglia Decl. ¶ 28. Sun has known about Microsoft’s Windows-specific compiler directives since July of 1997. Ex. 15 at 369:19-370:3 and Ex. 64 thereto. There is no reason why Sun could not have included its claims against these products in its original complaint, filed on October 7, 1997, or in its previous motion for preliminary injunction, filed on November 17, 1997. Only now, when Microsoft has invested millions of additional dollars in the development and distribution of its products, is Sun seeking an injunction. These facts belie any claim of irreparable harm and establish laches. See Plescia v. Plescia, 59 Cal. App. 4th 252, 256 (1997) (laches applies when plaintiff unreasonably delays bringing suit, causing prejudice to defendant); Whittaker Corp. v. Execuair Corp., 736 F.2d 1341, 1347 (9th Cir. 1984) (the expansion of one’s business and the expenditure of capital to undertake an activity that is later subjected to legal challenge supports the defense of laches). There are no grounds for the issuance of an injunction in this case. VI. CONCLUSION Microsoft’s products are among the most compatible Java implementations available. Distribution of Microsoft’s products does not adversely impact compatibility among Java language based products. Enjoining Microsoft’s distribution will cause devastating injury to Microsoft and third parties. Sun has not demonstrated a likelihood of success and a risk of harm that warrants the injury granting its motion will cause. Sun’s motion should be denied. Dated: October 21, 1998.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
