Reply_Declaration_of-Lee-Patch_in_Support_of_Sun_Microsystems_Motions_for_Preliminary_Injunction_9_10_1998. 

31. Reply Declaration of Lee Patch in Support of Sun Microsystems's Motions
for Preliminary Injunction
Legal document in support of Sun's motion to be argued on September 10th,
1998.

 Link to SUN MICROSYSTEMS, INC. Site
31. Reply Declaration of Lee Patch in Support of Sun Microsystems's Motions
for Preliminary Injunction
Legal document in support of Sun's motion to be argued on September 10th,
1998. http://java.sun.com/lawsuit/82198patch.html

I, Lee Patch, declare:

1. &#I am Vice President and Associate General Counsel of Sun Microsystems, Inc.
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.

Background

3. &#From late 1995 to March 1996, I was closely involved in the negotiations between Sun Microsystems, Inc. ("Sun") and Microsoft Corporation ("Microsoft") regarding Sun's JAVA^TM technology. I attended meetings between representatives of Microsoft and Sun as well as prepared and revised draft agreements.
4. &#As a member of Sun's negotiating team, I am very familiar with the terms of the Technology License and Distribution Agreement between Sun and Microsoft dated March 11, 1996 ("TLDA"). A true and correct copy of the TLDA is attached hereto as Exhibit A.
5. &#I am also familiar with the communications between the parties during the negotiations leading up to the TLDA. A true and correct copy of the Letter of Intent between Sun and Microsoft dated December 6, 1996 ("Letter of Intent") is attached hereto as Exhibit B. True and correct copies of a November 1995 draft of the TLDA prepared by Sun ("11/95 Draft"), a February 21, 1996 draft of the TLDA prepared by Microsoft ("2/21/96 Draft "), a February 28, 1996 draft of the TLDA prepared by Sun ("2/28/96 Draft"), a March 5, 1996 draft of the TLDA prepared by Microsoft ("3/5/96 Draft") and a March 10, 1996 draft of the TLDA prepared by Microsoft ("3/10/96 Draft") are attached hereto as Exhibits C-G, respectively.

Sun and Microsoft's Discussions Regarding Licensing Model

6. &#Prior to the execution of the Letter of Intent, I attended a meeting between representatives of Sun and Microsoft to discuss licensing the JAVA^TM technology. Roger Heinen and Denis Gilbert from Microsoft were present. At that meeting, Sun's then-Vice-President and Chief Technical Officer, Eric Schmidt, explained how Sun's licensing model for the JAVA^TM technology was designed to ensure compatibility
7. &#During the meeting, Mr. Schmidt drew a box on the whiteboard, and explained that under Sun's licensing model our licensees were obligated to incorporate and support fully all of the technology we delivered which was conceptually portrayed as being within that "box." He also explained that the JAVA^TM technology within the "box" was not static, that it was admittedly immature, and that it would be evolving under Sun's control over the next several years. Mr. Schmidt told the Microsoft representatives that Sun intended to make a series of shipments of code which would conceptually be in the "box," and that Sun's licensees would be obligated to support on an ongoing basis, everything that was delivered by Sun within that "box."
8. Since the initial discussions appeared promising, Sun and Microsoft executed a non-binding Letter of Intent, and agreed to try to negotiate a license agreement.
9. &#During the discussions that led to the Letter of Intent, the parties discussed Microsoft's intention to incorporate the JAVA^TM technology in browser and development tool products only. After the Letter of Intent was signed, however, Microsoft proposed a fundamental change to the nature and scope of the proposed license agreement. Microsoft requested that the scope of the proposed agreement be expanded to allow Microsoft to incorporate the JAVA^TM technology into its operating system products.
10. Since Sun's previous licenses had been principally to browser, development environment vendors and application developers, this proposal marked a significant change in how the JAVA^TM technology would be made available to the public. We explained to Microsoft that we were concerned that such a deal might impact other licensees and prospective licensees. If the JAVA^TM technology were present in every operating system shipped by Microsoft, some portion of Sun's present or future licensees would no longer need to incorporate the JAVA^TM technology into their products. Sun also raised concerns with Microsoft about how customers would be able to access or interface with the JAVA^TM technology, if it were incorporated into Microsoft's operating system. Microsoft's proposal to broaden the scope of the license agreement from a browser-oriented deal to an operating-system-oriented deal raised new issues and concerns that the parties attempted to address during the negotiations leading up to the execution of the final TLDA.

Definition of AAPI

11. &#The TLDA defines "AAPI" as

(a) the public application programming interface to the Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A, (b) the bytecode specification in the Documentation entitled "OEM Java Virtual Machine Specification," (c) the Java language specification in the Documentation entitled "OEM Java Language Specification" and (d) the OEM Java API Specification, as modified by SUN during the term of this Agreement.

(Exh. A [TLDA, § 1.1].)

12. &#Exhibit A of the TLDA defines that the "Java Applet Environment" consists of the source code of two components: (1) certain Java Classes listed in Exhibit A and (2) the "Java Runtime Interpreter, which implements the Java Virtual Machine." (Exh. A [TLDA, Exh. A].)
13. &#Since section 1.25 of the TLDA defines "Technology" to include "Upgrades" and the term "AAPI" includes "the public application programming interface . . . as modified by SUN during the term of this Agreement," the definition of "AAPI" encompasses modifications Sun may make through Upgrades.
14. &#Sun has repeatedly explained to Microsoft that Sun's Java Native Interface ("JNI") is a "public application programming interface to the Java Applet Environment," specifically, "a public application programming interface" to the Java Runtime Interpreter. JNI was included within Sun's JDK 1.1 Upgrade. Consequently, JNI falls within the TLDA's definition of "AAPI."
15. &#I understand that Microsoft now contends that the term "AAPI" must be interpreted to exclude JNI because (1) JNI is not one of the "Java packages listed in section I(A) of Exhibit A of the TLDA" or (2) JNI was part of an Upgrade and thus is somehow excluded from the definition of AAPI. (Microsoft's Opp. To Sun's Motion for Prelim. Injunc. Under 17 U.S.C. § 502 ("Opp.") at 7-9.)
16. &#I strongly disagree. Not only does a plain reading of the definition of "AAPI" in the TLDA unambiguously encompass JNI, the communications between Microsoft and Sun during the negotiation of the TLDA demonstrate that the parties did not agree that the definition of AAPI should be limited as Microsoft now contends.
17. &#During the negotiations, Sun initially proposed defining "AAPI" as "the public application programming interface to the Technology, including all public libraries and interfaces." (Exh. C [11/95 Draft at § 1.1]; emphasis added.)
18. &#Microsoft responded by proposing to define "AAPI" as "the application programming interface to the Technology, including the interface to the Applet Classes (as defined below)" and "Applet Classes" as "the Java classes listed in Exhibit A." (Exh. D [2/21/96 Draft at §§ 1.1 and 1.3].) Sun specifically rejected that definition, explaining that we were concerned Microsoft's proposed definition might be interpreted too narrowly, since it left out a specific reference to the Java Runtime Environment or Java Virtual Machine. Sun wanted to make clear that the definition of "AAPI" was not limited to just the Java classes listed in Exhibit A of the TLDA.
19. &#In its February 28, 1996 draft, Sun proposed a definition of AAPI, which originally included an explicit reference to the Java Runtime Interpreter, not just the "Java classes" or "Applet Classes" listed in Exhibit A, and then was broadened to the defined term "Java Applet Environment, which was defined to include the Java Runtime Interpreter. Although Microsoft again proposed its own definition of AAPI which referenced only "the interface to the Applet Classes" in its March 5 and 10, 1996 drafts, Sun repeatedly rejected Microsoft's definition as too narrow. With the exception of the addition of the terms "OEM" and "Documentation," Sun's proposed definition for "AAPI" from its February 28 draft, not Microsoft's definition, became the final definition in the TLDA.

/ / /

20. &#The following diagram depicts the progression of the definition of the term "AAPI" through the various drafts:

Sun's November 1995 Draft TLDA

"the public application programming interface to the Technology, including all public class libraries and interfaces"

¯

Microsoft's February 21, 1996 Draft TLDA

"the application programming interface to the Technology, including the interface to the Applet Classes (as defined below)"

¯

Sun's February 28, 1996 Draft TLDA

"(a) the public application programming interface to the Java Runtime Interpreter, including all public class libraries and interfaces Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A, (b) the bytecode specification in the Java Virtual Machine Specification, (c) the language specification in the Java Language Specification, and (d) the "Java API Specification", as modified by Sun during the term of this Agreement"

¯

Microsoft's March 10, 1996 Draft TLDA

"the public application programming interface to the Technology, including the interface to the Applet Classes (as defined below)"

Final TLDA

"(a) the public application programming interface to the Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A, (b) the bytecode specification in the Documentation entitled "OEM Java Virtual Machine Specification," (c) the Java language specification in the Documentation entitled "OEM Java Language Specification" and (d) the OEM Java API Specification, as modified by SUN during the term of this Agreement"

21. &#Based on these drafts as well as Sun's communications with Microsoft, it is clear that the parties did not agree to limit the definition of "AAPI" to just interfaces to "the Java classes listed in Exhibit A." If the parties intended the definition of AAPI to be limited in that way, the parties could have adopted Microsoft's proposed definition, not the broader definition proposed by Sun which was incorporated into the final TLDA.
22. &#As for Microsoft's claim that the definition of § 1.1(a) of the definition of "AAPI" in the TLDA excludes any Upgrades from its scope, the plain text of the TLDA and the negotiation history again refutes Microsoft's claim.
23. &#The definition of "Technology" in the TLDA expressly includes "all Upgrades." (Exh. A [TLDA at § 1.25].) Moreover, the definition of "AAPI" provides that "AAPI" includes everything listed in subsections (a)-(d) of § 1.1 "as modified by SUN during the term of this Agreement." (Id. at § 1.1; emphasis added.) Thus, "AAPI" expressly includes "the public application programming interface to the Java Applet Environment (JAE) reflected in the Technology as identified in Exhibit A . . . as modified by SUN during the term of this Agreement." (Id.; emphasis added.) Additionally, "Java Test Suite" is defined as test suites for validating compliance "with the SUN specification of the AAPI as of the date of the test suites." (Id. at § 1.15; emphasis added.)
24. &#This text is consistent with Sun's communications with Microsoft. As Eric Schmidt explained in the initial meeting with Microsoft, Sun's licensees had an obligation to support everything "within the box" which Sun shipped. And the technology that was conceptually "within the box" was not static because the JAVA^TM technology was still new and evolving.
25. &#Similarly, I heard Alan Baratz, the President of Sun's JavaSoft unit tell Microsoft during the negotiations of the TLDA that Sun's licensing model required Sun to have the ability to deliver to Microsoft sequential versions of the JAVA^TM technology over the term of the TLDA, and that Microsoft would be required to pass all of the test suites Sun delivered with these sequential shipments of the JAVA^TM technology.
26. &#Sun's ability to improve and evolve the JAVA^TM technology while maintaining compatibility and to require Microsoft to support that improvement and evolution in a compatible manner was critical to Sun's agreement to enter into the TLDA. Given the positions that Sun took during its negotiations with Microsoft, I do not believe Sun would have agreed to enter into the TLDA without those express rights and guarantees.

Microsoft's Obligation to Implement JNI

27. &#Section 2.9(b) of the TLDA provides 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." (Exh. A [TLDA at § 2.9(b). Because JNI is a public application programming interface to the Java Runtime Interpreter, section 2.9(b) obligates Microsoft to include the source code for JNI in its JAVA^TM virtual machine* implementation in order to "implement the functionality of the Java Runtime Interpreter."

Sun's Right To Test for Interfaces to the Java Runtime Interpreter Like JNI

28. &#Under the TLDA, Microsoft may not commercially distribute a Product unless it "passes the test suite that accompanied the Significant Upgrade (a "Relevant Test Suite")." (Exh. A [TLDA at § 2.6(a)(iv)].) The "Java Test Suite" is defined as "SUN's publicly available test suites for validating that products which interpret bytecodes comply with SUN's specification of the AAPI as of the date of the test suites." (Id. at § 1.15) As part of Sun's JDK 1.1 Upgrade, JNI was part of Sun's specification of the AAPI as of the date of the test suites, and Sun therefore was entitled to test whether products which interpret bytecodes comply with Sun's JNI specification.
29. &#I understand that Microsoft now claims that "SUN's specification of the AAPI" is somehow limited to "the three Documentation excerpts listed in TLDA sections 1(b), (c) and (d)." (Opp. At 15.) Microsoft's construction contradicts the text of the TLDA and is inconsistent with the communications between the parties during the negotiations. "Java Test Suite" is defined as validating compliance with "SUN's specification of the AAPI as of the date of the test suites." It does not state that it is limited to validating compliance with only the portion of SUN's specification of the AAPI reflected in the Documentation excerpts listed in sections 1.1(b), (c) and (d). Microsoft's construction gives no effect to section 1.1(a) of the definition of "AAPI."
30. &#In all the meetings and telephone conferences in which I participated, no Sun representative ever suggested to Microsoft that section 1.1(a) of the definition of "AAPI" was somehow excluded from the AAPI specification or that the subject matter of section 1.1(a) was not appropriate for compatibility testing. To the contrary, I specifically recall Sun representatives telling Microsoft representatives on several occasions that as the JAVA^TM technology evolved under Sun's control, Sun's specification of the AAPI, and hence the test suites, would also change and evolve.
31. The subject matter of section 1.1(a) of the definition of "AAPI" was critical to defining the "AAPI" and the subject matter for the test suites. Section 1.1(a) of the definition of "AAPI" represented the technology that Eric Schmidt had conceptually described as being "in the box" which Sun shipped to its licensees. The Documentation listed in Section 1.1(b)-(d) would articulate certain rules, functional characteristics and parameters, but the Documentation necessarily would trail behind the actual technology Sun shipped to its licensees as Sun attempted to document the new technology.
32. Microsoft and its Senior Vice-President Robert Muglia apparently now contend that under the TLDA Microsoft has the "sole right to define the native interfaces to Microsoft's Java Reference Implementation" and that Sun cannot test for native interfaces like JNI. (Opp. At 11; Muglia Decl., ¶ 16.) Again, the text of the TLDA and the negotiation history provide no support for Microsoft's current position.
33. &#Nowhere in the TLDA does it state that Microsoft has "sole right to define the native interfaces" or that Sun cannot test for native interfaces. Based on the positions Sun took during the negotiations, I do not believe Sun would have entered into such an agreement.
34. &#Under the TLDA, Microsoft only has "sole discretion" whether "to include one or more Supplemental Java Classes in its Products," subject to an obligation to distribute Supplemental Java Classes free of charge via the Worldwide Web or CD-ROM. (Exh. A [TLDA at § 2.7(a)].) JNI, however, is neither a Java Class nor a Supplemental Java Class. JNI is a public application programming interface to the Java Runtime Interpreter. Section 2.7(a) of the TLDA is thus inapplicable.
35. &#"Native code interfaces" are only expressly discussed in the TLDA at sections 2.8(a) and 2.9(e):

The parties understand and agree that during the Term, Licensee may develop Value Added Open Packages which do not need to call native code interfaces during execution ("Portable VAOPs") and Value Added Open Packages that need to call a native code interface during execution ("Non-Portable VAOPs").

. . . .

Licensee and SUN may openly publish a complete and accurate specification for interfaces to the Reference Implementation VM, including the invocation interface, the native code interfaces required for the execution of Non-Portable VAOPs, and interfaces required for the compilation of Java-compatible bytecodes into native code (e.g., Just-in-Time Compilation) by Licensee or third parties.

(Exh. A [TLDA at §§ 2.8(a) and 2.9(e)]; emphasis added.)

36. &#Based on these sections of the TLDA, at least three conclusions regarding native code interfaces can be drawn. First, the TLDA expressly addresses certain native code interfaces, but does not state that Microsoft has "sole right to define native code interfaces" for Microsoft's products. Second, native code interfaces are "interfaces to the Reference Implementation VM." Third, both Microsoft and Sun have the right to publish specifications for interfaces to the Reference Implementation VM such as native code interfaces.
37. &#Since native code interfaces are defined in the TLDA as "interfaces to the Reference Implementation VM," section 2.9(f) is also relevant to the issue of whether Sun is entitled to test for native code interfaces. Section 2.9(f) provides:

Licensee agrees that from time-to-time during the Term, SUN may wish to suggest that Licensee modify the implementation and/or interfaces to the Reference Implementation VM in a substantive way which cannot be adequately expressed through the Test Suites. Licensee agrees to work with SUN in good faith to create such modifications; provided, however, that if the parties cannot reach a mutually satisfactory agreement on such modifications, then Licensee may decline to implement SUN's requested modification(s).

(Exh. A [TLDA at § 2.9(f)]; emphasis added.)

38. &#Sun insisted that section 2.9(f) be inserted into the TLDA. Sun explained to Microsoft that it was concerned its test suites may not be able to detect or cover all possible modifications it may wish Microsoft to make.
39. On its face, section 2.9(f) addresses situations where Sun wishes that Microsoft modify interfaces that Microsoft introduced to the Reference Implementation VM (e.g., native code interfaces), but the modifications "cannot be adequately expressed through the Test Suites." Only in cases where a modification to a native code interface "cannot be adequately expressed through the Test Suites" does Microsoft have the ability to decline to implement Sun's modification after good faith negotiations. If the modification can be adequately expressed through the Test Suites, however, Microsoft must comply and pass the Test Suites. By its terms, section 2.9(f) indicates that Sun has the right to test for interfaces to the Reference Implementation VM, such as native code interfaces.
40. &#Since JNI is adequately expressed through the Test Suites, Microsoft's special rights under section 2.9(f) are not implicated. Microsoft must comply and pass the Test Suites with respect to JNI.
41. &The negotiation history with respect to interfaces to the Reference Implementation VM supports the plain meaning of these sections. Microsoft's proposal to change the scope of the license from the browser-oriented deal envisioned in the Letter of Intent to an operating-system-oriented deal brought the issue of interfaces to the Virtual Machine to the foreground. If the JAVA^TM technology were integrated down into the operating system, defining the interfaces to the JAVA^TM Runtime Interpreter or Virtual Machine became more important.
42. Thus, in its February 21, 1996 draft, Microsoft introduced the term "MS Invocation Interface" to begin to address this issue¹. "MS Invocation Interface" was defined as "the public interface to Reference Implementation VM, which allows programs to invoke Java methods or classes, but does not allow invocation of internal methods or classes of the Reference Implementation VM." (Exh. D [2/21/96 Draft at § 1.17].) Although Microsoft's draft defined the term, the term was only used in the definition section of Microsoft's draft.
43. &#Sun then proposed a February 28, 1996 draft, which made only a minor change to the wording of Microsoft's definition of "MS Invocation Interface." (Exh. E [2/28/96 Draft at § 1.16].) Sun's draft, however, added a provision stating, "The initial specification for the MS Invocation Interface and any modifications thereto shall be subject to approval by Sun." (Id. at § 2.9; emphasis added.)
44. &#Microsoft responded in its March 5, 1996 draft. In this draft, the definition of "MS Invocation Interface" was similar to Microsoft's February 21, 1996 draft, except that "MS Invocation Interface" was now defined as a "non-public interface," rather than a "public interface." (Exh. F [3/5/96 Draft at § 1.17].) This change reflected the intent of the parties to go back to the browser-oriented deal originally contemplated. Shortly after this draft, however, Sun and Microsoft changed course again and agreed to pursue a broader operating-system-oriented deal.
45. &#As for control over the interfaces, Microsoft's March 5th draft also required Microsoft to notify Sun of any interfaces to the Reference Implementation VM before making the Product commercially available. (Id. at § 2.9.) After receiving notice, Microsoft's draft proposed that Sun would have 30 days to notify Microsoft that (a) Microsoft could ship the product with the interfaces, (b) Sun would develop its own interfaces to the Java Runtime Interpreter and include the interfaces in an Update (but Microsoft would not be precluded from also developing its own interfaces), or (c) Sun would not develop its own interfaces, but Microsoft is free to proceed. (Id.)
46. &#In its March 10, 1996 draft, on the eve of signing the TLDA, Microsoft proposed defining "Invocation Interface" as follows:

[T]he public interface to the Reference Implementation VM, which is described in Exhibit B attached hereto, including any Derivative Works or Independent Works thereof which meet the compatibility requirements set forth in Section 2.6 of this Agreement.

(Exh. G [3/10/96 Draft at § 1.9].) Thus, Microsoft's proposal provided that Sun had the right to define the initial description of this interface to the VM with Microsoft and that any changes which Microsoft made to this interface to the VM were subject to the compatibility requirements of Section 2.6 (i.e., passing the test suites). Microsoft also proposed that it be allowed to modify or alter the Invocation Interface "provided that [Microsoft] does not modify or alter the functional behavior of such Invocation Interface without the written consent of SUN." (Id. at § 2.10(a).)

47. &#In the final TLDA, the term "Invocation Interface" is not defined. Instead, "invocation interface," like native code interface, is listed as one of the "interfaces to the Reference Implementation VM" in section 2.9(e) of the TLDA. Section 2.9(f) of the TLDA, however, makes clear that interfaces to the VM, like native code interfaces, are subject to compatibility testing through the test suites, since section 2.9(f) addresses cases where Sun's modifications "cannot be adequately expressed through the Test Suites."
48. &#The following diagram depicts the progression of the draft provisions relating to "Invocation Interface":

/ / /

Microsoft's February 21, 1996 Draft

"'MS Invocation Interface' means the public interface to Reference Implementation VM, which allows programs to invoke Java methods or classes, but does not allow invocation of internal methods or classes of the Reference Implementation VM." (§ 1.17)

¯

Sun's February 28, 1996 Draft

"'MS Invocation Interface' means the public interface to the Reference Implementation VM, which allows application programs to invoke Java methods or Classes, but does not allow invocation of internal methods or classes of the Reference Implementation VM." (§ 1.16) . . . . "Approval of MS Invocation Interface. The initial specification for the MS Invocation Interface and any modifications thereto shall be subject to approval by Sun." (§ 2.9)

¯

Microsoft's March 5, 1996 Draft

"'MS Invocation Interface' means the non-public interface to Reference Implementation VM, which allows programs to invoke Java methods or classes, but does not allow invocation of internal methods or classes of the Reference Implementation VM." (§ 1.17) . . . . "MS Invocation Interface and Other Interfaces. . . . Prior to making commercially available any Product that includes the Reference Implementation VM, Licensee shall notify SUN of the nature and purpose of any interfaces thereof. Within 30 days after receiving such notice, SUN shall notify Licensee that (a) the Licensee may proceed with shipping the Product that includes the Licensee-authored interfaces to the Reference Implementation VM, (b) Sun will develop its own interfaces to the Java Runtime Interpreter and include such new interfaces in an Update (but the fact that SUN develops its own interfaces shall not preclude Licensee from developing its own interfaces), or (c) SUN will not develop its own interfaces to the Java Runtime Interpreter and include it in a future Update, but Licensee is free to proceed." (§ 2.9)

¯

Microsoft's March 10, 1996 Draft

"'Invocation Interface' means the public interface to the Reference Implementation VM, which is described in Exhibit B attached hereto, including any Derivative Works or Independent Works thereof which meet the compatibility requirements set forth in Section 2.6 of this Agreement." (§ 1.9) . . . . "Licensee may modify, alter, adapt, or create Derivative Works or Independent Works of the Invocation Interface to the Reference Implementation VM, provided that Licensee does not modify or alter the functional behavior of such Invocation Interface without the written consent of SUN." (§ 2.10(a))

¯

Final TLDA

"Licensee and SUN may openly publish a complete and accurate specification for interfaces to the Reference Implementation VM, including the invocation interface, the native code interfaces ...." (§ 2.9(e)) . . . . "Licensee agrees that from time-to-time during the Term, SUN may wish to suggest that Licensee modify the implementation and/or interfaces to the Reference Implementation VM in a substantive way which cannot be adequately expressed through the Test Suites. Licensee agrees to work with SUN in good faith . . . ; provided, however, that if the parties cannot reach a mutually satisfactory agreement on such modifications, then Licensee may decline to implement SUN's requested modification(s)." (§ 2.9(f))

49. &#As the drafts make clear, the parties contemplated that Sun would retain the right to control the definition of interfaces to the Reference Implementation VM. The only issue was how and when that control would be exercised. Initially, Sun and, even Microsoft, contemplated that Sun would exercise its control by reviewing the proposed Microsoft interfaces before they were implemented in Microsoft's products. Eventually, however, the parties agreed that Microsoft could create its own interfaces to the Reference Implementation VM, subject to passing the Test Suites. If the Test Suites were not sufficient for Sun's purposes, Sun could request, but ultimately not require, Microsoft to make further changes.
50. Thus, Microsoft was free to develop, implement and publish its own native code interface – e.g., Raw Native Interface ("RNI"), subject to the requirement of passing the Test Suites. Sun, however, always retained the right to develop, implement and publish standard interfaces to the Java Runtime Interpreter like JNI. Since tests for compliance with JNI were successfully incorporated into the Java Test Suite, Microsoft's Products must pass the tests for JNI. Microsoft may maintain support for its own interface -- RNI, as long as it passes the Test Suites. Microsoft, however, is also required to support Sun's interface -- JNI -- because it is part of the AAPI, and tests for compliance were incorporated into the Java Test Suites. If compliance with JNI were "not adequately expressed through the Test Suites," Microsoft would have had an obligation to work in good faith with Sun, but could have ultimately declined to implement JNI. (Exh A [TLDA at § 2.9(f)].) Since section 2.9(f) is not applicable in the present case, Microsoft must pass the JNI tests in Sun's Test Suites.
51. &#In his declaration, Mr. Muglia states that he "clearly remember[s] 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." (Muglia Decl., ¶ 10.) I was present during the final negotiation session in Cupertino before the signing of the TLDA. I never heard Mr. Baratz indicate or even suggest that "Microsoft alone would define the interfaces to its VM." If Mr. Baratz had made such a statement, I am sure I would have remembered it because it would have directly contradicted the positions Sun repeatedly took during the negotiations with Microsoft. It also would have contradicted the position Microsoft had taken in its own drafts of the TLDA which provided for Sun's control over interfaces to the VM. (See Exh. G [TLDA at §§ 1.9 and 2.10(a)].)
52. &#A few hours before the signing the final agreement, I do recall Mr. Baratz telling Mr. Muglia that we had spoken to Sun's Bill Joy about the draft TLDA. Mr. Baratz told Mr. Muglia that Bill Joy had advocated that Sun go back to its earlier proposal and require Sun's prior approval before Microsoft introduced any new interfaces to the VM. Mr. Baratz told Mr. Muglia that he believed we have been through that issue and were prepared to go forward with the current deal. Mr. Baratz told Mr. Muglia that Sun believed the agreement met Sun's needs because although Microsoft could introduce new interfaces, those interfaces were subject to Sun's ability to test for compliance with the Test Suites. If those Test Suites were inadequate, Mr. Baratz told Mr. Muglia that the provisions of section 2.9(f) allowed Sun to engage Microsoft to engage in good faith discussions to try and address in any other concerns Sun might have.
53. &#Not only does Mr. Muglia's "memory" contradict my recollection of the discussions on the eve of signing, his "memory" contradicts Microsoft's own March 10, 1996 draft of the TLDA. In that draft, Microsoft specified that Microsoft's interfaces to the Reference Implementation VM such as the Invocation Interface would be subject to (1) Sun's initial approval of the definition of the interface; (2) the compatibility requirements of the TLDA and (2) Sun's written consent, if the functional behavior were altered. (Exh. G [3/10/96 Draft at §§ 1.9 and 2.10(a).] Given these negotiations, I find it impossible to imagine that Mr. Baratz would propose that Sun have less control over interfaces to the VM than Microsoft's own drafts proposed.

The "Mode" for Compiler Compatibility Only Allowed Microsoft to Distribute a Compiler That Supported Prior Compatible Versions of the JAVA^TM Technology

54. &#Section 2.6(b)(iv) states in relevant part:

. . . Licensee agrees that any new version of a Product that includes the Java Language compilation function that Licensee makes commercially available to the public after the most recent Compatibility Date shall 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.

55. Microsoft now contends this clause gives it the right to create compilers containing new compiler directives and keywords "so long as the compilers in its products 'include a mode' in which the products pass the Java Language Test Suite." (Opp. at 11-12.) Mr. Muglia also has submitted a declaration in which he states:

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.

(Muglia Decl., ¶ 11.)

56. &#Microsoft's "interpretation" and Mr. Muglia's "recollection" is contrary to both the plain meaning of the text and Microsoft's representations during the negotiation of the TLDA.
57. &#The text of section 2.6(b)(iv) says nothing about "extending the Java language" because Sun never agreed that Microsoft had a license to alter the JAVA^TM language.
58. &#In earlier drafts of the TLDA, the recitals stated that "SUN wishes to license its JAVA^TM programming language and related technology." (Exh. C-F, "Recitals".) In the final TLDA, however, the recital states only that "SUN wishes to licenses its JAVA technology." (Exh. A, "Recitals".)
59. &#Sections 2.1 and 2.2 of the TLDA refer to Sun granting a particular license under the Intellectual Property Rights of Sun with respect to the "Technology." The definition of Technology, however, is limited to "the Java Runtime Interpreter, Java Classes, Supplemental Java Classes, Java Compiler and all Upgrades," and does not include the JAVA^TM language. (Exh. A, [TLDA at § 1.25].)
60. &#The OEM Java Language Specification is defined as part of the "Documentation." (Exh. A [TLDA at § 1.4].) Section 2.3 of the TLDA grants Microsoft a limited license with respect to Documentation. That license, however, is limited to "[m]ake, use, modify, adapt, translate and create technically accurate Derivative Works of the Documentation." (Exh. A [TLDA at § 2.3(a)]; emphasis added.) Thus, Microsoft’s right to use or modify Documentation reflecting the OEM Java Language Specification is expressly limited to "technically accurate Derivative Works of the Documentation." This provision is therefore inconsistent with Microsoft's claim that it is entitled to add new keywords and compiler directives. If Microsoft were to distribute Documentation based on Sun's OEM Java Language Specification, but added new keywords and compiler directives, such Derivative Work of the Documentation would be outside the scope of Microsoft's license because the Derivative Work would not be "technically accurate."
61. &Allowing a licensee like Microsoft to unilaterally develop its own "polluted" version of the JAVA^TM language is also antithetical to Sun's stated purpose of "maintaining compatibility among JAVA language based products" as recited on the face of the TLDA. (Exh. A [TLDA, "Recitals"].) Under Microsoft's proposed "interpretation," Microsoft would have a blank check to create a completely new, competing variant of the JAVA^TM language. This interpretation is unreasonable given Sun's licensing policy and the communications between Sun and Microsoft. Again, the actual text of the final TLDA and its drafts reveal that Microsoft's "interpretation" and Mr. Muglia's "recollection" are neither credible nor reasonable.
62. &#Microsoft first introduced language regarding a "mode" for passing the compatibility tests in its February 21, 1996 draft. (Exh. D [2/21/96 Draft at §§ 2.5(a)(ii) and (b)(ii)].) Microsoft's draft proposed adding "mode" language in two places: (1) the Java Test Suite requirement for Products which interpret Java bytecodes and (2) the Java Language Test Suite requirement for Products which compile the Java Language.
63. &#Sun expressed great concern to Microsoft regarding the insertion of the "mode" language. Sun insisted that the "mode" language be removed. Microsoft's language suggested that Microsoft would be able to ship products that included both an old version of the JAVA^TM technology and a new version. We explained to Microsoft that, in order to achieve compatibility on an ongoing basis, our licensees must "uplevel" their products to the latest version. The JAVA^TM technology would have difficulty improving and evolving, if licensees continued to distribute Products containing old technology. Thus, on February 28, 1996, Sun proposed a draft which did not contain any "mode" language. (Exh. E [2/28/96 Draft at §§ 2.5(a) and (b)].)
64. &#During discussions between the parties regarding the "mode" language, Sun continued to insist that any "mode" language with respect to Products that interpret Java bytecodes be removed. Sun explained that it was necessary for runtime products -- Java Applet Environment-based products -- to have only the latest version of our technology in a fully compatible form.
65. &#Microsoft agreed. In its March 5, 1996 draft, Microsoft removed the mode language with respect to Products that interpret Java bytecodes. (Exh. F [3/5/96 Draft at § 2.6(a)(ii)] ("Licensee agrees that the portion of each Product that interprets Java bytecodes shall have a mode that permits it to pass the Java Test Suite . . . .").) Similarly, the final TLDA contains no "mode" language with respect to such Products. (Exh. A [TLDA at § 2.6(a)(iv)] ("Licensee shall deliver to SUN . . . (a 'Compatible Implementation') that passes the test suite . . . ."); [TLDA at § 2.6(a)(vi)] ("[A]ny new version of a Product that Licensee makes commercially available to the public after the most recent Compatibility Date shall only include the corresponding Compatible Implementation . . . ."); emphasis added.)
66. &#Microsoft, however, proposed that the "mode" language with respect to compiler-based Products was reasonable. Microsoft contended that developer tool products containing compilers traditionally included support for not just the latest release of a particular technology, but also prior, installed releases of the technology. Microsoft explained it was important for developers to be able to support earlier versions of the technology. A developer needed to be able to compile code he had written to run in operating systems or browsers incorporating the latest version of the JAVA^TM runtime environment as well as operating systems or browsers incorporating an earlier version of the JAVA^TM runtime environment. Since Microsoft intended to incorporate the JAVA^TM runtime environment into its operating system, it was obvious that large numbers of customers might continue for a time to have only an earlier version of the JAVA^TM runtime environment on their computer. Microsoft presented the "mode" language as a means of addressing that issue.
67. &#After receiving assurances from Microsoft on at least two separate occasions that the purpose of the "mode" language in this provision was to allow Microsoft to upgrade a previously compatible tool product so it could support the latest version of the JAVA^TM technology as well as an earlier, previously-compatible version of the JAVA^TM technology, Sun agreed to the language reflected in section 2.6(b)(iv) of the TLDA.
68. &#Microsoft never told Sun that purpose of this "mode" language was to allow Microsoft the authority to alter, pollute, or "extend" the JAVA^TM language.

Microsoft's "Right" to Distribute "Competitive Compilers"

69. &#Microsoft's declarations and oppositions claim Microsoft has a "right to create competitive compilers" and describe Microsoft and Sun as competitors. (Opp. at 11.) While Sun and Microsoft certainly compete in certain fields, the TLDA provides that Microsoft will be a value-added distributor of Sun's JAVA^TM technology, not a direct competitor.
70. &#The TLDA is a distribution agreement. Under the TLDA, 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.) Additionally, the TLDA provides, "Products shall not include the Technology distributed on a stand-alone basis, unless distributed as an upgrade to a Product." (Id.)
71. &In other words, Microsoft must add significant value to Sun's Technology in the Products it distributes. Microsoft cannot simply distribute, on a stand-alone basis, an implementation of the compiler, class libraries and/or virtual machine under the Microsoft label. The TLDA reserves the right to distribute those stand-alone products to Sun. Thus, Microsoft is not authorized to compete directly against Sun's JDK product, which contains a Compiler, Java Runtime Interpreter and Java Classes. The Technology as distributed by Sun in its JDK already addressed the marketplace need for a basic development kit for programmers.
72. Microsoft's Product must contain "significant functional and value enhancement in addition to the Technology." Microsoft only has the right to distribute the Technology if it is incorporated in a Product which adds significant enhancements like a browser, operating system, or a full-featured, integrated programming development environment. Microsoft's "significant functional and value enhancements" also must be "in addition to the Technology," not modifications or replacements to the Technology.
73. &#This value-added requirement in the definition of "Products" was originally proposed by Sun in its November 1995 draft: "'Product' must represent a significant functional and value enhancement 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. C [11/95 Draft at § 1.10].) In its February 21, 1996 draft, Microsoft proposed a definition of "Products" which excluded this requirement. (Exh. D [2/21/96 Draft at § 1.18].) Sun insisted that the requirement be re-inserted as reflected in its February 28, 1996 draft. (Exh. E [2/28/96 Draft at § 1.17].) Microsoft agreed, and incorporated the requirement in its subsequent drafts as well as the Final TLDA. (Exh. F [3/5/96 Draft at § 1.18]; Exh. G [3/10/96 Draft at § 1.22].)

Sun's Alleged "Waiver"

74. Microsoft alleges that Sun has waived its claim that Microsoft has breached the TLDA because Sun accepted Microsoft's required payment of license fees. (Opp. at 21.) In both this lawsuit and its correspondence with Microsoft, however, Sun has consistently maintained that Microsoft has been and continues to be in breach of the TLDA. Furthermore, the TLDA specifically provides: "This Agreement may not be modified, amended, rescinded, canceled or waived, in whole or in part, except by a written instrument signed by the parties." (Exh. A [TLDA at § 12.3]; emphasis added.)
75. Acceptance of Microsoft's licensee fees is also appropriate because the TLDA has not yet been terminated and Microsoft continues to ship products incorporating Sun's JAVA^TM technology, albeit in an incompatible form.

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

Lee Patch

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