Sun Microsystems, Inc. v. Microsoft Corp. ( 1998 )

21 F. Supp. 2d 1109 (1998)

SUN MICROSYSTEMS, INC., a Delaware Corporation, Plaintiff,
v.
MICROSOFT CORPORATION, a Washington Corporation, Defendant.

No. C 97-20884 RMW (PVT).

United States District Court, N.D. California.

November 17, 1998.

Lloyd R. Day, Jr., Vernon Winters, Day, Casebeer, Madrid, Winters & Batchelder, Cupertino, CA, Janet Cullum, Cooley Godward LLP, Palo Alto, CA, for Plaintiff.

David T. McDonald, Karl J. Quackenbush, Preston, Gates & Ellis, Seattle, WA, Terrence P. McMahon, Barbara A. Caulfield, Orrick, Herrington & Sutcliffe LLP, Menlo Park, CA, Allen Ruby, Ruby & Schofield, San Jose, CA, Thomas Burt Microsoft Corp., Redmond, WA, for Defendant.

Edward P. Davis, Jr., Skjerven, Morrill, MacPherson, Franklin & Friel LLP, San Jose, CA, Roger R. Myers, Steinhart & Falconer, San Francisco, CA, for Media Entities.

ORDER RE SUN'S MOTIONS FOR PRELIMINARY INJUNCTION AGAINST MICROSOFT

WHYTE, District Judge.

Plaintiff's motions for preliminary injunctive relief based on 17 U.S.C. section 502 and section 17200 of the California Business and Professions Code were heard on September 8-10, 1998. The court has read the moving and responding papers, considered the witness testimony and heard the oral argument of counsel. For the reasons set forth below, the court grants in part plaintiff's motions for preliminary injunctive relief.

I. BACKGROUND

According to Sun Microsystems, Inc. ("Sun"), Microsoft Corporation's ("Microsoft") Internet Explorer 4.0 ("IE 4.0"), Software Development Kit for Java ("SDKJ") versions 2.0 and 3.0, Visual J + + 6.0 ("VJ 6.0") and Windows98 products infringe Sun's copyrights for the source code embodying the Java Technology. More specifically, Sun asserts that Microsoft's license to distribute products which use Sun's copyrighted source code depends on compliance with Sun's applicable test suite for the version of the technology which Microsoft's products incorporate. Sun submits that the above-mentioned products fail to pass the applicable compatibility test suite and that, therefore, Microsoft's distribution of these products infringes Sun's copyrights.

Sun now seeks to immediately enjoin Microsoft from reproducing, distributing or selling SDKJ 2.0 and 3.0, and VJ 6.0, unless and until Microsoft has demonstrated that these products successfully pass Sun's compatibility test suite and comply with all other compatibility and certification requirements provided for in the Technology License and Development Agreement between Sun and Microsoft. Sun also challenges Microsoft's right to distribute IE 4.0 and Windows98 in their current configurations. However, Sun's proposed injunction as to these products would allow Microsoft ninety days to modify IE 4.0 and Windows98 such that these products also pass Sun's compatibility test suite.

A. SUN'S JAVA TECHNOLOGY

Sun's Java Technology is a collection of programming components that create a standard, platform-independent programming and runtime environment. Sun's Java Technology has two basic elements: the Java programming environment and the Java runtime environment.

The Java programming environment allows software developers to create a single version of program code that is capable of running on any platform which possesses a compatible implementation of the Java runtime environment. The Java programming environment comprises (1) Sun's specification for the Java language, (2) Sun's specification for the Java class libraries and (3) the Java compiler.

The Java runtime environment comprises the Java class libraries and the Java runtime interpreter. A system platform or browser program that implements the Java runtime environment can execute application programs developed using the Java programming environment.

Sun's Java programming and runtime environments are available to software developers in the form of the Java Developer's Kit ("JDK") which is a tool embodying the language, class libraries and the compiler. Sun also licenses the source code for its JDK software to systems and browser manufacturers (e.g., Apple, IBM, Microsoft, Netscape, etc.) to enable them to incorporate the Java Technology in their own operating systems, browsers and software development tool kits.

B. LICENSE AGREEMENT BETWEEN SUN AND MICROSOFT

The negotiations between Sun and Microsoft which resulted in the Technology License and Distribution Agreement ("TLDA") comprised several rounds of telephone conferences, e-mail communications and face-to-face negotiations. On December 6, 1995, Sun and Microsoft executed a Letter of Intent ("LOI") setting forth the general subject matter and basic terms of the agreement to be negotiated. See McMahon Decl. Ex. 36. During the negotiations of the LOI, Sun and Microsoft contemplated that any license agreement would grant Microsoft the right to include the Java Technology only in its Internet browsers and software development tools. See Baratz Reply Decl. ¶ 27; Patch Reply Decl. ¶ 9.^[1] However, the proposed agreement was soon expanded to encompass Microsoft's use of the Java Technology in operating systems.

Near the end of February 1996, the intensity and frequency of the negotiations resulting in the TLDA increased. Microsoft planned a Professional Developers Conference for mid-March 1996 during which it would announce the details of Microsoft's Internet strategy to technical system developers. Muglia Decl. ¶ 12. This conference marked a deadline for Microsoft's contract negotiations with Sun. Id. Even on the day before the conference, Microsoft and Sun had not finalized many material terms and details of the agreement. Microsoft's negotiators flew down to Sun's offices in Cupertino to begin discussions at 10:00 a.m. on Monday morning, March 11, 1996. Muglia Decl. ¶ 15. After almost 19 hours of negotiations, Sun and Microsoft executed the final agreement at 4:45 a.m. on March 12, 1996.^[2]Id. Less than fours hours later, Microsoft announced the execution of the TLDA at the conference. Id. ¶ 17.

Pursuant to the TLDA, Sun granted to Microsoft a nonexclusive license "under the Intellectual Property Rights of SUN to make, access, use, copy, view, display, modify, adapt, and create Derivative Works of the Technology in Source Code form for the purposes of developing, compiling to binary form and supporting Products." Batchelder Decl. Ex. C (TLDA § 2. 1(a)). Sun also granted Microsoft a license to "make, use, import, reproduce, license, rent, lease, offer to sell, sell or otherwise distribute to end users as part of a Product or an upgrade to a Product, the Technology and Derivative Works thereof in binary form." TLDA § 2.2(a)(iii). However, as to browser and operating systems, the TLDA also provides that each new version of any "Product" that incorporates Sun's Java Technology must pass Sun's compatibility test suite prior to its commercial distribution. TLDA §§ 2.6(a)(iv), (vi). The TLDA defines the "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 § 1.15. The AAPI or Applet Application Programming Interface is defined as:

(a) the public application programming interface to the Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A, (b) the bytecode specification in the Documentation entitled "OEM Java Virtual Machine Specification," (c) the Java language specification in the Documentation entitled "OEM Java Language Specification" and (d); the OEM Java API Specification, as modified by SUN during the term of this Agreement.

TLDA § 1.1. The TLDA permits Microsoft to extend or make additions to the AAPI, referred to as "Value Added Open Packages" or "VAOPs." TLDA §§ 1.28, 2.8(a). However, the TLDA restricts Microsoft to a specific naming convention for any VAOPs. See TLDA § 2.8(d). Additionally, the TLDA proscribes any modification or addition to the names of the public Java classes "whose names begin with `Java', `COM.sun' or their equivalents." TLDA § 2.8(d).

Microsoft's products which include Java compilers are subject to a slightly different compliance standard. Any Microsoft product having a Java language compiler "shall include a mode which a Tool Customer may use to permit such Product to pass the Java Language Test Suite^[3] that accompanied the Significant Upgrade." TLDA § 2.6(b)(iv). Microsoft argues that this provision allows it to develop compiler directives and keyword extensions which optimize the Java Technology for software developers who wish to write applications solely for the Win32 platform, as long as the compiler includes a mode that disables these compiler directives and extensions. See Muglia Decl. ¶¶ 5, 9, 11. Sun, on the other hand, argues that section 2.6(b)(iv) only allows Microsoft to include in its compilers the ability to compile code for prior compatible versions of the Java Technology that were incorporated in earlier products. See Baratz Reply Decl. ¶¶ 15, 18-21; Patch Reply Decl. ¶ 62-68. Sun also avers that Microsoft never discussed the possibility of extending the Java, language.. Patch Reply Decl .... ¶ 68; but see Muglia Decl. ¶ 11.

C. ASSERTED INCOMPATIBILITIES OF MICROSOFT'S PRODUCTS

Sun contends that Microsoft's Windows98 and IE 4.0 products fail to pass the JNI tests of Sun's JCK 1.1 a test suite. Schroer Supp. Decl. ¶¶ 5, 6 & Ex. A. Microsoft's SDKJ 2.02 and 3.0 and VJ 6.0 software development tools, according to Sun, do not support Sun's JNI and RMI technology and, therefore, fail (1) Sun's JNI tests, and (2) St & s RMI Compiler tests. Sun also contends that Microsoft's use of incompatible keywords and compiler directives cause its compiler to generate output which fails to properly execute on the JDK 1.1 virtual machine. See Schroer Supp. Decl. ¶¶ 7, 8, 9 & Ex. A. Sun also contends that SDKJ 2.02 fails two required compiler tests. Schroer Supp. Decl. ¶ 7(d).

Sun's original testing indicated that Microsoft's products generated 107 "Signature Test" failures. However, this testing was performed on so-called "betaversions" of Microsoft's products. Sun no longer asserts that Microsoft's products generate these Signature Test errors.

1. RMI Compiler Tests

As to the RMI test failures, Microsoft argues that Sun's RMI Compiler or "rmic" constitutes Supplemental Java Classes under the TLDA. See TLDA §§ 1.23, 2.7(a). Microsoft notes that the TLDA does not require it to include Supplemental Java Classes in its products. Rather, Microsoft must only post Supplemental Java Classes on its website to satisfy its obligations under the TLDA. Sun appears to agree with this contention as its reply brief offers no opposing argument.

2. SDKJ 2.02

As to the two compiler test errors generated by SDKJ 2.02, Microsoft asserts that one of these tests (the "601 test") is in fact passed and that the failure of the other test (the "2003 test") resulted from a program bug which was fixed in SDKJ 3.0. Golde Decl. ¶¶ 2-4. Microsoft submits that it will fix this bug in SDKJ 2.02. Id. ¶ 4. Sun maintains, however, that Microsoft's claim that SDKJ 2.02 passed the 601 test is most likely based upon an improper execution of the test. See Schroer Reply Decl. ¶ 26-29.

3. Java Native Interface ("JNI")

Since the Java Technology does not have all of the functionality which a software developer may require, Sun developed a native method interface to the Java runtime interpreter. See Deutsch Decl. ¶ 75. In Sun's JDK 1. I product, this native method interface is called the Java native in terrace or "JNI." According to Sun, JNI is an upgrade or enhancement to the native method interface (originally called "nmi") in the JDK 1.0 version of the Java Technology originally shipped to Microsoft. Sueltz Decl. ¶ 7. When functionality not available from the Java Technology is needed, the software developer will write part of the application in the Java language and the remaining portion in a native language supported by the particular platform for which the program is written. This native language, such as C or C + +, is platform-dependent; hence, any program written in the Java language which invokes a native method is also platform-dependent.

According to Sun, JNI is a public application programming interface to the Java runtime interpreter. Lindholm Reply Decl. ¶ 4. JNI "links Java code to native code through the Java virtual machine, and provides native code with access to the Java Virtual Machine." Id. ¶ 3. JNI allows a Java/native application to run on any Java-compatible virtual machine. Gosling Decl. ¶ 15; Lindholm Reply Decl. ¶ 3.

Microsoft's runtime interpreters or virtual machines do not support Sun's JNI. Rather, Microsoft's runtime interpreters support native method interfaces called RNI, Java/COM and J/Direct. Java/COM and J/Direct allow software developers to call to Windows-specific native functionality when using Microsoft's software development toolkits, such as SDKJ or VJ 6.0. Software applications that use RNI, J/Direct or Java/COM, says Sun, will not run on Java runtime interpreters supporting only Sun's JNI. See Gosling Decl. ¶ 16. This incompatibility, according to Sun, "fragments" the Java programming environment for the windows platform. Id. ¶ 17. Furthermore, Sun contends that Java/native applications which use RNI, J/Direct or Java/COM only run properly on Microsoft's virtual machine. Id. ¶ 16, 17.

Sun argues that JNI clearly falls within Microsoft's compatibility obligations under the TLDA. Sun submits that the TLDA permits Sun to test for compliance with Sun's specification of the AAPI, including upgrades thereto. Sun reasons that since JNI is a programming interface to the Java Runtime Interpreter which itself constitutes part of the Java Applet Environment, it falls within Microsoft's compliance obligations. See Sueltz Decl. ¶ 7; Day Decl. Ex. D (Silverberg Depo. at 38:3-10).

Microsoft, on the other hand, submits that the TLDA does not require its products to support JNI or pass any compatibility tests relating thereto. According to Microsoft, the issue is whether Sun's JNI is part of the AAPI and, more specifically, whether JNI is part of "the public application programming interface to the Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A." TLDA § 1. ¶ (a); Opposition at 9. Microsoft contends that, as evidenced by section 1.2, section 1. ¶ (a) of the TLDA was only intended to define Java applet interfaces and that JNI does not fit this definition. See TLDA § 1.2. As Microsoft explains, JNI is an interface available to C or C + + programmers which allows a native program to invoke a Java virtual machine and provides a connection mechanism for programmers to target when writing native code. Huhns Decl. ¶ 40; Deutsch Decl. Ex. 28 (Java Native Interface Specification at 1). Indeed, Microsoft asserts that it specifically rejected Sun's proposed contract language granting Sun control of the native interfaces to Microsoft's "Java Reference Implementation." McMahon Decl. Ex. 17 (Muglia Depo. at 117:14-118:10).

4. Keyword Extensions and Compiler Directives

Microsoft contends that the TLDA authorizes its specific implementation of keyword extensions and compiler directives in its Java-based products. Microsoft developed its compiler directives to provide direct, more efficient calling of native functionality which already exists on the Windows platform. See Gosling Decl. ¶ 16. The "@dll" and "@com" directives support Microsoft's native method interfaces called "J/Direct" and "Java/COM," respectively. These directives allow a software developer to access non-Java code in "dynamic link libraries" and "COM libraries," respectively. Lee Decl. ¶ 37. The "@security" directive disables certain security features implemented on Microsoft's virtual machine. Id. A software developer who wishes to use these compiler directives inserts them into source code as documentation comments. See Lee Decl. ¶ 43. Usually, a compiler ignores information in documentation comments; however, in its extended mode, Microsoft's compiler recognizes the @dll, @corn, and @security directives.^[4]

Microsoft's keyword extensions, "multicast" and "delegate," are used as part of a class declaration to create method pointers and were designed to handle the problem of "event handling." See Deutsch Decl. ¶ 34, Exs. 3, 4; Lee Decl. ¶ 37. When Microsoft's compiler in its extended mode encounters the "delegate" and "multicast" keywords, it generates class files that extend the "delegate" and "multicast" classes. The resulting class file has attributes that reference the two classes developed by Microsoft ("com.ms.lang.Delegate" and "com.ms.lang.MulticastDelegate"). See Deutsch Decl. ¶ 58, Ex. 2 (Delegates in Visual J + + 6.0 at 1). If a particular virtual machine, such as Sun's, does not implement these classes, compiled code which references them will not run on that virtual machine. Deutsch Decl. Ex. 6 (DeMichillie Depo. at 61:8-63:14). Microsoft's delegate class is implemented natively by the Microsoft Virtual Machine, rather than being implemented as separate Java classes. DeMichillie Depo. at 62:10-22.

As to Microsoft's allegedly incompatible compiler, Microsoft points out that its compiler has an "enhanced mode in which the user has available three families of compiler directives and two keywords." Opposition at 3. Microsoft also submits that SDKJ 2.0 and 3.0 as well as VJ 6.0 allow the software developer to turn this enhanced mode on and off as contemplated by section 2.6(b)(iv) of the TLDA. Huhns Decl. ¶ 58. Moreover, Microsoft asserts that its compiler executes properly regardless of whether the enhanced mode is employed. Lee Decl. ¶¶ 14, 15; Huhns Decl. ¶¶ 59, 60. Further, Microsoft contends that use of its compiler directives in source code does not result in errors even when Sun's compiler compiles that source code. Lee Decl. ¶ 15. However, Microsoft does admit that a software. developer's use of Microsoft's keyword extensions ("delegate" and "multicast") in its source code will generate errors with a non-Microsoft compiler. Lee Decl. ¶ 16. Microsoft asserts, however, that this would be patently obvious to almost any software programmer who would simply avoid these extensions when writing platform-independent code. Lee Decl. ¶¶ 8, 13, 16.

According to Sun, the mode switch in Microsoft's compiler does not allow generation of class files which pass the JCK 1.1a test suite. See Hankinson Decl. ¶¶ 7,8. However, this contention only appears to be valid when the source code being compiled includes Microsoft's language extensions. See id. ¶¶ 37, 38. In any event, Sun asserts that Microsoft's use of compiler directives and keyword extensions exceeds the scope of the license granted in the TLDA.

As to Microsoft's keyword extensions ("multicast" and "delegate"), the evidence indicates that Microsoft's compiler, when it encounters these extensions, generates output in a class file that is byte code compatible; however, the compiled instructions cause the virtual machine to look for classes which only Microsoft's virtual machine possesses. See Deutsch Decl. ¶ 58; Deutsch Reply Decl. ¶ 6. Microsoft's compiler directives, on the other hand, cause the Microsoft compiler to insert non-standard attributes into the resulting binary files. Deutsch Reply Decl. ¶ 9. According to Microsoft, this does not violate the Java Language Specification or the Java Virtual Machine Specification since the "semantics of class and interface types" remain unaffected and any Java runtime ignores attributes that it does not recognize. Lee Decl. ¶¶ 40-42. In any event, source code containing Microsoft's compiler directives, when compiled using Microsoft's compiler and run on Sun's JDK 1.1 virtual machine, generates an error message, rather than executing the desired native function. For example, with respect to the "@dll" compiler directive, a non-Microsoft virtual machine will ignore the attribute created by use of this compiler directive and will consequently fail to invoke the associated native DLL function thereby causing the virtual machine to generate an error message. See September 9, 1998 Hearing Transcript (Gosling Test. at 250:20-252:24, 255:2-15); see also September 8, 1998 Hearing Transcript (Lee Test. at 133:5-135:21); Hankinson Decl. ¶ 36.

D. MICROSOFT'S ALLEGED UNFAIR COMPETITION

Sun's motion for preliminary injunctive relief based on unfair competition under section 17200 of the California Business and Professions-Code is primarily based on Microsoft's alleged scheme to neutralize the threat that Sun's Java Technology apparently poses to Microsoft's continued dominance of the operating systems market. According to Sun, Microsoft's plan is to leverage its dominant market share in operating systems to "pollute" the market for the Java Technology with non-compliant browsers, operating systems and software development tools. Sun fears that the resulting installed base of Microsoft's incompatible implementations of the Java Technology will become the defacto standard. Arrow Decl. ¶¶ 26-29.

In addition to complaining about the alleged purposeful injection of Java-incompatible products into the market, Sun challenges Microsoft's licensing practices relating to its implementations of the Java Technology. Specifically, Sun contends that Microsoft's license agreements with resellers and developers restrict them to developing software only for Microsoft's version of the Java Technology. See Armstrong Reply Decl. Ex. 15 ("[Licensee] shall ... redistribute the Microsoft virtual machine for Java ... and not any other virtual machine; ... use only the Microsoft native code interface that is part of the MS Java VM for any native code calling."); Ex. 22 ("[Licensee] shall .... use only the Microsoft native code interfaces (J/Direct, RNI, Java/COM) that are part of the MS Java VM for any native code calling with respect to the such interfaces."); see also Armstrong Decl. Ex. 35. Microsoft, on the other hand, states that its current licensing program does not require exclusive use of Microsoft's virtual machine or methods of calling native code. Further, it submits that its prior license agreements which do require exclusive distribution of Microsoft's virtual machine are no longer "in force." See McMahon Decl. Ex. 19 (Plamondon Depo. at 40:6-41:19).

Sun also alleges that Microsoft has made certain misrepresentations in its effort to induce software developers to create programs written for Microsoft's incompatible implementation of the Java Technology. Unfair Comp. Motion at 19. According to Sun, Microsoft misleadingly advertises that the TLDA designates Microsoft's implementation the "official reference implementation" of the Java Technology for Win32-based systems. Armstrong Decl. Ex. 31, Sun also objects to Microsoft's advertising that "Java applications created with the SDKJ will run on any platform." Armstrong Decl. Ex. 32 at 3. Sun further decries Microsoft's designation of SDKJ and VJ 6.0 as "Java Compatible." Armstrong Decl. Exs. 29, 30. Microsoft argues that these statements are true and not likely to mislead software developers. Microsoft's software development tools, according to Microsoft, include a mode that allows a software developer to generate Java compatible code. Microsoft points out that its use of language extensions is well publicized and is no surprise to software developers. See Hejlsberg Decl. Exs. A, B.

E. SUN'S REQUESTED RELIEF

As discussed above, Sun seeks an order enjoining Microsoft from reproducing, distributing or selling IE 4.0, SDKJ 2.0 and 3.0. VJ 6.0 and Windows98, unless and until Microsoft has demonstrated that these products successfully pass Sun's compatibility test suite and comply with all other compatibility and certification requirements provided for in the TLDA. Sun, however, recognizes the harm to innocent third parties which the requested relief may cause. Sun's Copyright Reply at 15. As to Windows98 and IE 4.0, Sun requests an order enjoining Microsoft from distributing copies of these products ninety days after entry of this order unless each product include a Java runtime interpreter that passes the JCK 1.1a test suite. Sun also contemplates an extension to this ninety-day period if Microsoft can demonstrate good cause for it. As to Microsoft's development tools (VJ 6.0 and SDKJ 2.0 and 3.0), Sun seeks an order immediately enjoining Microsoft's distribution of these products unless and until they successfully pass Sun's JNI and Compiler Output Requirement tests.

F. MICROSOFT'S MOTION TO STRIKE SUN'S NEW AND CHANGED THEORIES

Microsoft moves to strike certain arguments and evidence which, it alleges, were first presented in Sun's reply briefs. Microsoft explains that Sun's reply papers contain arguments and evidence vastly different from those asserted by Sun in its initial moving papers. For example, in its initial moving papers, Sun primarily relied on the failure of Microsoft's products to pass Sun's Signature Tests. Sun's motion, says Microsoft, contained only minor references to JNI. In its reply, Sun has, according to Microsoft, shifted its main emphasis to Microsoft's allegedly wrongful failure to support JNI and Microsoft's use of compiler directives and keyword extensions. Microsoft now moves to strike these "new" arguments and supporting evidence raised by Sun.

The court denies Microsoft's motion to strike Sun's allegedly new and changed theories as Microsoft has failed to demonstrate any unfair surprise or prejudice. Microsoft's oppositions to Sun' motions and its presentation to the court during the technology tutorial demonstrate that Microsoft was fully apprised of the main issues in Sun's motions. Moreover, Microsoft had ample opportunity to mitigate any prejudice it now claims during the two-day evidentiary hearing conducted pursuant to its request. As to JNI, Sun's initial moving papers clearly assert that the TLDA requires Microsoft's products to support JNI. See Copyright Motion at 9:4-5; Unfair Comp. Motion at 16:26-18:5; see also Deutsch Decl. ¶¶ 5-8, 74-89. In addition, Sun's argument as to why the TLDA requires support for JNI is the same as that advanced by Sun it its first motion for preliminary injunctive relief. See March 24, 1998 Order at 16:15-27. As to Microsoft's compiler directives and keyword extensions, Sun provided Microsoft with sufficient notice of Sun's challenge. See Second Amended Complaint (May 12, 1998) ¶ 83; Schroer June 17, 1998 Decl. ¶¶ 5(a)-(c), 11(e), 12(f), 13(f). Sun's arguments and evidence submitted in reply respond in the main to Microsoft's argument that the "mode" language in section 2.6(b)(iv) of the TLDA allows Microsoft to create language extensions.

II. LEGAL STANDARD FOR PRELIMINARY INJUNCTIVE RELIEF

A plaintiff seeking preliminary injunctive relief must demonstrate "either a likelihood of success on the merits and the possibility of irreparable injury, or that serious questions going to the merits were raised and the balance of hardships tips sharply in its favor." Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1517 (9th Cir.1992) (citations omitted). The alternatives in the above standard represent "extremes of a single continuum," rather than two separate tests. Benda v. Grand Lodge of Int'l Ass'n of Machinists & Aerospace Workers, 584 F.2d 308, 315 (9th Cir.1978). A "serious question" is one to which the movant has a "fair chance of success on the merits." Sierra On-Line, Inc. v. Phoenix Software, Inc., 739 F.2d 1415, 1421 (9th Cir.1984). Generally, evaluation of the relative hardships of the parties should precede an analysis of the "likelihood of success on the merits" since the balance of hardships determines how strong and substantial the plaintiff's showing must be. See Alaska v. Native Village of Venetie, 856 F.2d 1384, 1389 (9th Cir.1988). Where a public interest is involved, the court should also consider if the grant of a preliminary injunction favors the public interest. Westlands Water Dist. v. Natural Resources Defense Council, 43 F.3d 457, 459 (9th Cir. 1994).

The Copyright Act specifically provides for temporary and permanent injunctive relief against infringers. 17 U.S.C. § 502(a). In the copyright infringement context, a plaintiff need only establish a reasonable likelihood of success to support a district court's grant of a preliminary injunction. Johnson Controls v. Phoenix Control Systems, 886 F.2d 1173, 1174 (9th Cir.1989) ("showing of a reasonable likelihood of success on the merits raises a presumption of irreparable harm.").

III. ANALYSIS

A. LIKELIHOOD OF SUCCESS ON THE MERITS OF SUN'S COPYRIGHT INFRINGEMENT CLAIM

To establish copyright infringement, a plaintiff must prove (1) ownership of a valid copyright and (2) copying of expression protected by its copyright. Triad Systems Corp. v. Southeastern Express Co., 64 F.3d 1330, 1335 (9th Cir.1995).

1. Ownership of a Valid Copyrights

Sun's certificates of copyright registration raise a rebuttable presumption that Sun owns valid copyrights in the JDK source code. 17 U.S.C. § 410(c); Entertainment Research v. Genesis Creative Group, 122 F.3d 1211, 1217 (9th Cir.1997); see generally Crean Decl. and Crean Supp. Decl. Microsoft attempts to rebut the presumption of validity by arguing that certain "chunks" of the JDK 1.1 source code were contributed by third-party sources. However, Sun submits evidence indicating that less than ten percent of the source code files for JDK 1.1 potentially contain third-party code. Lindholm Reply Decl. ¶ 44. Moreover, Sun's certificates of registration indicate that the registered source code incorporates third-party computer programs. See Crean Decl. Exs. D, E; Crean Supp. Decl. Exs. A. B, C. Microsoft cites no authority indicating that the acknowledged presence of third-party code in copyrighted software is sufficient to rebut the presumption of validity.

2. Copying of Expression Protected by Sun's Copyrights

Microsoft does not dispute that it has copied Sun's JDK 1.1 product. Microsoft contends, however, that Sun has not met its burden of demonstrating that its copyright extends to material copied by Microsoft given the presence of third-party code. However, Sun submits evidence that shows Microsoft's copying of source code files original to Sun. See Deutsch Reply Decl, ¶¶ 30-35.

3. Whether Microsoft's Use of Sun's Copyrighted Source Code is Authorized

Sun argues that Microsoft's IE 4.0, SDKJ 2.0 and 3.0, VJ 6.0 and Windows98 fail to pass Sun's compatibility test suite and that, therefore, distribution of these products falls outside the scope of the license granted to Microsoft in the TLDA. Microsoft, on the other hand, contends that the TLDA carves out the tests to be passed and that Microsoft's products pass these tests.

A licensee infringes the licensor's copyright if it exceeds the scope of the license. S.O.S., Inc. v. Payday, Inc., 886 F.2d 1081, 1087 (9th Cir.1989). "[C]opyright licenses are assumed to prohibit any use not authorized." Id. at 1088. Therefore, the affirmative grants of the TLDA determine the scope of Microsoft's license. See Cohen v. Paramount Pictures Corp., 845 F.2d 851, 853-54 (9th Cir.1988) ("[A copyright] license must be construed in accordance with the purpose underlying federal copyright law.").

Here, the issue is whether Microsoft's use of the Java Technology exceeds the scope of its license. Section 2.2(a)(iii) grants Microsoft the right to distribute the Java Technology and "Derivative Works thereof" "as part of a Product." Section 2.6(a)(vi) of the TLDA limits this distribution right to "Products" which pass Sun's relevant test suite. Therefore, the contractual issues distill down to (1) whether the TLDA requires Microsoft to support JNI and (2) whether the TLDA allows Microsoft to incorporate keyword extensions and compiler directives into its products.

a. Whether the TLDA Requires Microsoft to support JNI

Sun has demonstrated a reasonable likelihood of success on its claim that the TLDA requires compliance with Sun's specifications for JNI. Under the TLDA, the "Java Test Suite" means "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 § 1.15. The TLDA expressly defines the AAPI as, in part, "the public application programming interface to the Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A [to the TLDA] as modified by Sun during, the term of this agreement." TLDA § 1.1. Exhibit A states that the Java Applet Environment consists of certain Java Classes and the Java Runtime Interpreter. "Technology" comprises the "Java Runtime Interpreter, Java Classes, Supplemental Java Classes, Java Compiler, and all Upgrades." TLDA § 1.25. According to Sun, JNI is an upgraded, public application programming interface to the Java Runtime Interpreter which is intended to allow a Java/native application to run on all virtual machines, designed for a specific platform. See Sueltz Decl. ¶ 7; Gosling Decl. ¶ 15; Deutsch Decl. Ex. 28 (JNI Specification at 1). Microsoft appears to agree that JNI is an application programming interface to the virtual machine. See Huhns Decl. ¶ 40. Day Decl. Ex. D (Silverberg Depo. at 38:3-10); see also Deutsch Decl. Ex. 21. Sun also points out that the TLDA defines native code interfaces as interfaces to the virtual machine. TLDA § 2.9(e). It follows that, since JNI is an application programming interface to the Java Runtime Interpreter which, according to Exhibit A of the TLDA, is part of the Java Applet Environment, JNI falls within Microsoft's compliance obligations under section 2.6 of the TLDA.

The Java Language Specification and Java Virtual Machine Specification further support Sun's contention as both contemplate invoking native methods. See Lindholm Reply Decl. ¶¶ 14-19; Java Virtual Machine Specification ("JVMSpec.") at 104, Table 4.4. Sun's specifications indicate that the functionality of the Java runtime interpreter includes the ability to call native code. The Java Virtual Machine Instruction Set includes the terms "invokeinterface," "invokespecial," "invokestatic" and "invokevirtual" which cause native code to be loaded and linked to the virtual machine. JVMSpec. at 258-69; Lindholm Reply Decl. ¶ 14. Additionally, the Java Language Specification environment and native code is particular to a specific platform (and often written for a specific software application), an interface is required to allow communication between the Java virtual machine and the native code. See Lindholm Reply Decl. ¶ 15.

Other provisions of the TLDA support the court's interpretation. Section 2.9(b) of the TLDA requires that Microsoft's runtime interpreter "include the necessary Source Code to implement the functionality of the Java Runtime Interpreter." Accordingly, the TLDA requires Microsoft's runtime interpreter to implement the functionality encompassed by JNI, Sun's native interface to the Java Runtime Interpreter. Section 2.9(f) also contemplates Sun's testing of the interfaces to the "Reference Implementation VM." See TLDA § 2.9(f) ("Licensee agrees that from time-to-time during the Term, SUN may wish to suggest that Licensee modify the implementation and/or interfaces to the Reference Implementation VM in a substantive way which cannot be adequately expressed through the Test Suites.").

Furthermore, the negotiation history of the TLDA, as evidenced by the draft agreements, undermines Microsoft's contention that exclusive control over the programming interfaces to its runtime interpreter was a "deal breaker." Specifically, Microsoft's proposed draft of March 10, 1996 appears to allow Sun to test Microsoft's invocation interface to the runtime interpreter. See March 10, 1996 Draft § 1.9 ("`Invocation Interface' means the public interface to the Reference Implementation VM ... including any Derivative Works or Independent Works thereof which meet the compatibility requirements set forth in Section 2.6 of this Agreement."). The invocation interface allows a native code program to invoke the Java runtime environment. See September 8, 1998 Hearing Transcript (Muglia Test. at 31:1-5). The invocation interface, as defined in the March 10 draft agreement and previous drafts, relates directly to one of the two aspects of JNI. As discussed above, JNI comprises two sets of functionality: 1) an interface that allows Java code to invoke native methods, and 2) a set of native interfaces which allows a native program to invoke the Java runtime environment.

Microsoft argues that JNI is not part of the AAPI since, according to Microsoft, AAPI or "Applet API" only refers to the interface to the Java Classes, which are all that Applets require in order to run properly. See TLDA Ex. A § I(A). Microsoft relies on the definition of "Applet" in the TLDA and Sun's definitions of the "Java Applet API" in documentation to JDK 1.0 and a so-called Sun "White Paper" to support its interpretation. See Huhns Decl. Exs. B, C; see also TLDA § 1.2 ("`Applet means a program written in the Java Language which (i) runs on the AAPI and (ii) consists of Java byte codes executable by the Java Runtime Interpreter (but does not include or incorporate the Java Runtime Interpreter, or Java Classes).'"). Microsoft further asserts that its definition corresponds to the meaning of the term as understood by both Sun and Microsoft. in the negotiations resulting in the TLDA. McMahon Decl. Ex. 17 (Muglia Depo. at 108:23-109:17), Ex. 13 (Joy Depo. at 277:11-278:3). However, Microsoft ignores the fact that AAPI, regardless of how it is defined outside the TLDA, is expressly defined in the TLDA to include application programming interfaces to the Java Applet Environment which includes the Java Runtime Interpreter. Java/native applications embody native modules as well as Java Applets. Microsoft's asserted interpretation attempts to insert "Applet" into the definition of AAPI in section 1.1(a) and results in the replacement of the term "Java Applet Environment" with the term "Java Classes." See TLDA §§ 1.1, 1.3.

Moreover, since the TLDA is an integrated agreement (TLDA § 12.3) and Sun has demonstrated likely success in showing that the definition of AAPI is not ambiguous, the parol evidence rule may bar Microsoft's reliance on extraneous documents, letters-of-intent, and prior negotiations to excise interfaces to the Java Runtime Interpreter from the express definition of AAPI. See A. Kemp Fisheries, Inc. v. Castle & Cooke, Inc., 852 F.2d 493, 495 (9th Cir.1988) ("[T]he 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.' ... `[E]xtrinsic evidence is not admissible to add to, detract from, or vary the terms of a written contract.'") (citations omitted); see also California State Auto. Ass'n Inter-Ins. Bureau v. Antonelli, 94 Cal. App. 3d 113, 118, 156 Cal. Rptr. 369 (1979) (stating that, where a term is expressly defined and used consistently throughout an agreement, the fact that the ordinary or commonly understood meaning of the term is narrower does not render the contract term ambiguous).

Furthermore, Microsoft's own draft of March 10, 1996 vitiates Microsoft's contention that the term "Applet" in "Applet Application Programming Interface" limits the range of Sun's permissible testing to programs written solely in the Java language. Section 1.1 of the March 10 draft states that the AAPI "means the application programming interface to the Technology, including the interface to the Applet Classes (as defined below)." The definitions of "Applet" and "Java Test Suite" in the March 10 draft are identical to that contained in the TLDA. March 10, 1996 Draft §§ 1.2, 1.16. Microsoft's own March 10 draft quite clearly states that the invocation interface, an interface to the Reference Implementation VM, falls within the compatibility requirements of section 2.6. See, March 10, 1996 Draft § 1.9.

According to Microsoft, JNI is not part of Sun's "specification for the AAPI" under section 1.15 of the TLDA and, therefore, JNI falls outside of the TLDA's compatibility obligations. Microsoft argues that "Sun's specification for the AAPI" is limited to the documents referenced in sections 1.1(b), (c) and (d) of the TLDA and that these documents do not refer at all to JNI. However, Microsoft's interpretation cannot be squared with the unambiguous language of the TLDA. The term "specification for the AAPI" finds no express definition in the TLDA. The TLDA's definition of AAPI contains four sub-parts, including "the public application programming interface to the Java Applet Environment." TLDA § 1.1(a). Therefore, the TLDA appears to contemplate that Sun's test suite would validate compliance with Sun's specification for the Java Applet Environment which includes the Java Runtime Interpreter. See TLDA §§ 1.15, 1.1 & Ex. A.

Microsoft also argues that the TLDA's definition of AAPI in section 1.1(a) is limited to that identified in Exhibit A and excludes upgrades. However, Microsoft's asserted interpretation overlooks the language at the end of section 1.1 which reasonably appears to contemplate modifications and upgrades to the AAPI. TLDA § 1.1 ("`AAPI' means (a) 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.") (emphasis added)

Microsoft also submits that JNI is a "Supplemental Java Class" and that, therefore, it has no obligation to include JNI in its runtime interpreters. See TLDA § 2.7(a). However, "Supplemental Java Classes" are Sun's additions to the Java Classes provided in Exhibit A, while JNI is an interface to the Java Runtime Interpreter. See TLDA § 1.23 ("`Supplemental Java Classes' means the Java classes that SUN delivers to [Microsoft] after the Effective Date (i.e., in addition to the `Java Classes') pursuant to section 3.1 of this Agreement."). Furthermore, Microsoft ignores section 2.9(b) of the TLDA which requires Microsoft's virtual machine to include "the necessary Source Code to implement the functionality of the Java Runtime Interpreter."

Microsoft argues that Sun cannot permissibly test for compliance with JNI since Sun does not require some of its other licensees to comply with JNI. Microsoft contends that even Sun's JavaOS fails the JNI related tests. Sun points out, however, that Sun's JavaOS is specifically designed to exclude "dynamic loading of native code" and does not implement JNI or any other native method interface. Schroer Reply Decl. ¶ 19. Furthermore, Microsoft's reliance on the recommendations of Ms. Schroer as to whether a particular licensee should be required to support JNI in certain, well-defined instances is unavailing as no showing has been made (1) that she speaks conclusively for Sun and (2) that Sun has granted any such exemptions.

Finally, Microsoft argues that the extent of Sun's testing is limited to the Java Virtual Machine Specification and that including JNI in the definition of AAPI results in a meaning that is "arbitrary and unconstrained." However, section 1.1(a) of the TLDA appears to limit Sun's testing to public application programming interfaces to the runtime interpreter, rather than tool interfaces or other interfaces to the runtime interpreter. Furthermore, as discussed above, Sun's Java Virtual Machine Specification contemplates invoking native code.

b. Microsoft's Keyword Extensions and Compiler Directives

The TLDA, according to Microsoft, allows it to optimize the Java Technology for the Windows platform and expressly contemplates extensions to the Java language. Furthermore, Microsoft contends that its specific implementation of keyword extensions and compiler directives is not incompatible with Java and does not violate Sun's Java Language Specification or the Java Virtual Machine Specification. Microsoft submits that Sun has not identified a single test which Microsoft's compilers fail. Opposition at 17. However, Sun contends that Microsoft's software development tools fail the Compiler Output Requirement when the source code compiled with Microsoft's compiler includes Microsoft's extended keywords and compiler directives. Sun also states that Microsoft's language extensions violate both the Java Virtual Machine Specification and the Java Language Specification. Sun also argues that the TLDA does not authorize Microsoft to extend the Java language.

The evidence submitted by the parties indicates that as long as a software programmer avoids using Microsoft's keyword extensions and compiler directives, source code will properly compile with any Java compatible compiler and run on any Java virtual machine. Accordingly, the issue distills down to whether the TLDA permits Microsoft to create and distribute its own extended version of the Java language and corresponding compiler, provided that its tool products also have the capability of passing Sun's relevant test suites. The affirmative license grants of the TLDA control this issue. See Cohen, 845 F.2d at 853-54.

The meaning of section 2.6(b)(iv) appears to be dispositive. Microsoft does possess the right to modify and create derivative works of the Java Technology. Section 2. 1(a) of the TLDA grants Microsoft a license to modify, adapt, and create derivative works^[5] of the "Technology" in source code form for the purposes of "developing, compiling to binary form and supporting Products." "Technology" consists of the "Java Runtime Interpreter, Java Classes, Supplemental Java Classes, Java Compiler, and all Upgrades." TLDA § 1.25. However, the TLDA confines Microsoft's right to distribute derivative works of the Java Technology to compatible implementations.

The TLDA separately authorizes Microsoft to distribute "Products" including derivative works of the "Technology" provided that they pass Sun's relevant test suite. TLDA §§ 2.2(a)(ii), (iii); 2.6(a), (b). The TLDA sets forth Microsoft's compatibility obligations with respect to its compiler. See TLDA § 2.6(b)(iv) (Microsoft's compiler "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.").

Sun and Microsoft attribute materially different meanings to section 2.6(b)(iv). Microsoft contends that section 2.6(b)(iv) evidences the parties' understanding that Microsoft could extend the Java language as long as its compiler includes a mode which disables these extensions and, therefore, passes Sun's test suite.^[6] Sun, on the other hand, asserts that the "mode" language of section 2.6(b)(iv) only allows Microsoft "to include in its compilers the ability to compile code for prior, compatible versions of the Java Technology that were incorporated in earlier products." Reply at 12.

Sun has demonstrated a reasonable likelihood of establishing that the TLDA does not authorize Microsoft's extension of the Java language and its corresponding modifications to the Java language compiler. Sun's showing of likely success as to Microsoft's language extensions is not as strong as its demonstration of likely success as to JNI; however, Sun's showing warrants some form of preliminary injunctive relief. The literal language of section 2.6(b)(iv) supports the interpretation of both Sun and Microsoft. Similarly, the extrinsic evidence offered by Sun as to what was understood by the "mode" language directly conflicts with Microsoft's extrinsic evidence. However, the Java Language Specification and the context in which section 2.6(b)(iv) appears in the TLDA support Sun's position that Microsoft's language extensions and modified compiler are not authorized.

The compatibility requirements set forth in the TLDA, with respect to both the runtime interpreter and compiler, mandate compliance with the Java Technology as reasonably upgraded by Sun. See generally TLDA §§ 2.6(a), (b). The TLDA contemplates that Sun will upgrade the technology and designate "Significant Upgrades." TLDA §§ 2.6(b)(iii), (iv). "[A]ny new version of a Product that includes the Java Language compilation function shall include a mode which ... permit[s] such Product to pass the Java Language Test Suite that accompanied the Significant Upgrade." TLDA § 2.6(b)(iv). Against this backdrop, section 2.6(b)(iv) appears only to allow Microsoft to include in its compiler modes that compile code for earlier versions of the Java Technology, as long as it also includes a mode which compiles code in conformance with Sun's most recent Significant Upgrade of the Java Technology. Microsoft points to no other language in the TLDA that purports to affirmatively allow Microsoft to modify the Java compiler to accept nonstandard keywords and compiler directives. Indeed, Microsoft's asserted interpretation is antithetical to one of the stated purposes of the TLDA. See TLDA Recitals ("SUN wishes to license its Java technology, while maintaining compatibility among Java language based products."); see also JLSpec. at xxiii ("[A] Java program should compute the same result on all machines and in all implementations.").

The Java Language Specification also suggests that Microsoft's keyword extensions are prohibited. The Java Language Specification defines all of the keywords for the language and reserves two keywords which are not currently used. JLSpec. at 18-19., The authors of the current Java Language Specification intended that "the behavior of every language construct [be] specified [in the Java Language Specification], so that all implementations of Java will accept the same programs." JLSpec. at xxiii. Therefore, adopting non-standard keywords and modifying a compiler to accept them violate Java's main objective that a "Java program should compute the same result on all machines and all implementations." Id.

Furthermore, Microsoft's compiler directives violate the Java Virtual Machine Specification. Id. ¶¶ 31, 32. The Java Virtual Machine Specification states that "[a]ttributes not defined in this specification are not allowed to affect the semantics of the class file, but only to provide additional descriptive information (§ 4.7.1)." JVMSpec. § 4.6; see also JVMSpec. § 4.7.1. As Microsoft's own experts indicate, when, for example, the "@dll" compiler directive is encountered by a Microsoft compiler in its default (extended) mode, the resulting binary file contains (1) a method with the ACC-NATIVE flag set to indicate that native code must be connected and (2) a new attribute providing necessary additional information. See Huhns Decl. ¶ 59; Lee Decl. ¶ 39. Dr. Lee, one of Microsoft's experts, states that semantics "refers to the actual meaning or behavior of a program or file format." Lee Decl. ¶ 35. The Java Virtual Machine Specification indicates that the runtime interpreter should ignore any attribute which it does not recognize. JVMSpec. at 106, 107. However, with respect to the "@dll" and "@corn" compiler directives, the proper functioning of a software application requires recognition of a new attribute which contains necessary additional information, rather than mere descriptive information which a virtual machine can safely ignore. Accordingly, the binary file which results from use of Microsoft's compiler directives violates the Java Virtual Machine Specification since it contains a new attribute that affects program behavior.^[7]

At least with respect to Microsoft's compiler directives, Sun has also demonstrated that Microsoft's compilers in its development tools fail Sun's Compiler Output Requirement test as contemplated by the TLDA. The JCK 1.1a Test Suite documentation states that the output of a licensee's compiler implementation must execute properly with the JavaSoft Virtual Machine. Schroer Reply Decl. ¶ 4 & Ex. A. Accordingly, Microsoft's "extended" compiler fails the compatibility mandates of the TLDA since it generates output which contains non-standard attributes that affect program semantics and, therefore, fails Sun's Compiler Output Requirement. See Schroer Reply Decl. ¶¶ 7, 8, 11, 12 & Ex. A; Gosling Decl. ¶¶ 18-23 33.

On the other hand, Sun's contention that use of Microsoft's keyword extensions generates output that fails the Compiler Output Requirement is somewhat difficult to reconcile with Microsoft's expressly granted ability to add new functionality to its implementation of Java in the form of additional Java classes. See TLDA § 2.8(a) ("The parties understand and agree that ... [Microsoft] may develop Value Added Open Packages which do not need to call native code interfaces during execution (`Portable VAOPs') and Value Added Open Packages that need to call a native code interface during execution (`Non-Portable VAOPs')."); see also TLDA § 1.28 ("`VAOPs' "delegate,") it generates a crass file having attributes that reference two classes developed by Microsoft ("com.ms.lang.Delegate" and "com.ms.lang.MulticastDelegate"). If a virtual machine, such as Sun's, does not implement these classes, compiled code which calls these classes will not run on that virtual machine. Deutsch Decl. Ex. 6 (DeMichillie Depo. at 61:8-63:14). However, this would appear to occur regardless of the manner in which the compiler generates a class file (i.e., whether it recognized Microsoft's, added keywords and generated the class file or whether it compiled standard Java source code implementing this class file). Furthermore, a class file having an attribute which references a VAOP/Java class apparently would not run on Sun's JDK 1.1 virtual machine if it did not support that VAOP/Java class.^[8] In the present case, however, it is unclear whether com.ms.lang.delegate and com.ms.lang.multicastdelegate are in fact VAOP/Java classes. While these classes are named according to the convention set forth in section 2.8(d) of the TLDA, they appear to be integrated into Microsoft's Java virtual machine, rather than implemented as separate class files.^[9] See DeMichillie Depo. at 62:10-22. In any event, the court makes no determination as to whether Microsoft's delegate and multicast classes are in fact VAOPs. Even assuming that these classes are VAOPs, the TLDA does not authorize Microsoft's use of additional keywords ("multicast" and "delegate") and a modified compiler to generate class files which extend these classes.

3. SDKJ 2.02 and "Test 601"

In light of the evidence discussed in Section I.C.2., Sun has raised a reasonable likelihood of success of establishing that SDKJ 2.02 fails "Test 601" and "Test 2003."

4. Waiver

Microsoft submits that Sun waived its claim of breach by continuing to accept payments from Microsoft under the TLDA. However, waiver requires the intentional relinquishment of a known right. See U.S. v. King Features Entertainment, Inc., 843 F.2d 394, 399 (9th Cir.1988). Sun's acceptance of payment from Microsoft, even when Sun knew that Microsoft was breaching the TLDA's compatibility provisions, does not constitute a waiver of a claim for breach of the TLDA. Section 12.3 of the TLDA requires waivers to be in writing. Further, in light of the circumstances existing between the parties at the time of payment, Sun could not be viewed as intending to relinquish its claims of breach by accepting payment.

B. IRREPARABLE HARM AND BALANCE OF HARDSHIPS

Demonstrating a reasonable likelihood of success on the merits raises a presumption of irreparable harm. Johnson Controls v. Phoenix Control Systems, 886 F.2d 1173, 1174 (9th Cir.1989) (citing Apple Computer Inc. v. Formula Int'l. Inc., 725 F.2d 521, 525 (9th Cir.1984)). The adequacy of money damages does not rebut this presumption. Cadence Design Systems, Inc. v. Avant! Corp., 125 F.3d 824, 827 (9th Cir. 1997). Additionally, where a plaintiff has established a likelihood of success on the merits, the harm which a defendant may suffer from an order enjoining its infringing activity generally becomes a minor consideration. Id. at 829-30. Significant public injury resulting from an injunction, however, may support the denial of injunctive relief. See Abend v. MCA, Inc., 863 F.2d 1465, 1479 (9th Cir.1988), aff'd. sub nom., Stewart v. Abend, 495 U.S. 207, 110 S. Ct. 1750, 109 L. Ed. 2d 184 (1990).

As to compliance with JNI and Microsoft's unauthorized extension of the Java language, Sun has demonstrated a reasonable likelihood of success on the merits and, thus, enjoys a presumption of irreparable harm. Microsoft's argument that, under USAR Systems, Inc. v. Brain Works, Inc., 887 F. Supp. 84 (S.D.N.Y.1995), Sun does not enjoy a presumption of irreparable harm merely rehashes it argument, which the court has rejected, that Sun's claims arise out of breach of contract rather than copyright infringement.

Microsoft also argues that Sun's delay in seeking to enjoin Microsoft rebuts the presumption of irreparable harm. However, the circumstances of the present case do not appear to establish unreasonable delay by Sun. Sun filed its motions before the commercial release of Windows98 and VJ 6.0. See Forry, Inc. v. Neundorfer, Inc., 837 F.2d 259, 267 (6th Cir.1988) (holding that 22-month delay in filing copyright infringement action did not rebut presumption of irreparable harm).

As to the balance of hardships, the potential harm to Microsoft arising out of an injunction requiring support for Sun's JNI does not appear to be unduly burdensome. Sun's application for preliminary injunctive relief only seeks Microsoft's inclusion and support of JNI. Sun does not object to Microsoft's concurrent use of other native interfaces such as RNI or J/Direct. Microsoft estimates that inclusion of support for JNI in Windows98 would require at least ninety days for redevelopment, testing, documentation and distribution. Akerlind Decl. ¶ 12. Microsoft also states that the process of reworking VJ 6.0 to support Sun's JNI would take 180 days and cost about $5 million. Button Decl. ¶ 5.

Sun's requested relief does implicate the public interest. Microsoft submits evidence demonstrating that a variety of third parties would be harmed by an injunction precluding the distribution of Windows98, IE 4.0 and Microsoft's development tools. Specifically, OEM PC Manufacturers would be significantly harmed if Windows98 were immediately enjoined. See Akerlind Decl.. ¶¶ 2-11, 14; Mitchell Decl. An injunction affecting Windows98 also has the potential to significantly harm software distributors and resellers. Schiro Decl. ¶¶ 4-14, 16-18. Additionally, third party software developers who have used SDKJ or VJ 6.0 to develop client Windows-specific applications would be significantly harmed by any injunction affecting Windows98, IE 4.0 or any of Microsoft's software development products. Button Decl. ¶ 3, 9. Further, book and magazine publishers who have developed products relating to VJ 6.0 could be harmed. Id. ¶ 4, 10.

Sun's willingness to temper its requested relief mitigates some of the potential harm asserted by Microsoft. As discussed above, Sun does not seek recall of any Microsoft product already in the distribution channel. As to Windows98 and IE 4.0, Sun is willing to allow Microsoft ninety days to develop and distribute versions which pass Sun's test suites (i.e. support JNI). This ninety-day period, with the right to extend for good cause, should allow Microsoft adequate time to modify its virtual machine to support JNI.

Sun's requested relief as to Microsoft's development tools, however, would cause significant harm to innocent third party software developers. Therefore, the court declines to require Microsoft to immediately cease all further distribution of SDKJ 2.0, SDKJ 3.0 and VJ 6.0 in their present forms prior to a trial on the merits. Nevertheless, Sun is entitled to some preliminary relief which will lessen the harm caused by Microsoft's violation of the TLDA but not cause significant harm to the public.

Third party developers would not be significantly harmed by prohibiting Microsoft from adding new compiler directives, keywords or other language extensions pending trial. Nor would developers be harmed if the mode switch on Microsoft's compiler were changed so that the default mode disallowed Microsoft's extensions and a warning issued if a developer enabled the extensions.

C. SUN'S CLAIM OF UNFAIR COMPETITION

The court's disposition of Sun's motion for preliminary injunctive relief based on copyright infringement achieves much of the relief sought by Sun. Therefore, the court only addresses those aspects of Sun's motion based on unfair competition to the extent that it seeks, to enjoin certain of Microsoft's licensing practices and statements to developers.

Any person or entity who has engaged, engages or threatens to engage "in unfair competition may be enjoined in any court of competent jurisdiction." Cal. Bus. & Prof.Code §§ 17201, 17203. "Unfair competition" includes "any unlawful, unfair or fraudulent business act or practice and unfair deceptive, untrue or misleading advertising." Cal. Bus. & Prof.Code § 17200. Business conduct need not be illegal to be enjoined under section 17203. State Farm Fire & Casualty Co. v. Superior Court, 45 Cal. App. 4th 1093, 1103-05, 53 Cal. Rptr. 2d 229 (1996) (holding that breach of duty of good faith and fair dealing supports injunction under section 17200). Rather, the "test under section 17200 is that a practice merely be unfair." Allied Grape Growers v. Bronco Wine Co., 203 Cal. App. 3d 432, 452, 249 Cal. Rptr. 872 (1988). This test involves balancing the "the impact of the practice or act on its victim ... against the reasons, justifications and motives of the alleged wrongdoer." Klein v. Earth Elements, Inc., 59 Cal. App. 4th 965, 969-70, 69 Cal. Rptr. 2d 623 (1997).

As discussed above, Sun challenges Microsoft's licensing policies to the extent that Microsoft requires its licensees to exclusively distribute Microsoft's virtual machine and to call native code only by use of Microsoft's interfaces (RNI, J/Direct and Java/COM). Sun submits two licensing agreements which contain the offending terms. Sun also objects to Microsoft's "Designed for Windows95/NT" logo licensing program. Sun alleges that Microsoft unfairly requires software developers who wish to use the logo to use only Microsoft's virtual machine in the products they distribute. See Schroer Decl. Ex. L, M, N. Microsoft submits that no Java program developer has ever attempted to certify an application. Thibodeaux Decl. ¶ 3. Microsoft contends that this part of the program will be dropped for lack of interest. McMahon Decl. Ex. 19 (Plamondon Depo. at 139:14-140:7).

The court finds that negotiating for or enforcing the above-mentioned licensing terms constitutes an unfair business practice. Microsoft does not argue that these licensing provisions bear any utility which outweighs the harm asserted by Sun. That Microsoft apparently no longer requires its licensees to adhere to such terms and that it plans to abandon its logo licensing program as to Java provides an insufficient basis for denying Sun its requested relief.^[10]See Polo Fashions, Inc. v. Dick Bruhn Inc., 793 F.2d 1132, 1135-36 (9th Cir.1986).

Additionally, the court finds that Microsoft's designation of its virtual machine as the "Official Reference Implementation of Java on Windows 32-bit platforms" is misleading. The TLDA defines "Reference Implementation VM" as "[Microsoft]-authored Derivative Works or Independent Works of the Java Runtime Interpreter for Win32 Platforms." TLDA § 1.10. However, this definition does not expressly state or imply that Microsoft's runtime interpreter is the Sun designated, official reference implementation for Win32 platforms. Microsoft directs the court to no other language in the TLDA which supports its position.

IV. ORDER

Since the court finds that Sun is likely to prevail on the merits and that it may suffer irreparable harm if Microsoft is not enjoined, a preliminary injunction is hereby issued against Microsoft, and its officers, agents, servants, employees, attorneys, and those in active concert or participation with them who receive actual notice of this order by personal service or otherwise, pending trial, from:

(A) Selling or distributing, directly or indirectly, any operating system or browser product containing or implementing computer program code copied or derived from any Sun copyrighted program code for the Java Technology as that term is defined in the TLDA (i.e., the Java Runtime Interpreter, Java Classes, Supplemental Java Classes, Java Compiler, and all Upgrades), including Windows98 and IE 4.0, ninety (90) days after the date of this order unless such product includes a Java runtime implementation which supports Sun's JNI in a manner which passes the compatibility test suite accompanying the latest version of the Java Technology contained in, implemented by, or emulated by such product;

(B) Selling or distributing, directly or indirectly, any software development tool or product containing or implementing computer program code copied or derived from any Sun copyrighted program code for the Java Technology; as that term is defined in the TLDA, including SDKJ 2.0, SDKJ 3.0 and VJ 6.0, ninety (90) days after the date of this order unless such product:

(1) includes a Java runtime implementation which supports Sun's JNI (including help files, header files, etc.) in a manner which passes the compatibility test suite accompanying the latest version of the Java Technology contained in, implemented by, or emulated by such product,

(2) has the default mode in the compiler configured such that (a) Microsoft's keyword extensions and compiler directives are disabled and (b) has the compiler mode switch such that it enables, rather than disables, such keyword extensions and compiler directives, and

(3) includes a warning which appears when a user elects to use the extended mode of the compiler (either when the user accesses the compiler from a DOS command line or when the user checks a box provided during execution of the compiler software) and which warns the user (a) that use of Microsoft's language extensions will result in compiled code which may not run on all compatible virtual machines, and (b) that future versions of Microsoft's development tools may be prohibited by court order from incorporating keyword extensions and compiler directives not contained in Sun's Java Language Specification; however, nothing in this order prevents Microsoft from removing the mode switch, keyword extensions and compiler directives from its Java software development tools and distributing or selling such resulting implementations.

(C) Selling or distributing SDKJ 2.02 unless such product passes Test 601 and Test 2003;

(D) Conditioning the right to use the "Designed for Windows95(98)/NT" logo on the exclusive distribution of Microsoft's Java virtual machine;

(E) Conditioning any license to any Microsoft product on exclusive use or distribution of Microsoft's Java virtual machine;

(F) Entering into any agreement, condition or arrangement with any third party that requires such third party to exclusively use Microsoft's interfaces to its runtime interpreter when invoking native code;

(G) Advertising any product that contains, implements or emulates the Java Technology as the "official" Java reference implementation; however, nothing in this order prevents Microsoft from making advertising claims with respect to the performance of its reference implementation; and

(H) Incorporating any additional Microsoft keyword extensions or compiler directives into its Java software development tools.

Microsoft may seek a reasonable extension of the ninety-day period provided in sections IV(A) and (B) of this order upon a showing of good cause.

Nothing in this order requires Microsoft to recall any product or from upgrading its products so long as they do not include additional Microsoft keyword extensions or compiler directives. This order does not prevent any purchaser of Microsoft's products from continuing to use them. However, Microsoft shall provide upgrades that meet the requirements of IV(A) and (B) above (for example, by way of service packs on its Website).

Microsoft shall, within fifteen (15) days of this order, notify its customers of this order and the corrective steps to be taken. Such notice shall expressly indicate that the court has preliminarily found that Microsoft has violated its licensing agreement to Sun's Java Technology and that if a final judgment is entered consistent with the court's preliminary findings, Microsoft's keywords and compiler directives not contained in Sun's Java Language Specification (i.e. "multicast," "delegate," "@dll," "@corn," and "security") may be prohibited from being included in any future Microsoft software development tool for Java. Such notice shall be prominently posted on Microsoft's website and included in the next quarterly-release of the Microsoft-Developer Network.

As a condition of this preliminary injunction, Sun shall give security within ten (10) days of this order in the amount of $15,000,000 for the payment of such costs and damages as may be suffered by Microsoft if it is found to have been wrongfully enjoined.

NOTES

[1] Certain language in the LOI supports Sun's contention that the parties initially contemplated only a "browser" deal. See McMahon Decl. Ex. 36 at 1 ("Assuming that we are able to reach a definitive agreement that is consistent with this letter and attachment, MICROSOFT will supply Java support in the Internet Explorer for Windows95 and its successors."); Id. at 4 ("If MICROSOFT is to agree to incorporate the necessary and sufficient Java runtime execution environment and AAPI binaries into MICROSOFT's Internet Explorer browser products. ...").

[2] The conditions under which the final terms of the TLDA were negotiated may explain why the recollections of Sun's and Microsoft's respective negotiators differ substantially as to several material issues.

[3] The TLDA defines "Java Language Test Suite" as "SUN's publicly available test suites for validating that products which compile the Java Language comply with the then-current Java Language Specification as of the date of the test suites." TLDA § 1.13.

[4] Microsoft points out that Sun has created a compiler directive called "@deprecated." The @deprecated directive causes the compiler to print a warning under certain circumstances and does insert a "deprecated" attribute into the output class file. Deutsch Reply Decl. ¶ 8; Gosling Decl. ¶ 36; see also Nuhns Dec. ¶ 55. However, the deprecated attribute does not affect the behavior of the class file. See Deutsch Dec. Ex. 20

[5] The TLDA defines a derivative work as "any revision, modification, ... abridgment, ... expansion ... or other form in which an existing work may be recast, transformed, ported or adapted and which is a `derivative work' under U.S. copyright law." TLDA § 1.5.

[6] Beyond Microsoft's license to create derivative works of the Java Technology and section 2.6(b)(iv) of the TLDA, Microsoft points to no other provision in the TLDA which purports to authorize Microsoft to extend the Java language.

[7] Microsoft's "@security" directive also affects program semantics, but is "used to disable special security facilities implemented on Microsoft's Virtual Machine." Lee Decl. ¶ 37.

[8] According to Sun's logic, the Compiler Output Requirement test would be failed.

[9] If com.ms.lang. Delegate and comp.ms.lang. MulticastDelegate are VAOPs, the fact that a class file containing references to them would fail to execute on Sun's JDK 1.1 Virtual Machine would not appear to be an appropriate basis for asserting that Microsoft's compiler fails the compatibility requirements of the TLDA. Furthermore, even if these classes are not VAOPs, the court makes no determination as to whether the TLDA prevents Microsoft from integrating added functionality directly into its virtual machine.

[10] Moreover, since Microsoft alleges that it no longer seeks such terms from its licensees, it will suffer no harm from this aspect of the court's injunction.