Microsoft Was Inducing Developers to Use Their Implementation of Java Rather Than Sun's

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 Windowscompatible 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 upto- 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.

     
     

About HackerNoon Legal PDF Series: We bring you the most important technical and insightful public domain court case filings.

This court case Civil Action No. 98-1232 (TPJ) retrieved on 2-13-2023, from justice.gov is part of the public domain. The court-created documents are works of the federal government, and under copyright law, are automatically placed in the public domain and may be shared without legal restriction.