|
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. UNITED STATES DISTRICT COURT
I, Robert Muglia, declare as follows: 1. I am Senior Vice President, Applications and Tools Group, of Microsoft Corporation. I make this Declaration of my own personal knowledge. If I were called as a witness, I would and could testify competently to each matter stated herein. 2. During the summer and fall of 1995, the Internet was growing in importance. Microsoft, which had been focusing on the launch and success of Windows 95, had not yet developed a comprehensive Internet Strategy. We heard from our customers that they wanted Microsoft to support new Internet technologies including HTML and Java. 3. Microsoft announced its Internet strategy on December 7, 1995. At that event, Microsoft outlined an approach where it would embrace existing Internet standards and work with the industry to drive innovation forward. 4. In preparation for the December 7th event, Microsoft and Sun had signed a Letter of Intent. The LOI established the basic structure upon which the parties’ contract would eventually be based. Microsoft agreed that its implementation of Java would be compatible with Java applets written to run on other platforms. In turn, Sun agreed that Microsoft could extend Java to allow programs written in the Java language to take advantage of the platform specific features of Windows, which are written in "native-code," such as C++. 5. The LOI established a framework upon which Sun and Microsoft were able to agree. There is tension in that framework, because Sun’s objective was to establish a new platform-independent environment, while Microsoft’s objective was to continue to demonstrate the value of Windows. Yet, even with this underlying competitive tension, the approach of the LOI was good for the industry and the parties, because it encouraged innovation. Sun was free to innovate with Java. Microsoft was free to innovate in its implementation of Java in its products, with the assurance that Microsoft could make those innovations available to Java programmers. Most importantly, developers could choose between cross-platform and platform specific approaches to Java, based on the success of the innovation and what was most important to them. Either or both companies could be successful. In any case, end-users and developers would win. 6. The negotiating teams from both Sun and Microsoft changed early in 1996. Alan Baratz joined Sun as the President of Javasoft, and I took over the Java relationship for Microsoft from Roger Heinen. 7. Mr. Baratz and I retained the basic win-win framework that was established in the LOI. However, both of us expressed that there were benefits to expanding the scope of the license. Microsoft thought its customers would benefit from a broader license. First, it was clear that Java was a good language and thus it made sense to allow Java applications to access the functionality of Windows. Second, Microsoft wanted to establish a longer-term relationship with Sun, so that Microsoft’s customers could stay up-to-date with any innovations Sun made to the Java language. 8. Likewise, Mr. Baratz expressed the view that Sun would benefit from a broader agreement. He indicated that the broad distribution that Windows would bring to Java was attractive. Mr. Baratz also said that he saw this agreement as an opportunity to change his business model. Previously, Sun licensed its Java source code very broadly to a diverse set of licensees. Mr. Baratz indicated that with the Microsoft agreement, Sun would instead focus on licensing to platform vendors – Microsoft, IBM, HP, Digital, Apple, etc. The idea was to let the platform vendors decide how to optimize Java for their respective platforms and provide a set of "reference implementations" back to Sun for sublicensing to the rest of the industry on a non-discriminatory basis. 9. This had an important implication for Microsoft. If Microsoft was going to put significant resources into optimizing Java for Windows, we needed to have control over how the optimization was done. Windows supports a number of technical standards, such as COM, that pervade its many millions of lines of code. It was untenable to think that Microsoft would be required by its agreement with Sun to support alternative technologies in its Java VM that could require massive investments with uncertain results. Microsoft had already made substantial progress on its own implementation of the Java Virtual Machine (VM), and a Java compiler, and it was clear to Microsoft engineers that this implementation could be improved in terms of performance and reliability if it was optimized to work closely with the underlying services of Windows. Thus, in order to optimize Java for Windows, Microsoft needed to be able to control the programming interfaces that join the VM with the rest of the Windows environment. 10. This optimization would impact the way a C++ program interacts with the Java VM. C++ programs are always platform specific, so the interaction between a C++ program and the Java VM does not impact programs written in Java. During the contract negotiations, we discussed this issue with Mr. Baratz and his team and they agreed that Microsoft alone would define the interfaces to Microsoft’s Java VM. I clearly remember one occasion in particular on the eve of signing the final agreement, when Mr. Baratz specifically told me that Microsoft alone would define the interfaces to its VM. Sun’s focus was on Java programs, not native Windows C++ applications. Given this, Mr. Baratz agreed that having Microsoft optimize the Java VM for Windows and define the way the VM works with native Windows applications would benefit Java developers. The ability to define the interfaces to the VM was a deal-breaker for Microsoft. Consequently, Microsoft would not have entered into the contract with Sun if we had not been assured that we would be able to define those interfaces. 11. Many other details that were initially discussed in the LOI were finalized during the contract negotiations. We explained to Sun that Microsoft’s own implementation of a Java VM was well underway. We explained that one of the ways Microsoft’s VM would provide better optimization for Windows would be through support of the Windows object model, COM. We also discussed the inevitability of Microsoft making extensions to the Java language. Microsoft’s first business was development tools, and Microsoft has had many language products over the years. Without exception, Microsoft’s developer customers have asked for features that can only be accomplished by extending the language. For example, Microsoft and other companies have made many extensions to programming languages such as Fortran and C++. The issue of Microsoft extending the Java language was discussed in-depth with Mr. Baratz and his team on multiple occasions. They agreed that Microsoft could do this, but that Microsoft had to create a mode in its tools that supported the Java language consistent with Sun’s specification. Again, the parties established the context for a win-win compromise that gives the developer the choice to build either cross-platform or Windows-specific programs. 12. In mid-March, 1996, Microsoft planned a large Professional Developers Conference (PDC), where we would roll out the details of our Internet strategy to very technical system developers. This conference set a deadline for Microsoft’s Java contract negotiations with Sun. 13. By March, 1996, the internal development of Microsoft’s Java VM was quite advanced. Microsoft had the option to move forward and support Java on Windows without any formal license from Sun. 14. As is often the case, the PDC deadline was approaching and the parties still had to resolve the important issue of price. Mr. Baratz expressed that, because the license was broader than contemplated in the LOI, and would include rights for Microsoft to include the technology in all Microsoft products, the price should be higher. Microsoft agreed in principal, but of course wanted the price to be fair. Finally, on the Friday before the PDC, both sides agreed to a five year contract at $3.5 million per year, with an additional $250,000 per year for support. 15. There were still many details, however, that needed to be finalized. The negotiating teams worked all weekend to incorporate the business terms into the agreement. We flew down to JavaSoft’s new Cupertino offices to start the final discussions at 10:00 a.m. on Monday morning. After an 18 ¾ hour negotiating session, Mr. Baratz and I signed the final agreement at 4:45 a.m. the next morning. 16. The final agreement retained the win-win concept of the LOI. Microsoft would pass Sun’s test suites only with respect to the Applet APIs and the Java language. Sun could not test for native interfaces. Sun could extend the Applet API, but Sun would be required to deliver its enhancements so that they ran on Microsoft’s existing Java VM. Microsoft would not be obligated to incorporate those enhancements into its products, but would distribute the technology via alternative channels, such as the Internet. Microsoft would have the right to optimize Java for Windows. Microsoft also could create Java tool products with language extensions that were optimized for Windows but these products needed to include a mode that would compile the basic Java programming language. Microsoft retained control of any native code interfaces in its implementation of the Java Virtual Machine, but Sun could change those interfaces before licensing Microsoft’s Java VM to third parties. Sun also obtained widespread distribution of Java and $17.5 million from Microsoft. 17. Less than four hours after signing the agreement, Microsoft’s Paul Maritz announced the agreement at the Professional Developers Conference in San Francisco. During Paul’s talk, we gave the first public demonstration of Java support in Internet Explorer. Microsoft had not yet received a single line of source code from Sun. 18. The reception to Microsoft’s Internet strategy from the developers at the PDC was very positive. Microsoft engineers began looking seriously at how Microsoft could apply the technology within Microsoft products. Java is a very good language, so this was an attractive proposition to many engineers. 19. For the first few weeks after the contract was signed, there was a spirit of cooperation between Sun and Microsoft. Microsoft’s engineers shared information about Microsoft’s Java implementation freely with Sun. Mr. Baratz and I continued to talk about how we could effectively work together. It was apparent to me that from a technical perspective, our integration of Java and COM was proceeding well and that this would be a very positive feature for any Java developer. At that time Java lacked an object model. We had already licensed COM to several companies, including Digital, so COM support as a standard feature of Java seemed logical. During a discussion with Mr. Baratz, I offered to license COM to Sun. 20. In May, we held a design preview for key companies who were interested in Java to describe the technical details of our Java implementation. Sun sent several senior technical representatives to that preview. We showed the work we had done integrating Java with Microsoft's COM interface. We also shared specifications for other interfaces to the Microsoft VM, including Microsoft’s native code interfaces, such as our basic interface to C++ programs ("RNI") and our debugging interface. 21. The first sign of problems between the two companies happened during the preparations for Sun’s JavaOne conference. At the JavaOne conference itself, Sun revealed its true intentions. Without any warning or prior discussion, Mr. Baratz announced a new object model for Java – JavaBeans. This announcement hit me, my management, and our engineering teams like a ton of bricks. 22. The announcement of JavaBeans was disturbing because Microsoft’s contract with Sun stipulated that Microsoft was to get the same information regarding changes to the Java Technology in the same time frame as other Java licensees. We had offered to license COM to Sun and work in good faith to incorporate it into Java. Companies like IBM, Netscape, and Borland were at the conference announcing support and explaining how they would use JavaBeans. It was obvious that they had been briefed about the technology by Sun, and that Microsoft had been deliberately excluded from these briefings. Sun never mentioned JavaBeans to Microsoft until Mr. Baratz called me late in the afternoon on the day before JavaBeans was announced. 23. JavaOne and the JavaBeans announcement changed our relationship with Sun. Microsoft people learned of their true intent and could no longer think of Sun as a partner. The unfortunate war of words began. 24. During the summer of 1996, Sun began to discuss the features of JDK 1.1, the new version of its developers’ kit. Sun indicated that it would, for the first time, specify a basic native code interface to allow C++ programs to work with their Java VM. This interface is known as Java Native Interface ("JNI"). Because it is a native code C++ interface, it has no impact on developers writing programs in Java. Microsoft knew that from a contractual perspective, we were not obligated to support Sun’s definition and that only Microsoft had the right to define these interfaces in our VM. However, Microsoft saw it in everybody’s interest to attempt to agree with Sun on a basic native code interface. 25. Microsoft’s engineers attempted to work with their Sun counterparts to define a common, basic native code interface. Microsoft tried to participate in Sun’s design process. Although Microsoft engineers had obvious experience and had supplied a full set of specifications to Sun, Sun chose to ignore all of Microsoft’s input. The JNI interface that Sun eventually chose had no resemblance to the RNI interface in Microsoft’s VM. 26. In the fall of 1996 as we learned more about Sun’s plans for JDK 1.1 it became apparent that Sun did not plan to uphold its contractual obligation to make JDK 1.1 backward compatible with JDK 1.0. This was harmful to Java developers, because many Java applications written to JDK 1.0 would not run in JDK 1.1-enabled Virtual Machines and browsers. This forced developers to rebuild their applications and make changes to the code. We have learned over the years that this is very painful for customers, so in every version of a Microsoft operating system, Microsoft puts enormous energy into compatibility. Sun ignored Microsoft’s objections and refused to correct the incompatibilities in JDK 1.1, which caused Microsoft and many independent software developers to expend significant engineering and test resources. 27. I was very surprised to later learn that Mr. Baratz expected Microsoft to support JNI. We had explicitly discussed this issue during our contract negotiations. Based on my statements during those negotiations and Sun’s responses, it was clear that Microsoft would define the native code interfaces and would have no obligation to follow any Sun specifications or pass any tests in this area. This was critical because Microsoft was committing significant resources to build an implementation of the VM that was specifically optimized for Windows. This point was not negotiable from Microsoft’s perspective for three reasons: 1) the uncertain technical feasibility of supporting different interfaces given our Java VM implementation, 2) concerns about performance and size of alternative interfaces, and 3) our commitment to Windows C++ programming standards such as COM. Again, Microsoft’s obligation under the contract pertained to compatibility with programs written in Java, not with native code written in C++. 28. Given these circumstances, it was hard to work together. Still, both sides tried to resolve the issue. Mr. Baratz and I both agreed that the best way to solve the problem was to come to agreement on a common, basic native code interface. In early 1997, the engineers from both companies began working through the issues. Sun was unwilling to address our technical concerns and the discussions did not produce an agreement. It was at this time that Mr. Baratz first informed us of Sun’s plans to introduce test suites for JNI. From our perspective, the introduction of these test suites was clearly an attempt to force Microsoft to adopt JNI even though we had no contractual obligation to do so. I told Mr. Baratz at that time that Microsoft had no obligation to pass tests related to Sun’s native code interfaces and that we viewed the introduction of such tests as being directly contrary to our agreement. 29. To our great surprise in early October, Sun filed suit against us. We had just released a new version of Internet Explorer that provided a high quality, compatible implementation of Java 1.1 – compatibility that Microsoft’s competitors have yet to deliver. The parties’ contract included a well-defined process to resolve disputes. In suing Microsoft, Sun completely bypassed the mechanism for resolving differences which we both agreed to in the contract. 30. Once Sun sued Microsoft, Sun stopped delivering Java updates to Microsoft. Therefore, despite the parties’ contract and Microsoft’s payment to Sun of $11 million, including our most recent payment to Sun of $3.5 million in May, Microsoft no longer has access to the new Java technology that Sun has developed. 31. On May 12, 1998, Sun filed for a preliminary injunction against Windows 98 and other Microsoft products. Prior to this filing we had informed Sun that Windows 98 passed Sun’s signature tests. The only open dispute with Windows 98 was the native code tests for JNI. 32. In late June, I learned that Sun had submitted a supplemental declaration in which it alleged a new "failure" related to a tool provided in Sun’s JDK which they call an "RMI Compiler." This technology, as delivered by Sun, does not run on Microsoft’s existing VM. On July 1, I wrote to Alan Baratz advising him that this technology constitutes a supplemental class under our agreement which Sun must deliver to Microsoft in working order on our existing Java VM. I assured Mr. Baratz that Microsoft would immediately post this supplemental class to our web site once it was delivered to Microsoft in working order in the form required by our contract. A true and correct copy of this letter is attached hereto as Exhibit A. Mr. Baratz wrote back to me on August 5, conceding that the RMI Compiler is a supplemental class but disputing Sun’s obligation to make it work on our existing Java VM. Microsoft remains ready to distribute the RMI compiler on its web site when it is delivered to us in working order. 33. I understand that Sun has suggested to the court that forcing Microsoft to support alternative native code interfaces would not be a burden. This is untrue. Not only is it a burden, it may not even be possible. The issue is not limited to JNI. Beyond JNI, Sun has demanded that Microsoft support any native interface that it defines –interfaces for debugging, invocation, profiling, just-in-time compilation, and any other native interface that Sun chooses. Sun wants to change these interfaces at their discretion and demands that Microsoft support all such changes. Because of the tight relationship between the Java VM implementation and native code interfaces, nobody knows whether it will ever be technically feasible for Microsoft to support the native code interfaces defined by Sun. These unreasonable demands have no basis in our contract. I declare under the penalty of perjury under the laws of the State of California and the United States that the foregoing is true and correct. Dated August 6th, 1998 at Redmond, Washington.
|
|
