Reply_Declaration_of_Alan_Baratz_in_Support_of_Sun_Microsystems_Motions_for_Preliminary_Injunction_9_10_1998

30. Reply Declaration of Alan E. Baratz in Support of Sun Microsystems,
Inc.'s Motions for Preliminary Injunction
Legal document in support of Sun's motion to be argued on September 10th,
1998.

I, Alan E. Baratz, declare:

1. I am President of the Java Software Division of Sun Microsystems, Inc ("Sun"). I have been President of Java Software or its predecessor, the JavaSoft Division, since January 1996.
2. I make this declaration of my own personal knowledge. If called to testify as to the truth of the matters stated herein, I could and would do so competently.
3. Before I joined Sun in January 1996, Sun and Microsoft had begun negotiations regarding Microsoft's license of Sun's JAVA^TM technology. Sun and Microsoft signed a non-binding letter of intent regarding a license on December 5, 1995.
4. After my arrival, Sun and Microsoft continued negotiations towards a definitive license agreement. As President of JavaSoft, I took over responsibility for the negotiations from Eric Schmidt. I personally participated in negotiations with Microsoft and was kept apprised of the discussions.
5. The negotiations culminated in a Technology License and Distribution Agreement ("TLDA") between Sun and Microsoft dated March 11, 1996. As President of JavaSoft, I signed the TLDA on behalf of Sun. A true and correct copy of the TLDA is attached as Exhibit A.

AAPI

6. I understand that Microsoft now claims the term "SUN's specification of the AAPI" used in the definition of "Java Test Suite" is somehow limited to the Documentation excerpts listed in sections 1.1(b), 1.1(c) and 1.1(d) of the TLDA and excludes section 1.1(a). I never told any Microsoft representative, nor did I ever hear any Sun representative state, that section 1.1(a) of the definition of "AAPI" was excluded from "SUN's specification of the AAPI" or that the subject matter of section 1.1(a) was not within the scope of subject matter for which Sun could promulgate compatibility tests and with which Microsoft would be obligated to comply. To the contrary, I specifically recall telling Mr. Muglia and other Microsoft representatives on several occasions that as the JAVA^TM technology evolved, Sun's specification of the AAPI, as well as the test suites, would also evolve.

Interfaces to the VM

7. I have read the declaration submitted by Microsoft's Robert Muglia. Mr. Muglia's declaration contains a number of statements that simply are not true.
8. Mr. Muglia claims that "on the eve of signing the final agreement," I "specifically told [him] that Microsoft alone would define the interfaces to its VM." (Muglia Decl., ¶ 10.) Mr. Muglia is wrong. I never told Mr. Muglia, or anyone else for that matter, that "Microsoft alone would define the interfaces to its VM."
9. Mr. Muglia and I did have a conversation regarding native code interfaces during the final negotiating session in Cupertino before the TLDA was signed. Mr. Muglia stated that Microsoft wanted to develop a native code interface and that Microsoft would probably develop such an interface. I told Mr. Muglia that Sun agreed that a native code interface to the JAVA runtime interpreter was an important interface and that Sun planned to make a standard version of the interface as part of the JAVA^TM technology. I also told him that Sun had no problem with Microsoft creating an additional native code interface, if Microsoft thought it needed it. At no time did I agree that "Microsoft alone" would create native code interfaces, or that Microsoft would not be obligated to implement the interfaces created by Sun, including a native code interface, and to do so in a manner that passes Sun's compatibility test suite.
10. I also remember another discussion with Mr. Muglia during the final negotiation session regarding the subject of interfaces to the VM. I told Mr. Muglia that we had spoken with Sun's Bill Joy about the draft TLDA. I explained that Mr. Joy had suggested we go back to an earlier proposal requiring Sun's prior approval before Microsoft introduced any new interfaces to the VM. I then told Mr. Muglia that we had been through that issue, believed our concerns were addressed, and were prepared to go forward with the deal. I told Mr. Muglia that we believed Microsoft's contractual commitment to pass Sun's compatibility test suites, as well as our ability to engage Microsoft in good faith discussions to address any modifications that could not be required by means of the test suites, sufficiently protected Sun's interests with respect to interfaces that Microsoft might add to its implementation of the JAVA virtual machine*.
11. I believe my statements to Mr. Muglia are consistent with the terms of the TLDA. The right granted to Microsoft under the TLDA to create interfaces to the virtual machine does not mean that Sun is precluded from defining standard interfaces such as JNI for all of its licensees and promulgating compatibility tests for conformance with those interfaces. Both Sun and Microsoft can define, implement and publish "interfaces to the Reference Implementation VM" such as a native code interface. (Exh. A [TLDA at § 2.9(e)].) Thus, Sun has the right to specify any interface to the JAVA virtual machine, and to require Microsoft to implement Sun's interface in Microsoft's products in a manner that passes Sun's compatibility tests for the interface. Conversely, Microsoft is free under the terms of the TLDA to develop a native code interface to its implementation of the JAVA Runtime Interpreter, subject, however, to the requirement that its implementation pass Sun's compatibility test suites.
12. Section 2.9 (b) and (f) of the TLDA make that clear. Section 2.9(b) states that "Licensee agrees that the Reference Implementation VM, and any upgrades thereto, shall include the necessary Source Code to implement the functionality of the Java Runtime Interpreter." Since JNI is a public application programming interface to the Java Runtime Interpreter, Microsoft is obligated under section 2.9(b) to include the source code for JNI in its implementation of the JAVA virtual machine in order to "implement the functionality of the Java Runtime Interpreter."
13. Section 2.9(f) addresses cases where Sun wishes to modify an "interface to the Reference Implementation VM" (e.g. a native code interface), but the proposed modification "cannot be adequately expressed through the Test Suites." Section 2.9(f) reflects our agreement that Sun always retained the right to require Microsoft to adopt Sun's specified interfaces and to conform the Microsoft implementation to comply with Sun's test suites. The parties always contemplated that the interfaces to the Reference Implementation VM would be subject to testing through the Test Suites. Section 2.9(f) was designed to act as a safety net for certain types of modifications that could not adequately be expressed through conformance with compatibility tests. Since tests for JNI are adequately expressed through the Test Suites, Microsoft must pass those tests.
14. Microsoft never asserted during the negotiations that it would have sole or exclusive control over native code interfaces or that its products would be excluded from compatibility testing for the interfaces Sun specifies. Moreover, I never stated that Sun could not test for native code interfaces, and neither party ever proposed any draft language barring Sun from testing for native code interfaces.

"Mode" Provision in TLDA

15. Mr. Muglia also inaccurately states that the "issue of Microsoft extending the Java language was discussed in depth with Mr. Baratz and his team on multiple occasions" and that Sun "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." (Muglia Decl., ¶ 11.) I never discussed, much less agreed, that Microsoft would be licensed to "extend" the JAVA^TM language. Indeed, to have done so would have been contrary to the whole purpose of the agreement, which is aptly stated in the recitals as "maintaining compatibility among JAVA language based products." The position Mr. Muglia now claims he asserted would destroy that compatibility, and give Microsoft carte blanche to do with the JAVA^TM language whatever it pleases. Sun would never agree to that position and did not do so in the TLDA.
16. We did agree to grant Microsoft the right to develop new classes that extend the libraries of the JAVA technology. This right is defined in the TLDA as "Value Added Open Packages" ("VAOPs"). (Exh. A [TLDA at § 1.28].) But developing VAOPs is very different than changing the JAVA language. Developing VAOPs is like writing new books in English. Everyone who can read English benefits from the availability of the new books. While Sun did agree to license Microsoft to "write new books" using the JAVA language it never agreed to allow Microsoft to alter or change the language that would be used to write those books.
17. Nonetheless, Microsoft has unilaterally "polluted" the JAVA^TM language by adding unauthorized, non-standard keywords and compiler directives to its JAVA implementations. Only Microsoft's products can "understand" this new language. It's like someone changing the English language by adding new vowels and consonants that change the meaning of the words that use them, and by changing the rules of grammar. Only the people who know the new alphabet or rules of grammar would be able to make sense of the new books being written in this new, polluted form of English. While the TLDA does allow Microsoft to create new classes in the form of VAOPs (i.e., new "books"), it does not allow Microsoft to change the JAVA^TM language.
18. I simply do not understand how Mr. Muglia could interpret anything we ever discussed as suggesting that Microsoft had the right to change the JAVA^TM language. I certainly would have remembered if we discussed this issue on "multiple occasions."
19. I do recall discussions between Sun and Microsoft regarding the "mode" language which appears in section 2.6(b)(iv) of the TLDA. Throughout the negotiations, Sun repeatedly emphasized the need for a commitment from Microsoft to upgrade its products to conform to the latest version of the JAVA^TM technology. In response, Microsoft initially proposed to include a "mode" in both its runtime implementations and compiler implementations that would pass Sun's compatibility test suite. Sun, however, rejected Microsoft's proposal and insisted that each runtime implementation include only the latest version of the Technology. Microsoft ultimately agreed, as reflected in section 2.6(a)(vi).
20. As to compiler implementations, however, Microsoft argued, and Sun ultimately agreed, that it would be desirable for Microsoft to distribute compilers that were capable of compiling programs written in the JAVA language for both prior outdated versions of the JAVA^TM technology, and for the most current version of the technology. Because Microsoft's customers might have an older version of the JAVA^TM technology incorporated into their operating system or browser, Microsoft wanted to be able to make developer tool products that could compile code for the installed base of such prior products as well as the most current products it was currently distributing. The compromise we reached was to allow Microsoft to upgrade its existing compiler implementation to include a mode that supports the most current version of the JAVA^TM technology and passes the most current compatibility test suite.
21. Properly understood, the portion of section 2.6(b)(iv) that requires Microsoft to "include a mode which a Tool customer may use to permit such Product to pass the JAVA Language Test Suite that accompanied the Significant Upgrade," means that Microsoft may continue to distribute its prior, now obsolete, compiler implementation, provided that implementation also includes a mode that incorporates the most current upgraded version of the JAVA technology and passes the test suite that accompanied it. At no time during the negotiations did Microsoft ever suggest that the "mode" language applied to anything other than supporting an older, installed base of products which were previously compatible.

JavaBeans Announcement

22. Mr. Muglia's declaration also inaccurately states that at the JavaOne conference, "Without any warning or prior discussion, Mr. Baratz announced a new object model for Java -- JavaBeans." (Muglia Decl., ¶ 21.) Mr. Muglia's claim that I announced JavaBeans at the JavaOne conference "without any warning or prior discussion" is not true.
23. As a courtesy, I called Mr. Muglia the day before the JavaOne conference to discuss the JavaBeans issue with him -- a fact Mr. Muglia later admits in his declaration. (Muglia Decl., 22.) Microsoft was one of a number of major licensees whom I called shortly before the conference to discuss the issue. Most of Sun's licensees, however, did not receive such a call.
24. At the JavaOne conference, Sun announced only an intent to begin working with its licensees to develop JavaBeans. Sun invited Microsoft, along with other licensees, to participate in this process. In fact, for a period of time, Microsoft did participate. Sun never excluded Microsoft from participating.

Microsoft's Distribution Channels

25. I do agree with Mr. Muglia that I "indicated that the broad distribution that Windows would bring to Java was attractive." (Muglia Decl., ¶ 8.) But it was always understood that Microsoft's broad distribution was subject to the compatibility requirements of the TLDA. It is precisely because of Microsoft's broad distribution channels that Microsoft's compliance with the compatibility requirements of the TLDA was of such paramount importance. If Microsoft were to distribute an incompatible product, I fully appreciated that there was a very serious danger that Microsoft would fragment the JAVA^TM programming environment and establish its own de facto standard. For this reason, we were very careful to ensure that the TLDA permitted Microsoft to distribute only such products as first pass Sun's compatibility test suite.

Discussions with Paul Maritz

26. I also have read the declaration submitted by Microsoft's Paul Maritz. Mr. Maritz did not participate in most of the negotiations regarding the TLDA. I recall having one or two telephone conversations with Mr. Maritz regarding the TLDA. I believe those conversations occurred during the week before the signing of the TLDA.
27. When I first became involved in the negotiations with Microsoft approximately one month after the Letter of Intent was signed, Microsoft requested that we expand the deal contemplated in the Letter of Intent to grant Microsoft the right to implement the JAVA technology in Microsoft's operating systems, such as Windows98 and Windows NT. As the negotiations proceeded, Microsoft and Sun experienced difficulties in negotiating the broader operating system-oriented license which Microsoft sought. One of the difficult issues presented by the broader license Microsoft sought related to the expanded set of interfaces to the JAVA runtime interpreter that would become possible if the JAVA runtime environment were implemented as part of the Microsoft operating systems. For a short period of time during the negotiations of the TLDA, the parties discussed narrowing the negotiations back to a browser-oriented deal envisioned in the Letter of Intent. I remember discussing these two alternatives with Mr. Maritz on the telephone. Mr. Maritz and I decided to pursue the broader operating system-oriented license, which is the scope of license ultimately agreed upon in the TLDA. I also recall discussing pricing and the use of the JAVA^TM technology on non-PC-based products with Mr. Maritz as part of these one or two telephone conversations.
28. I do not recall ever discussing specific terms or language of the TLDA with Mr. Maritz. I do not recall discussing native code interfaces with Mr. Maritz, nor do I recall ever agreeing that the "final decision on interfaces was up to Microsoft." (Maritz Decl. ¶ 8.) Indeed, such an agreement would have been contrary to the positions that Sun consistently took during the negotiations as well as the text of the final TLDA.
29. I also do not recall discussing with Mr. Maritz whether Microsoft would be permitted to continue to ship products in the event of termination. I do recall having such discussions with Mr. Muglia. Sun told Microsoft that Sun needed to be able to promptly stop the shipment of any incompatible products, and ultimately to terminate the Agreement if Microsoft continued on an ongoing basis to intentionally ship incompatible product. Microsoft told Sun that Microsoft needed certainty that its distribution of previously released versions of compatible products would not be interrupted, even by termination of the Agreement.
30. These discussions were reflected in the final version of the TLDA. Under the TLDA, if Microsoft willfully and intentionally breaches a material provision of section 2.6 and fails to cure within one year after receiving notice from Sun, Sun has the right to terminate the TLDA. (Exh. A [TLDA at § 11.2(b)].) After termination, Microsoft has certain rights with respect to Surviving Products, but those rights are "subject to its [Microsoft's] continued compliance with the Test Suites current at the time of expiration or termination." (Id. at § 11.3.)
31. Section 11.2(b) of the TLDA does not authorize Microsoft to distribute Products which fail Sun's compatibility test suites. The parties never discussed granting Microsoft the unfettered right to distribute incompatible Products for one year. If we had, Sun certainly would not have agreed to give Microsoft that right.

Microsoft's Role as Distributor of JAVA^TM Technology

32. Both Mr. Maritz and Muglia's declarations give the false impression that Sun agreed Microsoft would compete with Sun with respect to the JAVA^TM technology. The TLDA is entitled, "Technology License and Distribution Agreement." We believed Microsoft had agreed to act as Sun's value-added distributor, not a direct competitor, regarding the JAVA^TM technology.
33. The text of the TLDA reflects this relationship. Microsoft's license is limited to "Products." A Product "that includes the Technology or a Derivative Work or Independent Work thereof must include significant functional and value enhancement in addition to the Technology such that the primary reason for a customer to license such Product is other than the right to receive a license to the Technology." (Exh. A [TLDA at § 1.20]; emphasis added.)
34. Sun insisted on this provision during the negotiations. Sun did not license Microsoft to compete with Sun's JDK product, e.g., by simply re-distributing Microsoft's implementation of the Technology. The definition of "Product" specifically provided that "Products shall not include the Technology distributed on a stand-alone basis . . . ." (Id. emphasis added)
35. Regardless of whether Microsoft implemented the Technology or created a Derivative Work or Independent Work based on the Technology, Microsoft could not simply distribute, on a stand-alone basis, an implementation of the compiler, class libraries and/or virtual machine under the Microsoft label. The Technology distributed by Sun already addressed the marketplace need for a basic development kit for programmers interested in developing applications using the JAVA^TM programming language.
36. Instead, the TLDA requires that Microsoft's tool products add "functional and value enhancements" to the Technology and distribute the JAVA^TM technology as part of a full-featured, integrated programming development environment. Microsoft's Products could not serve the same purpose as Sun's JDK product. Microsoft's Products must offer additional functionality and value to customers, so that the "primary reason" for a customer to license the Microsoft Product is to obtain this added functionality, not simply the functionality already provided by the Technology.
37. At the same time, the parties also agreed that Microsoft's Product would contain this "significant functional and value enhancement in addition to the Technology," not in place of or as a substitute to the Technology. The fundamental principle reflected in the TLDA is that Microsoft's Products must incorporate Sun's Technology and pass Sun's test suites, while at the same time adding significant functional and value enhancements in addition to the Technology.
38. By December 1996, Sun had become aware that Microsoft was distributing a Software Development Kit for JAVA^TM ("SDKJ"). We believed that, unlike Microsoft's Visual J++ product, which was a development tool for the JAVA^TM programming environment, SDKJ did not satisfy the requirements of a "Product" under the TLDA. SDKJ was simply Microsoft's version of Sun's JDK, containing the Technology on a stand-alone basis without "significant functional and value enhancements." Accordingly, on December 5, 1996, I wrote a letter to Mr. Muglia notifying Microsoft of its failure to comply with the terms of the TLDA and requesting that Microsoft cease distributing SDKJ. A true and correct copy of that letter is attached hereto as Exhibit B. In the months that followed, the parties continued to discuss this issue. To this day, however, Microsoft continues to distribute its SDKJ product, even though it does not satisfy the TLDA's requirements for a Product.

PeopleSoft

39. I received a letter dated October 23, 1997 from Ken Morris, Chief Technical Officer for PeopleSoft, Inc., which was jointly addressed to myself and Steve Ballmer, Executive Vice President of Sales and Support for Microsoft. Sun did not ask anyone at PeopleSoft to write such a letter. The letter expressed concern that the "splintering of Java would destroy one of the most powerful benefits of the technology -- that is based on a universally agreed upon standard." Mr. Morris further explained, "Competing Java definitions would force every application developer, including PeopleSoft . . . to divert valuable development resources towards porting efforts at the expense of product innovation . . . ." A true and correct copy of that letter is attached hereto as Exhibit C.

I declare under penalty of perjury under the laws of the United States that the foregoing is true and correct. Signed this 20th day of August, 1998.

Alan E. Baratz

*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.