|
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 Archive Corporation v. Cipher Data Products, Inc., 1988 U.S. Dist. LEXIS 17190 Environmental Defense Fund, Inc. v. Armstrong, 352 F. Supp. 50, (N.D. Cal. 1988)24 Haskell v. Time, Inc., 857 F. Supp. 1392 (ED. Cal. 1994)22 Sega Enterprises Ltd. v. Accolade, Inc. 977 F.2d 1510 (9th Cir. 1992)18 The Ingle Co. v. Videotours, Inc., 1997 U.S. App. LEXIS 423 (9th Cir. 1997)21 STATE CASES Klein v. Natures Natural Recipes, Inc., 59 Cal. App. 4th 965 (1997)21 STATE STATUTES Cal. Bus. & Prof. Code § 1720019, 21 MISCELLANEOUS Van Der Linden, Not Just Java (1997)19 I. SUMMARY Sun’s motion requests that the Court halt distribution of Microsoft's flagship products, with drastic consequences for Microsoft and millions of software developers and customers. Yet its motion is based on a record consisting largely of redacted email sound bites, hyperbole and speculative opinions bearing little relation to the Technology License and Distribution Agreement ("TLDA") or the facts. The Microsoft products that Sun seeks to enjoin pass the tests for compatibility with the Applet Application Programming Interface that is defined in the TLDA. Microsoft's enhanced Java software development tools afford Java programmers an explicit choice of creating rich, full-featured Windows applications, or least-common-denominator Java applications that are restricted to the limited functionality provided by Sun. This choice certainly means competition for Sun, but there is nothing unfair about it. The claims asserted by Sun are inconsistent with the TLDA and the facts:
It is the TLDA, not Sun's changing plans for Java, that defines Microsoft's obligations. The TLDA Applet Application Programming Interface ("AAPI") compatibility is the extent of the compatibility testing to which Microsoft agreed. Contrary to Sun’s current interpretation of the TLDA, Microsoft never agreed that its products would pass any tests Sun might arbitrarily include in future versions of the JCK suite, such as the JNI tests, which have nothing to do with Java or the AAPI. Sun’s interpretation is unreasonable. Microsoft understood that its interests and Sun's interests in Java might diverge. Microsoft insisted on, and the TLDA contains, provisions to protect Microsoft in such an eventuality. Sun is now asking the Court to re-write the TLDA to remove these protections. Sun also seeks to prohibit Microsoft's enhancements to its Java developer's tools. Sun wants developers to shun Windows programming and restrict their applications to the least-common-denominator features of "pure Java," thereby adhering to Sun’s vision of a Java platform which would ultimately replace Windows. Microsoft’s products, on the other hand, offer software developers and end-users increased functionality while giving developers a choice between enhanced functionality and portability. This is not only consistent with the TLDA, but pro-competitive as well. There is no evidence of irreparable harm to Sun. Competition is not a harm that justifies an injunction. Sun has provided no evidence that any consumer or developer has been injured by the fact that Microsoft has declined to implement JNI in its products or that Microsoft has provided Java developers with enhanced Java tools to help them create Windows applications. The fact that Sun delayed in bringing its motion for almost a year, after it was aware of the "incompatibilities" on which its motion is based, also disproves Sun’s claim of irreparable harm. In contrast, Sun's proposed injunction would cause severe damage to Microsoft and innocent third parties, who depend on the Microsoft products that Sun seeks to remove from the market. Even a temporary disruption in the availability of Windows 98 would have a profound effect - to the tune of billions of dollars - on Microsoft, computer manufacturers, and software developers who have planned their businesses around Windows and Microsoft’s developer tools. II. FACTS
The language of the TLDA demonstrates that Microsoft has not violated its terms or
engaged in unfair competition. The business context of the TLDA demonstrates how Sun is
attempting to contort the TLDA to avoid the deal it made.
Microsoft Windows, first introduced in 1985, is the most widely used operating system for Intel-based personal computers ("PCs"). Windows supplies low-level software services that a programmer uses in creating an application. For example, Windows provides user interface components, such as menus or buttons, which Independent Software Developers ("ISVs") use rather than creating them from scratch. These Windows services are accessed by developers through the Windows Application Programming Interfaces or "APIs." Microsoft has for many years invested heavily in Windows to make it the most attractive development environment for ISVs. When ISVs create useful and desirable applications using Windows, Microsoft benefits because demand for these products also creates demand for Windows.
Sun is in the business of selling proprietary hardware running Sun's "Solaris" operating system. Sun's computer business competes with vendors of Intel-based computers, including network servers running the Microsoft Windows NT operating system. Sun also attempts to convince ISVs to write applications for Sun's proprietary operating system and to take advantage of Sun’s APIs. To the extent that popular applications are available for Sun’s operating system, Sun's hardware and software business are benefited. To the extent developers devote their resources to other platforms, such as Windows, Sun's business is diminished. The popularity of Intel-based computers running Windows and Windows NT poses a problem for Sun. As Intel-based computers running Windows become more powerful, less expensive, and more ubiquitous, there is less reason for ISVs to target Sun's proprietary platform.
The Java programming language was created in 1990. Ex. 11 (Gosling Dep. 31:24-32:16). With the advent of the Internet, Sun realized that Java might be a way to attack the market for Intel-based computers running Windows. Ex. 20 (Schmidt Dep. 168:11-171:12). In a high-level internal briefing to Sun’s top executives in 1995, Sun's Chief Technology Officer Eric Schmidt laid out Sun's plan to evolve Java into an operating system platform (the "Java Platform") and "Attack Novell, Lotus, Borland, Microsoft Franchises." Ex. 69. Sun's plan called for creation of a set of APIs that would become an Internet operating system that would be "layered software on Windows." Ex. 69; Ex. 20 (Schmidt Dep. 172:3-21). Pursuant to this plan, the Java Platform would replace Windows as the APIs that developers would target instead of Windows. Ex. 20 (Schmidt Dep. 172:3-174:21). Sun recruited Netscape to join the effort. Joy told his colleagues in February of 1996 that Netscape should: 4) stop being paranoid about hotjava. its not the enemy, microsoft is. 5) remember that we did the deal with msft after talking to them [Netscape]. they said they thought it was a good idea. input from them in the meantime suggests they are changing their mind, but it is too late. we have to work together to outrun them. maybe microsoft will have java, but this is a trojan horse, if we work to establish api’s together. Ex. 49 (emphasis added). Internally, Microsoft was often referred to as the "evil empire." Ex. 20 (Schmidt Dep. 112:23-113:19); Ex. 38. Sun also recruited Oracle and IBM as allies in the "Java Platform" effort. Ex. 13 (Joy Dep. 603:1-9). Indeed, the latest step in Sun's Java Platform strategy is the August 5, 1998 joint announcement with IBM of the JavaOS, which is postured as "… a thin-client alternative to Microsoft Corp.'s Windows for desktops on a network." Ex. 27.
It was in this business context that the parties negotiated their agreement. The first step in Sun’s Java Platform strategy was to obtain widespread distribution of Java virtual machines. Sun wanted to have Java on 100 million computers. Ex. 20 (Schmidt Dep. 105:16-106:13). Sun needed Microsoft's help to accomplish this, and convincing Microsoft to endorse Java was seen as a big public relations win. Ex. 20 (Schmidt Dep. 105:16-24); Ex. 13 (Joy Dep. 476:15-477:17). Microsoft had what Sun wanted: widespread distribution of Java, Microsoft’s endorsement of Java, a license back to Microsoft’s Java VM and a huge license fee. Although Microsoft had almost completed its own Java VM and Java compiler, a license to the Java Technology would make it easier to meet the planned September 1996 ship date for Internet Explorer 3.0. Muglia Decl., ¶ 14; Ex. 23 (Toutonghi Dep. 75:17-25). However, Microsoft would not give up control of the direction of Microsoft’s Java development and allow its products to become the distribution vehicle for Sun’s competing Java Platform or expose Windows to Sun’s control by relinquishing control of the programming interfaces to Microsoft’s VM. Ex. 17 (Muglia Dep. 115:17-124:15). In the final agreement Sun obtained as much benefit as it could, but Microsoft retained the protections it required. Under the TLDA, Microsoft’s agreement to pass Sun's test suites is limited to the Applet Application Programming Interface ("AAPI"). TLDA §§ 1.1, 1.15 (test suites test are for conformance with the AAPI) Ex. 1. Applets are small programs written in the Java language that require an Internet browser to run. Ex. 72. Microsoft would not agree to put future changes into the Java Technology in its products. TLDA § 2.7a. Instead, Microsoft retained the right to distribute this technology via alternative channels, including the Internet. TLDA § 1.23. A central principle of the TLDA was the parties’ agreement that Microsoft would retain control of the programming interfaces to its Java Virtual Machine. TLDA § 2.9(f); Ex. 17 (Muglia Dep. 115:17-124:1); Ex. 4 (Andersen Dep. 101:17-105:13). Microsoft agreed that Sun could request programming interfaces to Microsoft's Virtual Machine for Java, but that Microsoft had the final say. Id. Sun received a license back to the Microsoft Reference Implementation, which allowed Sun to change Microsoft’s interfaces as it wished and distribute the modified Microsoft VM. TLDA §2.9(a); Ex. 20 (Schmidt Dep. 93:10-23). Microsoft also did not agree to limit its Java implementation to the lowest-common-denominator philosophy of Java. Microsoft retained the right to optimize Java for Windows as long as its Java tools products included a mode that compiled the basic Java programming language. TLDA § 2.6(b)(iv). Microsoft's current products include such a mode. Lee Decl. ¶ 30; Huhns Decl. ¶ 11.
Sun thought that Microsoft's interest in licensing Java was merely a "defensive" move against Netscape, i.e., that Microsoft would not "execute well" and "bring out new functionality, use Java effectively . . ..", and that Sun would be able to "outrun" Microsoft in the Java market. Ex. 39; Ex. 20 (Schmidt Dep. 115:24-117:7). However, in May of 1996, just two months after the TLDA was signed and less than a month after the licensed Java Technology was actually delivered, Microsoft gave Sun executives a demonstration of its Java implementation. What they saw did not make them happy: The really scary thing about the meeting was how much effort they’re putting into it. They’re not using our VM at all, they’re using the one that they wrote from scratch, along our .class files. The clause in the contract which requires them to send source back (which they’re happy to do) isn’t going to be real useful since it bears no relation to ours...." Ex. 42. Sun saw that its perceived head-start on Microsoft in fact did not exist, and that it would have to compete hard to "outrun" Microsoft in the market. Subsequent events only heightened Sun's concern. In September 1996, Microsoft released Internet Explorer 3.0 which was widely acknowledged to have the best, fastest, most compatible Java VM available. PC Magazine reported that IE 3.0 had "the best Java performance by far." Ex. 24, p. 104. Sun's engineers did their own tests of IE 3.0 and sounded the alarm to Mr. McNealy and Mr. Baratz: I don’t care who take [sic] the lead in this, but somebody ought to do something about this NOW. It is especially critical since just yesterday I saw our competitive benchmarks comparing browser performance on various platforms. The benchmarks compared [Sun’s] SS5 running [Sun’s] HotJava, Mr. Coffee running HotJava, Pentium PC running Netscape and Pentium PC running Explorer. The first three platforms were about equal on all benchmarks while [Microsoft’s] Explorer completely blew away every benchmark. Just watching the benchmarks run, you can see it is blazing fast. So combining this compiled/tuned Explorer with a MS [Microsoft] JIT [Just-in-Time Compiler] means a (cheap) Pentium PC will make [Sun’s] NC’s look pathetic unless we do the same. We can’t afford to wait. . . . Ex. 82 (emphasis added). Microsoft’s development of an excellent Java VM created two significant problems for Sun. First, under TLDA section 2.7(a), if Sun developed new Java functionality (which would be implemented with Supplemental Classes), it would have to deliver it to Microsoft running on Microsoft’s Java Virtual Machine. Microsoft’s VM was different than Sun’s, which had already been shipped to Sun’s other licensees. Sun, therefore, would have to maintain two program code bases for each implementation if it shipped Microsoft's version. Second, Sun risked losing the market "footrace" it had been planning on leading. Since TLDA permitted compatibility testing only for Applet APIs, Microsoft’s development of its own VM meant that Microsoft and Sun were diverging on secondary or "low level" APIs such as the native methods interface. Ex. 89. As Sun’s Lindholm queried: What do our licensing terms permit us to say about conforming to these secondary APIs? They are not part of the AAPI, which we have successfully guarded. Are we in any position to require people to support our secondary APIs...?" Ex. 41; Ex. 14 (Kannegaard Dep., 143:24-144:11).
Sun needed a way to slow Microsoft down and get control over Microsoft’s VM. Ex. 40. Sun’s Kannegaard suggested: Three cats to get back in a [sic] the bag: Debugger API, Native Method Interface, JIT API. Abstractly: Design them, add them to a conformance test, put them in release. Ex. 43 (emphasis added). The TLDA also presented a problem for Sun's planned Java Beans technology, which was incompatible with Microsoft's Java VM. When Microsoft discovered this incompatibility in a beta release of JDK 1.1, it reminded Sun that the TLDA obligated Sun to deliver new Java technologies to Microsoft in a form that ran on Microsoft's VM, and which also passed the two previous Sun JCK compatibility test suites. Ex. 37. In the fall of 1996, senior JavaSoft executives decided it was time to read the TLDA for themselves. Mr. Spenhoff, JavaSoft's director of product marketing, read the contract "in detail" and summarized his conclusions in an email to Mr. Kannegaard, providing in relevant part: 1. Msft [Microsoft] were smarter than us when we did the contract. 2. While I doubt that Msft contempated [sic] JavaBeans, they did contemplate that our interests in evolving the platform would conflict with theirs, and they put language in place that not only protected their interests but also inhibited our ability to drive significant new functionality that is not purely bolt-on to the existing Java Classes. What I find most annoying is that no one at Sun saw this coming. I don’t think our folks who negotiated and agreed to these terms understood at the time what they meant. I wonder what is in other contracts? 3. If we adhere to these terms, the Java Classes cannot add substantial new functionality without Msft buy-in. Who knows what this might mean beyond JavaBeans? Code signing? RMI? Native Methods? Anything that does not bolt onto JDK 1.0.2? Lots of other stuff, I bet. A real strict view is that JDK 1.1 probably cannot ship if adhere to these terms because it does not run on Msft’s current reference implementation. It will not even run on JDK 1.0.2. 4. If we adhere to these terms, new Java and Java Platform functionality must be developed as Supplemental Classes without dependence on new features in the Java Classes, or it must have Msft buy-in. 5. In the absence of comprehensive compatibility test suites, Msft de facto owns the definition of Java Compatible. Compatibility test suite only seems to apply to upgrades (2.6 (a)(iii)), which we can only deliver if they run on the Msft Java Reference Implementation. Even where there is a test, all Msft has to do to void it it [sic] to report a "programming error" (2.6 (a)(viii)). Ex. 44 (emphasis added). Kannegaard proposed one way around the TLDA. Sun would invent a new TLDA category called "Extensions" which would be: "stuff that doesn’t fit in T[Technology], or S[Supplemental Classes], that we’ll have to create a new category for." Ex. 45 (emphasis added). Eric Chu, the JDK 1.1 product manager, and David Bowen, Sun’s JDK engineering manager, studied the TLDA and reached the same bleak conclusion as their colleagues: Both Dave and I concluded that based on the contract, we have full rights to enhance the "Java technology" as long as classes not clearly specified in the contract works with their VM. This substantially limits our ability to introduce new technologies since almost all new technologies require a new class. In addition, our attempt to introduce the new category Extensions might not work simply because the definition of Supplemental Java Classes is very very broad. In summary, I believe we’re in violation of the MS contract and our attempt to re-class things as Extensions will have limited success. I don’t believe we can afford to take an aggressive approach with MS unless we’re willing to forego over $15 million of revenue for the next 4+ years with possible high legal cost to consider. Ex. 46 (emphasis added). Plainly JavaSoft executives understood the bargain that had been struck. In response to this discussion, Baratz issued an order to stop reading the TLDA. Ex. 22 (Spenhoff Dep. 127:22-128:21). Mr. Chu did not think Mr. Kannegaard’s "Extensions" plan would work, so he devised his own strategy to get the "cats back in the bag." Chu recommended that Sun approach the problem from the other direction: jury-rig the Java test suites to invalidate any Microsoft implementation which did not contain technology Sun wanted to force into Microsoft's products: If negotiation with MS [Microsoft] is not going well, we can possibly "enhance" the Java Test Suite to invalidate any Java implementation that doesn’t support certain desired new feature. I believe this should be one of the last card [sic] we play if negotiation goes badly. Ex. 81 (emphasis added). Sun apparently settled on Chu's strategy, as it thereafter developed a JCK test for JNI, which is a non-Java native code interface, not written in the Java language, not intended for Java programmers, not part of the AAPI, and not consistent with Sun's WORA philosophy. Lee Decl. ¶ 49; Huhns Decl. ¶ 40. Microsoft did not agree, however, to implement in its products (as opposed to otherwise distributing any Sun technology) everything that Sun could design a test for.
The primary focus of Sun's brief is snippets from Microsoft email messages that refer to competing with Sun or Java, "polluting" or "fragmenting" Java or finding ways to convince Java programmers to write programs for Windows. This is a red herring. Certainly Microsoft intended to compete strongly against any attempt to replace the Windows platform with the Sun Java Platform. Sun was actively campaigning to convince developers not to write to the Windows APIs. Ex. 20 (Schmidt Dep. 149, 171); Ex. 3 (Allchin Dep. 20:1-2) ("And my job is to get developers to write to Windows. So there's a direct conflict there."). Internal email and documents on both sides reflect the heated competition between these companies. Colorful language is common to both sides. See, e.g., Ex. 38 ("Nearly every [Java] licensing negotiation has opened with "We see Java as a way to attack the evil empire."); Ex. 69. Sun referred to Microsoft as the "enemy" and the planned TLDA with Microsoft as a "trojan horse" Sun and its allies would use to attack Microsoft. Ex. 49. Notwithstanding its TLDA obligation to deliver Java updates to Microsoft, Sun discussed with Netscape ways to exclude Microsoft from such Java enhancements. Ex. 66. Sun discussed a secret agreement with its Java licensees, IBM and Netscape, to develop Java technology which (contrary to the TLDA) would not be shared with its licensee Microsoft: In such an arrangement the three companies would cross license all technology to each other in perpetuity, and all would be able to license these libraries, so long as the customer is not Microsoft. Ex. 66. Sun simultaneously declared an "API war" against enemy Microsoft. Ex. 85. Sun based its technology decisions on combating Microsoft rather than creating high-quality products. See e.g., Ex. 77: What if we - Sun -take the following approach, based on a fundamental belief that it will be Java that kills MSFT, not Corba: --Get OMG/Gof4 to endorse RMI as a great foundation for enterprise object distribution in pure Java application environments.... Sun's "Gang of Four," also referred to internally as "Gof4" includes Sun, IBM, Oracle and Netscape. Ex. 78. Microsoft's response to Sun’s Java Platform strategy was to enhance its Java implementation to attract Java programmers to Windows while maintaining compatibility. Attracting developers to the Windows platform is an important and legitimate business objective.
Professional software developers stay in business by creating programs that satisfy the needs of their customers. Hausman Decl. ¶ 7. In deciding what programs to write, developers consider what platform and operating system to target, what programming language to use, the functionality, speed and performance required, and, in some circumstances, the extent to which the program should be able to run on different platforms. Hausman Decl. ¶ 13. If developers need more functionality than Java has to offer, they will choose platform-specific methods over cross-platform portability. Hausman Decl. ¶ 13; Lee Decl. ¶¶ 7, 9; Huhns Decl. ¶ 4. The experience of Corel, Microsoft, and others in the industry, has confirmed how difficult it is to use least-common-denominator Java to develop full-featured applications. Ex. 16 (Gross Dep. 228-230); Hausman Decl. ¶ 14. Microsoft has extended the functionality of Java available in its tools products while giving developers the choice to do "pure Java" development if they wish. Hejlsberg Decl. ¶ 2. These extensions were made for legitimate technical reasons - not to hurt Sun or fragment Java. Id. ¶ 10. They do not make Microsoft's products incompatible. Lee Decl. ¶ 42. If Microsoft’s Windows-specific extensions do not add sufficient value, developers will not use them. Hausman Decl. ¶ 9; Lee Decl. ¶ 12 & 13. If these extensions add sufficient value, programming output will increase, and both software developers and consumers will be better off. Hausman Decl. ¶ 9.
Microsoft has indisputably created the fastest, most efficient, most Java-compatible VM. PC Magazine recently tested Java environments, including offerings from Microsoft, IBM, Netscape and Sun: [¶] The Microsoft Java Virtual Machine (JVM) for Windows was the exception, and it earns our Editors’ Choice. For the second year in a row, Microsoft has produced the fastest and most reliable Java implementation available . . . The Microsoft Java environment came close to a perfect score on our compatibility tests, where it ran all but one applet each on Microsoft Windows 95 and NT. Ex. 24, p. 139. Microsoft also offers software development tools (SDKJ 2.02, 3.0, VJ++6) which provide Java developers with the resources needed to create high-quality Java applications. Pursuant to the TLDA, Microsoft’s products provide developers with enhanced Java functionality, yet permit development of both cross-platform programs and Windows-specific programs. Hejlsberg Decl. ¶ 2.
Visual J++ 6.0 is a full-featured development environment product for professional software developers. Hejlsberg Decl. ¶ 2. Microsoft SDKJ products are lower-end development tools. Both contain Microsoft’s Java VM and Microsoft’s Java compiler. VJ++ 6.0 includes two Java "keywords:" multicast and delegate. Hejlsberg Decl. ¶ 3. These keywords, combined with Microsoft’s new WFC technologies, give Java developers better tools to write high-quality Windows applications in the Java language. Id. ¶ 5. Sun’s JDK technology does not provide these capabilities. Id. ¶ 4. Java developers using Microsoft’s tools decide whether or not to use these Microsoft-specific enhancements in creating their programs. Hejlsberg Decl. ¶ 9; Lee Decl. ¶ 44. If a developer prefers to write a cross-platform Java application, he simply checks a box entitled "Disable Microsoft extensions." Hejlsberg Decl. ¶ 9; Lee Decl. ¶ 30. Likewise, Microsoft’s Java compiler has a mode (as contemplated by TLDA § 2.6(b)(4)) that processes "pure" Java source code and also has a mode which supports Microsoft’s Windows-specific enhancements. Lee Decl. ¶ 30; Huhns Decl. ¶ 11. The modes are changed easily using a standard compiler switch. Id. Industry reviews have confirmed the quality and choice provided by Visual J++ 6.0. PC Week reports: [I]t’s not supportable to accuse Microsoft of twisting Java to its own ends, because all of the Microsoft-specific extensions to Java in Visual J++ 6.0 can be disabled by simple selections of options . . . [D]evelopers who just want to write good Java that runs on any compatible platform will still find Visual J++ 6.0 a well-crafted development system. Ex. 25.
Sun now concedes that all of the Microsoft products which it seeks to enjoin pass the so-called JCK "signature" tests. Schroer Decl. (July 30, 1998) ¶¶ 5-9, Ex. A.
Microsoft does not include JNI in its products because it explicitly reserved the right not to do so, and because JNI is inferior technology. Muglia Decl. ¶¶ 9-10, 16; Toutonghi Decl. ¶ 8; Ex. 88 (Sharpe Dep. 65:9-67:3). JNI is a native interface composed of native C code, intended for programmers writing non-Java program code. Microsoft specifically negotiated to preserve its right to define native code interfaces to its Windows operating systems, and its exercise of this right cannot be unfair competition. Muglia Decl. ¶¶ 9-10, 16. According to Sun, the value of Java is "…write it once, run it anywhere." Sun Mem. at 7. There is no dispute, however, that JNI has nothing to do with this proposition. A program that utilizes JNI is by definition not cross-platform. Toutonghi Decl. ¶ 13; Lee Decl. ¶ 49. As Sun’s Kannegaard acknowledged shortly before Sun brought this action: "JNI, RNI: Positioning is: It ain’t all that big a deal - it’s only relevant to people writing native methods, not to people writing Java." Ex. 76.
Contrary to Sun’s claim, Microsoft’s licensing programs do not require the exclusive use of the Microsoft VM. Microsoft’s SDK distribution licenses require the licensee’s products to support the Microsoft VM, but do not require the exclusive inclusion or support of the Microsoft VM. Ex. 19 (Plamondon Dep. 40:12-41:1). Sun’s Java licenses are of course similar in requiring some degree of support of Sun’s JDK. Microsoft’s "first wave" licenses, for those who want early access to beta versions of new products, require licensees to support IE 4.0 as a browser in their products, but there is no requirement that any other browser or Java VM be excluded. Id. Microsoft also maintains a "Designed for Windows" logo program. Id. (Plamondon Dep. 137:13-140:7). Contrary to Sun’s representation, there is no requirement that developers cannot also use any other VM in those same products. Id. (Plamondon Dep. 40:12-41:1). No Java developer has ever submitted a Java application for certification under the logo program. Ex. 19 (Plamondon Dep. 141:24-142:2; 240:10-241:10); Thibodeaux Decl. ¶ 2. This part of the program will be dropped for lack of interest. Ex. 19 (Plamondon Dep. 139:14-140:2).
Sun has in fact paid little attention to cross-platform compatibility by developing and distributing development kits, such as JDK 1.0 and JDK 1.1, that are not compatible with each other. As PC Magazine observed: The compatibility situation is likely to get worse before it gets better: JDK 1.1 is a substantial change from JDK 1.0, which means that compatibility between the two is not assured. And the delivery of JDK 1.1 support in VMs has been surprisingly slow: JDK 1.1 is only partly implemented in Netscape Communicator and is largely implemented in Internet Explorer 4.0. Ex. 24, p. 103. In an effort to support its "Gang of Four" allies in a battle against Microsoft, Sun has allowed them to flood the market with products that do not pass Sun’s Test Suites. With support for WORA waning in August 1997, Sun believed it needed to keep IBM, Netscape and others "on board" "at all costs." Ex. 57. Thereafter, Sun accommodated IBM and Netscape more than once, despite their failure of Sun’s tests. Furthermore, Sun does not require JNI of itself or of other licensees. Sun’s JavaOS product does not include JNI. According to Ms. Schroer, JavaOS is a Java implementation and therefore should pass the JCK test suites. As she put it: "Looking forward to a 1.1 based JavaOS I wonder whether the JNI will be implemented on JavaOS. If not, I think we have some real explaining to do." Ex. 74. In addition, Sun has excluded JNI tests for other licensees, including "Gang of Four" member IBM. Ex. 71 ("Meantime JNI invocation is in the JCK but on the exclusion list, so no compliance problem.") (emphasis added).
Microsoft, its distributors, retailers, and OEMs, as well as software developers and end users, will be severely damaged if Microsoft is required to re-work its products to incorporate JNI or remove Windows-specific enhancements from its developers tools. The re-working of Microsoft’s products would take months to accomplish. Recalling Windows® 98 from distribution channels would take several weeks. Schiro Decl. ¶ 9. After the recall, it would take another 4-6 weeks re-writing the code, documentation and product packaging, and an additional several weeks to return to the current level of channel inventory. Schiro Decl. ¶ 11. In the interim, Microsoft would incur hundreds of millions of dollars of damage for each month Windows® 98 does not ship, as well as losses from the recall of product already in distribution channels and wasted promotional and advertising. Akerlind Decl., ¶ 14; Schiro Decl., ¶¶ 9-12, 15. Third parties would suffer severely if the shipment of Windows® 98 is enjoined. Windows® 98 is primarily distributed through personal computer makers (Original Equipment Manufacturers or "OEMs"). OEMs such as Compaq have specifically adapted their products to Windows® 98. Mitchell Decl. ¶ 3. Peripheral makers have done this as well. Akerlind Decl. ¶ 9. It may be impractical for OEMs simply to install an older version of Windows 95 (without Internet Explorer), so OEMs may be forced to halt distribution until a revised version of Windows® 98 is available. Mitchell Decl. ¶ 7. Enjoining the shipment of the final release of VJ++6.0 will hurt Microsoft, software developers, other third parties, and consumers. If Microsoft cannot include Windows-specific enhancements in VJ++6.0, it will incur millions of dollars of damages. Button Decl. ¶ 3. If Microsoft must incorporate JNI, it will suffer lost or delayed sales and other damages in excess of $10 million. Id., ¶ 8. Not only will Microsoft lose tremendous revenues, it will suffer a loss of good will. Id., ¶ 6. Independent software developers will also be severely damaged. Approximately 200,000 software developers have used a beta version of VJ++6.0 in the last six months. Button Decl. ¶ 3. These developers may - and do - create programs using the redistributable Microsoft technology in the beta version, but they are not permitted to distribute them until receiving the final version and performing any necessary finishing touches to their programs. Id. Thousands of Java ISVs have written programs using VJ++ 6.0, and will not be able to release their products if Microsoft is enjoined from shipping VJ++6.0. Id. ¶ 9. Third-party publishers of V J++ 6.0 books and magazines will forfeit expenses incurred in anticipation of the release of VJ++ 6.0, in addition to anticipated lost profits. Id. ¶ 10. II. ARGUMENT Sun cannot obtain a preliminary injunction unless it demonstrates (1) a probability of success on its unfair competition claim and irreparable harm, or (2) the existence of serious questions on the merits and a balance of hardships tipping in Sun’s favor. Sega Enterprises Ltd. v. Accolade, Inc., 977 F.2d 1510, 1517 (9th Cir. 1992). Sun cannot demonstrate either. Sun will not succeed on its unfair competition claim. Nothing Microsoft is doing constitutes a violation of the TLDA or an otherwise "unlawful, unfair or fraudulent" act or practice. Nor can Sun show irreparable harm. The absence of JNI does not affect cross-platform compatibility, and Sun has already destroyed any prospect of cross-platform compatibility by letting its anti-Microsoft allies slide on compatibility tests. Further, Sun has known since mid-1997 that Microsoft would not support JNI and would include Microsoft-specific enhancements to its Java implementation. Having waited over a year to bring this motion, Sun may not now complain of irreparable harm. Because of the enormous costs and loss of resources, reputation and goodwill that Microsoft and third parties will suffer if the injunction is issued, the balance of hardships tips decidedly in Microsoft’s favor. Accordingly, Sun’s motion should be denied.
To prevail on an unfair competition claim, Sun must prove that Microsoft committed an "unlawful, unfair or fraudulent business act or practice." Cal. Bus. & Prof. Code § 17200. Sun contends that Microsoft either breached the TLDA, or breached the covenant of good faith and fair dealing, by (1) creating Windows-specific Java enhancements in SDKJ 2.0 and 3.0 and Visual J++ 6.0, (2) not including JNI from its products, (3) requiring its licensees to support the Microsoft VM, and (4) making certain statements to developers. None of these allegations supports a claim under section 17200.
Microsoft has not breached the TLDA by including Windows-specific language extensions in its products or by not including JNI. Even if Microsoft had breached the TLDA, the utility of its products preclude any finding that its competition with Sun is "unfair," and therefore precludes liability under section 17200.
Sun claims that Microsoft’s Windows-specific enhancements in SDKJ 3.0 and Visual J++6.0 (i.e., keywords "multicast" and "delegate" and compiler directives) do not meet Sun’s specification. Sun is incorrect. Lee Decl. ¶ 12. In fact, Microsoft’s products are consistent with Sun’s specifications and will allow developers to make their work easier and more efficient. Lee Decl. ¶¶ 4, 5, 12-17; Huhns Decl. ¶ 59. Furthermore, the Windows-specific features complained of by Sun do not cause Microsoft’s products to fail any JCK tests. Schroer Decl. (7/30/98), ¶¶ 7-9, Ex. A. The fact that Microsoft provides these features to developers cannot constitute a breach of the TLDA or unfair competition.
Microsoft has no obligation to include JNI in its products. Fundamental to Microsoft’s entry into the TLDA was the principle that Microsoft, not Sun, would define internal interfaces between the Microsoft VM and native system code. Indeed, the TLDA would not have happened at all unless, as confirmed to Microsoft just before Microsoft signed the TLDA, Microsoft had the right to define those interfaces. Muglia Decl. ¶ 16; Ex. 17 (Muglia Dep. 115:17-124:15); Maritz Decl. ¶ 8. While Sun’s expert, Dr. Deutsch, has come up with a creative interpretation of the concept of "compatibility," it bears no relation to the parties’ agreement. Deutsch submits that the primary goal is "binary compatibility of native method libraries across all Java VM implementations on a given platform." Deutsch Decl. ¶ 79. Under this theory, all Java VMs for Windows (written by Sun, Borland, Microsoft, etc.) would have to be the same, at least in some respects. That is not, however, what Microsoft and Sun agreed to in the TLDA. The parties agreed to applet compatibility - so that programs written in Java, compiling to Java bytecodes, run on Sun’s VM and other licensees’ VM, as well as Microsoft’s VM. Ex. 17 (Muglia Dep. 201:24-202:15). Microsoft's products provide this compatibility. Lee Decl. ¶¶ 41-42.
Microsoft did not implement JNI for two reasons: it is not required to implement JNI, and JNI is inferior technology. TLDA § 2.9(f). Toutonghi Decl. ¶¶ 8-9, 11-12. If Sun is unhappy with this decision, the TLDA provides the solution. Sun can put JNI in Microsoft’s Reference Implementation for Java (which Microsoft must provide to Sun), and distribute it to anyone it chooses. TLDA § 2.9(a). If Sun’s interface technology - combined with Microsoft’s industry-leading VM - is superior, the market will adopt it. Sun also can attempt to convince developers to adopt its Java VM substitute for the Microsoft Virtual Machine. This product, called "Java Plug In," has been designed by Sun to quickly "plug in" to any system and replace the Microsoft Virtual Machine. Ex. 33. It is distributed free by Sun via download from the Sun's web site. Id. Sun’s allegedly perfect solution for any developer or end-user is just a few mouse clicks away on the Internet. There is no harm to Sun by virtue of the fact that Microsoft does not implement JNI.
To obtain an injunction under section 17200, Sun cannot merely argue that Microsoft has breached the TLDA. See The Ingle Co. v. Videotours, Inc., 1997 U.S. App. LEXIS 423, *22 (9th Cir. 1997) (affirming dismissal of unfair competition claim, noting that "[the plaintiff] cites no case applying section 17200 to a simple breach of contract, and we have found none."). An act or practice is not "illegal" simply because it breaches a contract, and therefore the plaintiff must also establish that the act is not only a breach, but also "unfair." See Klein v. Nature’s Natural Recipes, Inc., 59 Cal. App. 4th 965, 968 (1997). To determine whether an act or practice is unfair, the court must "weigh the utility of the defendant’s conduct against the gravity of the harm to the alleged victim." Id. Microsoft's products provide increased performance and functionality, while preserving the opportunity for developers to choose between this increased performance and portability. The utility of these products clearly outweighs any "harm" to Sun. Hausman Decl. ¶ 22; Lee Decl. ¶ 5. Sun’s accusation that the extensions reflect a "deliberate attempt" to undermine cross-platform compatibility is inconsistent with the facts. These extensions give developers useful tools. They do nothing to undermine Java. Microsoft’s SDKJ and Visual J++ 6.0 give developers a clear opportunity to choose for themselves between creating full-features Windows applications and creating cross-platform applications. Lee Decl. ¶ 5. Developers may prefer performance over portability. Hausman Decl. ¶ 22. Microsoft, however, has no obligation to promote Sun’s plan for a Java platform over Windows - as the TLDA makes clear - or to deprive developers and end users of the benefits of superior Windows applications programs. Sun complains that the functionality of Microsoft’s Windows-specific extensions and native interfaces could have been accomplished without "destroying cross-platform compatibility." Sun Mem. at 16:14-15. Sun’s argument is irrelevant and unsupportable. Microsoft made these enhancements for sound technical reasons: because Sun’s technology was lacking features developers wanted. Hejlsberg Decl. ¶ 4. Sun also claims that Microsoft could have implemented JNI in its products along with Microsoft’s native interface, RNI. This claim is irrelevant and incorrect. The point is not whether Microsoft could have implemented Sun’s JNI in its products, but whether it has to. Microsoft is not required to ship JNI. TLDA § 2.9(f).
Sun provides no evidence that Microsoft has made deceptive statements to developers. Sun alleges that Microsoft advertises that the TLDA designates Microsoft’s implementation of the JAVA Technology as "the official reference implementation" for Win32-based systems and browsers." Sun Mem. at 19. The TLDA does, in fact, define Microsoft’s Java implementation as the reference implementation for Win32-based systems and browsers. TLDA § 1.10. Sun alleges that Microsoft advertises that "[t]he JAVA applications created with the SDKJ will run on any platform," and that SDKJ 3.0 and VJ++ 6.0 are Java compatible. Sun Mem. at 19. Those statements are also true. Lee Decl. ¶ 12. Furthermore, as Sun notes in its moving papers, advertising cannot constitute unfair competition unless it is "likely to deceive" reasonable developers. Haskell v. Time, Inc., 857 F. Supp. 1392, 1397-98 (E.D. Cal. 1994). See Sun Mem. at 24. Sun presents no evidence whatsoever that any developer is deceived, or is likely to be deceived, by Microsoft’s advertisements. To the contrary, developers are well aware of the differences between Sun’s VM and Microsoft’s VM. Hejlsberg Decl. Ex. A & B.
Sun contends that an injunction is necessary to "preserve the integrity of the JAVA technology and the competitive market forces it creates." Sun Mem. at 22:6-7. Sun submits not one shred of competent evidence to support this claim of damage. As discussed above, Sun’s JNI interface has nothing to do with the "WORA" concept which Sun claims to be trying to preserve. Lee Decl. ¶ 49. Use of non-Java code is inconsistent with WORA. As Sun acknowledged in an internal memo in September 1997: JavaSoft products are currently not required to be certified 100% Pure (i.e. we don’t eat our own dogfood) . . . There are planned Java extensions which will be difficult or impossible to implement in Pure Java . . . Heads up: This breaks WORA. Ex. 73 (emphasis added). If, contrary to its internal document, Sun believes JNI is critical to its success then Sun should implement it in the Microsoft VM and distribute it as contemplated by the TLDA. The fact that JNI is not in Microsoft products does not harm Sun at all. To support its claim of harm, Sun offers only the speculations of Kenneth Arrow, who starts and ends his analysis with faulty assumptions lacking a factual basis. First, Arrow ignores the realities of professional software development, especially the reasons that developers want to write programs with robust non-Java functionality. See Hausman Decl. ¶ 15. Second, Arrow ignores the factual basis for the developer’s marketplace, in which sophisticated developers analyze and choose between the performance benefits of Windows-specific developments and the portability advantages of cross-platform compatible programs. Id. ¶ 24; Lee Decl. ¶ 47. That choice is preserved by Microsoft’s products and should be left to the market. Hausman Decl. ¶ 9. Third, Arrow (and Deutsch) ignore the TLDA and any factual analysis of the current state of cross-platform compatibility. Sun’s product maneuverings have so compromised WORA that its demise cannot be blamed on Microsoft. Fourth, Arrow has admitted that his analysis is "unfair" because he considered only the material Sun provided to him, without conducting any research of his own. Ex. 86 (Arrow Dep. 82:8-15). If Sun really thought it was being damaged, it would have brought its motion months ago, before Windows®98 was shipped, when it learned that Microsoft was not going to include JNI in its products. Sun has also known of Microsoft’s proposed enhanced compiler directive for over a year. Sun did not seek an injunction then, and it is not entitled to one now.
This Court was careful in its previous order to explain that "Microsoft’s use of Sun’s JAVA Technology would remain unaffected by the grant of the preliminary injunction requested by Sun," because it only seeks to discontinue Microsoft’s display of the logo. Order at 11. The motion now before this Court, however, would stop the shipment of Microsoft’s most important products. Microsoft will suffer huge costs if the shipment of its products is stopped. It will suffer huge costs and delays if it is forced to include JNI, or precluded from adding Windows-specific enhancements. Button Decl. ¶¶ 5, 8; Schiro Decl. ¶ 15; Akerlind Decl. ¶¶ 12-14. Microsoft will also be fundamentally damaged if it is forced to distribute a competitor’s technology as part of a plan to attack the Windows franchise. Microsoft did not agree to such a provision and forcing such provision on Microsoft would be unfair, unjust and unnecessary. Furthermore, it is well-established that the public interest, including potential harm to third parties, must be considered in deciding whether to issue an injunction. See, e.g., Archive Corporation v. Cipher Data Products, Inc., 1988 U.S. Dist. Lexis 17190 (C. D. Cal. 1988). Where issuance of an injunction will cause severe harm to third parties, the injunction should not be issued. Id.; Environmental Defense Fund, Inc. v. Armstrong, 352 F. Supp. 50, 60-61 (N. D. Cal. 1972). Here, OEMs, distributors, retailers, software developers and end users will be severely harmed if Microsoft’s flagship products are enjoined. Schiro Decl. ¶¶ 12, 15-17; Button Decl. ¶¶ 9, 10; Akerlind Decl. ¶ 15; Hausman Decl. ¶ 37. IV. CONCLUSION For the foregoing reasons, Microsoft respectfully requests that Sun’s motion be denied. Dated this __th day of August, 1998.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
