Judge Jackson's Finding of Fact
VI. MICROSOFT’S RESPONSE TO THE THREAT POSED BY SUN’S IMPLEMENTATION OF JAVA
386. For Microsoft, a key to maintaining and reinforcing the applications barrier to entry has been preserving the difficulty of porting applications from Windows to other platforms, and vice versa. In 1996, senior executives at Microsoft became aware that the number of developers writing network-centric applications in the Java programming language had become significant, and that Java was likely to increase in popularity among developers. Microsoft therefore became interested in maximizing the difficulty with which applications written in Java could be ported from Windows to other platforms, and vice versa.
A. Creating a Java Implementation for Windows that Undermined Portability and Was Incompatible with Other Implementations
387. Although Sun intended Java technologies eventually to allow developers to write applications that would run on multiple operating systems without any porting, the Java class libraries have never exposed enough APIs to support full-featured applications. Java developers have thus always needed to rely on platform-specific APIs in order to write applications with advanced functionality. Recognizing this, Sun sponsored a process for the creation of a software method that would allow developers writing in Java to rely directly upon APIs exposed by a particular operating system in a way that would nevertheless allow them to port their applications with relative ease to JVMs running on different operating systems.
388. On March 12, 1996, Sun signed an agreement granting Microsoft the right to distribute and make certain modifications to Sun’s Java technologies. Microsoft used this license to create its own Java development tools and its own Windows-compatible Java runtime environment. Because the motivation behind the Sun-sponsored effort ran counter to Microsoft’s interest in preserving the difficulty of porting, Microsoft independently developed methods for enabling "calls" to "native" Windows code that made porting more difficult than the method that Sun was striving to make standard. Microsoft implemented these different methods in its developer tools and in its JVM. Microsoft also discouraged its business allies from aiding Sun’s effort. For example, Gates told Intel’s CEO in June 1996 that he did not want the Intel Architecture Labs cooperating with Sun to develop methods for calling upon multimedia interfaces in Windows.
389. Since they were custom-built for enabling native calls to Windows, and because they were developed by the firm with the most intimate knowledge of Windows, the native methods that Microsoft produced were slightly easier for developers to use than the method that derived from the Sun-sponsored effort, and Java applications using Microsoft’s methods tended to run faster than ones calling upon Windows APIs with Sun’s method. If a developer relied on Microsoft’s methods rather than Sun’s, however, his Java application would be much more difficult to port from the Windows-compatible JVM to JVMs designed to run on different operating systems.
390. Microsoft easily could have implemented Sun’s native method along with its own in its developer tools and its JVM, thereby allowing Java developers to choose between speed and portability; however, it elected instead to implement only the Microsoft methods. The result was that if a Java developer used the Sun method for making native calls, his application would not run on Microsoft’s version of the Windows JVM, and if he used Microsoft’s native methods, his application would not run on any JVM other than Microsoft’s version. Far from being the unintended consequence of an attempt to help Java developers more easily develop high-performing applications, incompatibility was the intended result of Microsoft’s efforts. In fact, Microsoft would subsequently threaten to use the same tactic against Apple’s QuickTime. Microsoft continued to refuse to implement Sun’s native method until November 1998, when a court ordered it to do so. It then took Microsoft only a few weeks to implement Sun’s native method in its developer tools and JVM.
391. Although the Java class libraries have yet to provide enough functionality to support full-featured applications, they have gradually expanded toward that goal. In 1997, Sun added a class library called Remote Method Invocation, or "RMI," which allowed Java applications written to call upon it to communicate with each other in certain useful ways. Microsoft was not willing to stand by and allow Java developers to rely on new Java class libraries unimpeded. The more that Java developers were able to satisfy their need for functionality by calling upon the Java class libraries, the more portable their applications would become. Microsoft had developed a set of Windows-specific interfaces to provide functionality analogous to the functionality RMI offered; it wanted Java developers to rely on this Windows-specific technology rather than Sun’s cross-platform interface. Microsoft thus refused to include RMI as a standard component of the Java runtime environment for Windows that it shipped with Internet Explorer 4.0.
392. The license agreement it had signed with Sun the previous year obligated Microsoft to offer RMI, at a minimum, on its developer Web site. Microsoft did so, but with respect to the RMI beta release, it buried the link in an obscure location and neglected to include an entry for it in the site’s index. Referring to RMI and any Java developers who might access Microsoft’s site looking for it, a Microsoft employee wrote to his approving manager, "They’ll have to stumble across it to know it’s there. . . . I’d say it’s pretty buried."
393. It is unclear whether Microsoft ultimately placed RMI in a more prominent place on its developer Web site. Even if it did, the fact that RMI was not shipped with Microsoft’s Java runtime environment for Windows meant that Java developers could not rely on its being installed on consumers’ PC systems. If developers wanted their Java applications to call upon communications interfaces guaranteed to be present on Windows users’ systems, they had no choice but to rely on the Microsoft-specific interfaces instead of RMI. Microsoft undertook the effort to remove RMI from the rest of the Java class libraries, instead of simply leaving it in place and allowing developers to choose between it and Windows-specific interfaces, for the sole purpose of making it more difficult for Java developers to write easily portable applications.
394. In a further effort intended to increase the incompatibility between Java applications written for its Windows JVM and other Windows JVMs, and to increase the difficulty of porting Java applications from the Windows environment to other platforms, Microsoft designed its Java developer tools to encourage developers to write their Java applications using certain "keywords" and "compiler directives" that could only be executed properly by Microsoft’s version of the Java runtime environment for Windows. Microsoft encouraged developers to use these extensions by shipping its developer tools with the extensions enabled by default and by failing to warn developers that their use would result in applications that might not run properly with any runtime environment other than Microsoft’s and that would be difficult, and perhaps impossible, to port to JVMs running on other platforms. This action comported with the suggestion that Microsoft’s Thomas Reardon made to his colleagues in November 1996: "[W]e should just quietly grow j++ [Microsoft’s developer tools] share and assume that people will take more advantage of our classes without ever realizing they are building win32-only java apps." Microsoft refused to alter its developer tools until November 1998, when a court ordered it to disable its keywords and compiler directives by default and to warn developers that using Microsoft’s Java extensions would likely cause incompatibilities with non-Microsoft runtime environments.
B. Inducing Developers to Use the Microsoft Implementation of Java Rather than Sun-Compliant Implementations
395. If all Microsoft had done to combat the growth of easily portable Java applications had been to increase the incompatibility between its Java implementation and ones complying with Sun’s standards, the effect might have been limited. For if Sun could have assured developers that a Windows-compatible Java runtime environment that complied with Sun’s standards would be installed on as many Windows PCs as Microsoft’s version, and that it would run Java applications as well as Microsoft’s, developers might have considered the cost in portability associated with relying on Microsoft-specific technologies and instead written their Java applications using Sun’s developer tools. When Netscape announced in May 1995 that it would include with every copy of Navigator a copy of a Windows JVM that complied with Sun’s standards, it appeared that Sun’s Java implementation would achieve the necessary ubiquity on Windows.
396. Determined to induce developers to write Java applications that relied on its version of the runtime environment for Windows rather than on Sun-compliant ones, Microsoft made a large investment of engineering resources to develop a high-performance Windows JVM. This made Microsoft’s version of the runtime environment attractive on its technical merits. To hinder Sun and Netscape from improving the quality of the Windows JVM shipped with Navigator, Microsoft pressured Intel, which was developing a high-performance Windows-compatible JVM, to not share its work with either Sun or Netscape, much less allow Netscape to bundle the Intel JVM with Navigator. Gates was himself involved in this effort. During the August 2, 1995 meeting at which he urged Intel to halt IAL’s development of platform-level software, Gates also announced that Intel’s cooperation with Sun and Netscape to develop a Java runtime environment for systems running on Intel’s microprocessors was one of the issues threatening to undermine cooperation between Intel and Microsoft. By the spring of 1996, Intel had developed a JVM designed to run well on Intel-based systems while complying with Sun’s cross-platform standards. Microsoft executives approached Intel in April of that year and urged that Intel not take any steps toward allowing Netscape to ship this JVM with Navigator.
397. By bundling its version of the Windows JVM with every copy of Internet Explorer and expending some of its surplus monopoly power to maximize the usage of Internet Explorer at Navigator’s expense, Microsoft endowed its Java runtime environment with the unique attribute of guaranteed, enduring ubiquity across the enormous Windows installed base. As one internal Microsoft presentation from January 1997 put it, the company’s response to cross-platform Java entailed "[i]ncreased IE share — integrat[ion] with Windows." Partly as a result of the damage that Microsoft’s efforts against Navigator inflicted on Netscape’s business, Netscape decided in 1998 that it could no longer afford to do the engineering work necessary to continue bundling up-to-date JVMs with Navigator. Consequently, it announced that, starting with version 5.0, Navigator would cease to be a distribution vehicle for JVMs compliant with Sun’s standards.
398. The guaranteed presence of Microsoft’s runtime environment on every Windows PC and the decreasing likelihood that the primary host of the Sun-compliant runtime environment (Navigator) would be present, induced many Java developers to write their applications using Microsoft’s developer tools, for doing so guaranteed that those applications would run in the Java environment most likely to be installed on a Windows user’s PC. Owing to Microsoft’s deliberate design decisions, more developers using Microsoft’s Java developer tools meant that more Java applications would rely on the Windows-specific technologies in Microsoft’s runtime environment and thus would not be portable.
399. Microsoft was not content to rely solely on its anti-Navigator efforts to ensure that its Java runtime environment would be the only one guaranteed to be present on Windows PC systems. After all, Netscape was not the only ISV capable of placing copies of a runtime environment on users’ systems. Many developers of network-centric applications were just as capable of bundling compatible runtime environments with their applications as they were of bundling browsing software. If the right runtime environment already came bundled with the right browsing software, all the more convenient for the ISV. If not (as would increasingly be the case after Netscape stopped bundling a runtime environment with Navigator), though, the ISV could still separately obtain the desired runtime environment and bundle it with every copy of its product.
400. Recognizing ISVs as a channel through which Java runtime environments that complied with Sun’s standards could find their way onto Windows PC systems, Microsoft induced ISVs to distribute Microsoft’s version instead of a Sun-compliant one. First, Microsoft made its JVM available to ISVs separately from Internet Explorer so that those uninterested in bundling browsing software could nevertheless bundle Microsoft’s JVM. Microsoft’s David Cole revealed the motivation for this step in a message he wrote to Jim Allchin in July 1997: "[W]e’ve agreed that we must allow ISVs to redistribute the Java VM standalone, without IE. ISVs that do this are bound into Windows because that’s the only place the VM works, and it keeps them away from Sun’s APIs."
401. Microsoft took the further step of offering valuable things to ISVs that agreed to use Microsoft’s Java implementation. Specifically, in the First Wave agreements that it signed with dozens of ISVs in 1997 and 1998, Microsoft conditioned early Windows 98 and Windows NT betas, other technical information, and the right to use certain Microsoft seals of approval on the agreement of those ISVs to use Microsoft’s version of the Windows JVM as the "default." Microsoft and the ISVs all read this requirement to obligate the ISVs to ensure that their Java applications were compatible with Microsoft’s version of the Windows JVM. The only effective way to ensure compatibility with Microsoft’s JVM was to use Microsoft’s Java developer tools, which in turn meant using Microsoft’s methods for making native calls and (unless the developers were especially wary and sophisticated) Microsoft’s other Java extensions. Thus, a very large percentage of the Java applications that the First Wave ISVs wrote would run only on Microsoft’s version of the Windows JVM. With that in mind, the First Wave ISVs would not have any reason to distribute with their Java applications any JVM other than Microsoft’s. So, in exchange for costly technical support and other blandishments, Microsoft induced dozens of important ISVs to make their Java applications reliant on Windows-specific technologies and to refrain from distributing to Windows users JVMs that complied with Sun’s standards. The record contains no evidence that the relevant provision in the First Wave agreements had any purpose other than to maximize the difficulty of porting Java applications between Windows and other platforms. Microsoft remained free to hold the First Wave ISVs to this provision until a court enjoined its enforcement in November 1998.
402. In addition to the First Wave agreements, Microsoft entered an agreement with at least one ISV that explicitly required it to redistribute Microsoft’s JVM to the exclusion of any other and to rely upon Microsoft’s native methods to the exclusion of any other methods. Such agreements were also prohibited by the November 1998 injunction.
403. Microsoft anticipated that the Java language would become a popular medium in the multimedia arena. It thus wanted to ensure that the Java software created to deliver multimedia content would not rely on Java implementations that fostered portability. RealNetworks developed the most popular software for the creation and play-back of streaming multimedia content. Therefore, Microsoft sought to ensure that, to the extent Java developers relied on RealNetworks’ technologies, they would not be relying on a Java implementation that complied with Sun’s standards. So, in the July 18, 1997 agreement that it entered with RealNetworks, Microsoft conditioned its agreement to distribute RealNetworks’ media player with Internet Explorer on RealNetworks’ agreement to exert its best efforts to ensure that its player primarily use Windows-specific technology, rather than any analogous interfaces that Sun or Netscape might develop, to display multimedia content. Absent this obligation, there would have been no technical reason why RealNetworks could not have designed its media player to support both Microsoft’s technologies and ones developed by Sun or Netscape. Although RealNetworks subsequently announced that it planned to continue developing its own fundamental streaming software, the July 18 agreement limited the extent to which that software would include Java technologies that complied with Sun’s standards.
C. Thwarting the Expansion of the Java Class Libraries
404. As discussed above, Microsoft’s effort to lock developers into its Windows-specific Java implementation included actions designed to discourage developers from taking advantage of Java class libraries such as RMI. Microsoft went further than that, however. In pursuit of its goal of minimizing the portability of Java applications, Microsoft took steps to thwart the very creation of cross-platform Java interfaces. The incorporation of greater functionality into the Java class libraries would have increased the portability of the applications that relied on them, while simultaneously encouraging developers to use Sun-compliant implementations of Java. In one instance of this effort to stunt the growth of the Java class libraries, Microsoft used threats to withhold Windows operating-system support from Intel’s microprocessors and offers to include Intel technology in Windows in order to induce Intel to stop aiding Sun in the development of Java classes that would support innovative multimedia functionality.
405. In November 1995, Microsoft’s Paul Maritz told a senior Intel executive that Intel’s optimization of its multimedia software for Sun’s Java standards was as inimical to Microsoft as Microsoft’s support for non-Intel microprocessors would be to Intel. It was not until 1997, though, that Microsoft prevailed upon Intel to not support Sun’s development of Java classes that would have allowed developers to include certain multimedia features in their Java applications without sacrificing portability.
406. In February 1997, one of Intel’s competitors, called AMD, solicited support from Microsoft for its "3DX" technology, which provided sophisticated multimedia support for games. Microsoft’s Allchin asked Gates whether Microsoft should support 3DX, despite the fact that Intel would oppose it. Gates responded: "If Intel has a real problem with us supporting this then they will have to stop supporting Java Multimedia the way they are. I would gladly give up supporting this if they would back off from their work on JAVA which is terrible for Intel." Near the end of March, Allchin sent another message to Gates and Maritz. In it he wrote, "I am positive that we must do a direct attack on Sun (and probably Oracle). . . . Between ourselves and our partners, we can certainly hurt their (certainly Sun’s) revenue base. . . . We need to get Intel to help us. Today, they are not." Two months later, Eric Engstrom, a Microsoft executive with responsibility for multimedia development, wrote to his superiors that one of Microsoft’s goals was getting "Intel to stop helping Sun create Java Multimedia APIs, especially ones that run well (ie native implementations) on Windows." Engstrom proposed achieving this goal by offering Intel the following deal: Microsoft would incorporate into the Windows API set any multimedia interfaces that Intel agreed to not help Sun incorporate into the Java class libraries. Engstrom’s efforts apparently bore fruit, for he testified at trial that Intel’s IAL subsequently stopped helping Sun to develop class libraries that offered cutting-edge multimedia support.
D. The Effect of Microsoft’s Efforts to Prevent Java from Diminishing the Applications Barrier to Entry
407. Had Microsoft not been committed to protecting and enhancing the applications barrier to entry, it might still have developed a high-performance JVM and enabled Java developers to call upon Windows APIs. Absent this commitment, though, Microsoft would not have taken efforts to maximize the difficulty of porting Java applications written to its implementation and to drastically limit the ability of developers to write Java applications that would run in both Microsoft’s version of the Windows runtime environment and versions complying with Sun’s standards. Nor would Microsoft have endeavored to limit Navigator’s usage share, to induce ISVs to neither use nor distribute non-Microsoft Java technologies, and to impede the expansion of the Java class libraries, had it not been determined to discourage developers from writing applications that would be easy to port between Windows and other platforms. Microsoft’s dedication to the goal of protecting the applications barrier to entry is highlighted by the fact that its efforts to create incompatibility between its JVM and others resulted in fewer applications being able to run on Windows than otherwise would have. Microsoft felt it was worth obstructing the development of Windows-compatible applications where those applications would have been easy to port to other platforms. It is not clear whether, absent Microsoft’s interference, Sun’s Java efforts would by now have facilitated porting between Windows and other platforms enough to weaken the applications barrier to entry. What is clear, however, is that Microsoft has succeeded in greatly impeding Java’s progress to that end with a series of actions whose sole purpose and effect were to do precisely that.