|
Tech Law Journal |
 |
| News, records, and analysis of legislation, litigation, and regulation affecting the computer, internet, communications and information technology sectors | |
|
|
|
| |||||
|
[List of Plaintiff's attorney's omitted] UNITED STATES DISTRICT COURT
II. THE RELEVANT TLDA PROVISIONS CAN BE INTERPRETED ONLY ONE WAY. TABLE OF AUTHORITIES
On March 12, 1999, Sun Microsystems, Inc., will move the Court, pursuant to Rule 56(d) of the Federal Rules of Civil Procedure, to enter an order granting summary adjudication that the "most current" version of Microsoft's Java Reference Implementation, as referenced in the last sentence of section 2.7(a) of the Technology License and Distribution Agreement Exhibit 1 ("TLDA"), refers to Microsoft's Compatible Implementation of the Significant Upgrade in which the Supplemental Java Classes were delivered. Microsoft seizes on the last sentence of TLDA section 2.7(a) and argues that it should be interpreted in isolation to turn the upgrade and compatibility requirements of the TLDA on their head. According to Microsoft, the assurance provided by Sun in the last sentence of section 2.7(a) that "[t]he Supplemental Classes delivered by Sun to Licensee shall run on the most current Java Reference Implementation" should be interpreted to countermand the upgrade and compatibility requirements of section 2.6, and to impose upon Sun an obligation to deliver Supplemental Java Classes engineered to run on a prior, out-of-date version of Microsoft's Java Reference Implementation, not the "most current" implementation. Microsoft's tortured construction conflicts with the manifest purpose of section 2.7(a) as a whole, as well as the express provisions of section 2.6 and the remaining definitions and provisions of the TLDA that specify the parties' respective rights and obligations regarding the delivery of upgrades and compatibility testing. It also is nonsensical, since it would require the Court to conclude that the parties intended for Sun to warrant that its most current Supplemental Classes would run on a prior implementation that necessarily lacked the new functionality upon which the Supplemental Java Classes depend. The definitions of "Technology," "Supplemental Java Classes," "Upgrades," "Java Test Suite," and "AAPI" are each carefully worded to make clear that it is Sun - not Microsoft - that controls and defines the Technology, that it is Sun - not Microsoft - that has the right to modify or enhance the specifications for the Technology, and that it is Sun - not Microsoft - that determines whether Microsoft will be required to support such modified or enhanced Technology in the products Microsoft distributes. Thus, insofar as Sun delivers an Upgrade and corresponding Java Test Suite to Microsoft, and designates that Upgrade a "Significant Upgrade," Microsoft is required under TLDA section 2.6(a)(iv) to incorporate the Significant Upgrade, within six (6) months after its delivery to Microsoft by Sun, into a Compatible Implementation that passes the Relevant Test Suite that accompanied the Significant Upgrade. If the Significant Upgrade includes modifications or enhancements to the Java Runtime Interpreter, Java Classes or Java Compiler that are needed to support Supplemental Java Classes, Microsoft must implement all such modifications or enhancements into a Compatible Implementation of its Java Reference Implementation within, at the longest, six (6) months. TLDA section 26(a)(iv). Thereafter, pursuant to TLDA section 2.6(a)(vi), any new version of a Product that Microsoft makes commercially available to the public must include only the corresponding Compatible Implementation, subject, however, to the right of Microsoft under TLDA section 2.7(a) to choose not to distribute Supplemental Java Classes as part of a Microsoft Product. To the extent that Microsoft decides not to bundle Supplemental Java Classes as part of a Product, TLDA section 2.6(a)(vii) makes clear that Microsoft's Product must nonetheless pass the Relevant Test Suite when combined with the Supplemental Java Classes that it excludes. Thus, irrespective of whether Microsoft elects to bundle Supplemental Java Classes with its Products, it nonetheless has the obligation to upgrade its Java Reference Implementation by implementing the technology needed to support such Supplemental Java Classes in a manner that passes the Test Suite that accompanied them, and to do so within six months following their delivery by Sun. TLDA sections 2.6(a)(iv) and (vii). Once Microsoft has fulfilled its obligation under section 2.6 to create a Compatible Implementation that incorporates the upgraded technology, section 2.7(a) provides Microsoft the right not to bundle the Supplemental Java Classes with the Products it distributes. However, if Microsoft elects not to include Supplemental Java Classes as part of a Product it distributes, it must nonetheless distribute such Supplemental Java Classes to independent developers and others on an expedited basis through the Microsoft Developer Network ("MSDN") pursuant to TLDA section 2.7(a). The purpose of section 2.7(a) is to ensure that insofar as Microsoft elects not to bundle Supplemental Java Classes with its Products, it will nonetheless promptly distribute such excluded Classes through its Website and developer network so that developers will have the lead time needed to incorporate the excluded Classes in applications they develop for Microsoft's most current Products. Thus, section 2.7(a) imposes upon Microsoft, not Sun, the obligation to distribute, on an accelerated basis, any Supplemental Java Classes that Microsoft declines to bundle, and to do so in a way that can easily be combined by developers and end-users with the Products Microsoft distributes. Properly construed, section 2.7(a) thus means exactly what it says: the Supplemental Java Classes delivered by Sun will run on the "most current" version of Microsoft's Java Reference Implementation, that is, the version of Microsoft's Reference Implementation that compatibly implements the Significant Upgrade in which the Supplemental Java Classes were delivered. As noted above, the TLDA specifically contemplates that Sun may upgrade the Technology. If Sun designates an Upgrade as a "Significant Upgrade," Section 2.6 requires Microsoft to implement that Significant Upgrade in an upgraded version of the Java Reference Implementation that passes Sun's test suite. Microsoft must then deliver the Source Code for that upgraded Compatible Implementation to Sun:
To the extent a Significant Upgrade designated by Sun includes modifications or enhancements that permit the Java Runtime Interpreter, Java Classes, or Java Compiler to run or compile Supplemental Java Classes, Microsoft must implement all such changes or enhancements as are required to pass the Test Suite that accompanied the Significant Upgrade. Once Microsoft has built, tested and delivered to Sun a Compatible Implementation of its Java Reference Implementation, section 2.7(a) provides Microsoft a limited right to distribute Products that do not bundle the Supplemental Java Classes as a part of the Product: "Licensee may determine, in its sole discretion, to include one or more Supplemental Java Classes in its Products; however, Licensee shall not be obligated to distribute any Supplemental Java Classes with its Products." But if Microsoft chooses not to bundle Supplemental Java Classes with its Product, section 2.7 goes on to require Microsoft to promptly notify Sun of its decision and to make the excluded classes available on an expedited basis through alternate distribution channels. Why does section 2.7(a) require expedited distribution? As reflected in Microsoft's March 5, 1996 draft of the TLDA, Microsoft initially sought the right to exclude Supplemental Java Classes from its Product implementations without any corresponding obligation to distribute the excluded classes through its alternate distribution channels. See Exh. 9 Microsoft's 3/5/96 Draft TLDA, section 2.7. In addition, Microsoft proposed that its implementations of the Java Technology not be required to pass that portion of a Relevant Test Suite that tests for conformance of Microsoft's Products with any Supplemental Classes delivered by Sun. See Id. Microsoft's 3/5/96 Draft TLDA section 2.6(a)(iii). Sun refused, and insisted that each Microsoft Product implement the functionality required to Support Supplemental Java Classes, and do so in a manner that passed the Relevant Test Suite. Microsoft agreed, and that agreement is reflected in TLDA section 2.6(a)(vii). 1/22/99 Baratz Declaration ¶¶ 12-13. In addition, while Sun agreed that Microsoft could choose not to bundle Supplemental Java Classes with the Products it distributes, it insisted that Microsoft agree to use its distribution channels to deliver whatever Supplemental Java Classes it chose to exclude from its Product to independent software developers so that they could incorporate such classes in the applications they were developing. 1/22/99 Baratz Declaration ¶14. If the Supplemental Java Classes were expeditiously posted on Microsoft's website and expeditiously distributed in its MSDN channel, Microsoft (and Sun) could be assured that hundreds of thousands of software developers would be able to "fine tune their programs to conform to any changes in the final version and then quickly release their products to market." Consequently, Sun insisted that Microsoft agree to distribute any excluded Supplemental Java Classes on an accelerated basis, so that developers would have the lead time they would need in order to incorporate the excluded classes in the applications they were developing in time to market their applications concurrent with the anticipated release of Microsoft's upgraded Products. 1/22/99 Baratz Declaration ¶ 14. Microsoft at first acquiesced in Sun's demand. See Exhibit 8 Microsoft's 3/10/96 Draft TLDA section 2.7. However, on the final night of negotiations, Microsoft balked, stating that it was reluctant to agree to immediately place Sun's Supplemental Java Classes into distribution unless it had some assurance that they would run as intended when combined with Microsoft's upgraded Java Reference Implementation. 1/22/99 Baratz Declaration ¶ 15. Having agreed to distribute the Supplemental Java Classes to thousands of developers through its Website and MSDN, Microsoft wanted assurances that the Supplemental Java Classes would run on the implementation for which they were intended. The implementation for which they were intended was not an out-of-date, prior implementation that lacked the new functionality needed to support them; rather, the implementation for which they were intended was the "most current" version of Microsoft's Java Reference Implementation, the version that implemented the Significant Upgrade that contained the functionality needed to support the Supplemental Java Classes, and passed the Java Test Suite that accompanied them. To address Microsoft's stated concern, Sun agreed that the Supplemental Java Classes it delivered as part of an Upgrade would function properly with the upgraded version of Microsoft's Java Reference Implementation, and that representation is set forth in the last sentence of section 2.7(a). Although section 2.7(a) provides Microsoft a limited right not to bundle Supplemental Java Classes as part of a Product that Microsoft distributes, all such Products must nonetheless first pass Sun's Test Suite, including such tests as validate Microsoft's compatible implementation of any upgraded technology needed to support Supplemental Java Classes. Sections 2.6(a)(vi) (vii) make this clear:
Sun was able to provide the assurance that Microsoft sought because Sun controls the functionality of the Significant Upgrade and the content of the accompanying test suite. It is thus within Sun's control to ensure that so long as the Significant Upgrade is implemented in a manner that passes the accompanying test suite, the Supplemental Java Classes would run on the upgraded Java Reference Implementation -- the "most current Java Reference Implementation." Because Microsoft is obligated to upgrade its Java Reference Implementation and pass the Sun Test Suite that accompanies the Upgrade, Sun had every confidence that applications incorporating the Supplemental Java Classes distributed by Microsoft would run on the most current version of Microsoft's Java Reference Implementation. That is why Section 2.7(a) concludes "The Supplemental Classes shall run on the most current Java Reference Implementation." Section 2.7(a) does not require, as Microsoft apparently contends, that newly developed Supplemental Java Classes must run on an outdated, prior version of Microsoft's Java Reference Implementation. Nor would any such requirement make sense since, by definition, Supplemental JAVA Classes add new functionality to that previously supported in a prior implementation of the JAVA technology, and therefore are designed to run on the JAVA TECHNOLOGY as upgraded, not on outdated prior versions of the technology.
Summary adjudication is designed to avoid consumption of the Court's resources in a trial when there is no genuine dispute of material fact.1 Consistent with this purpose, in the Celotex trilogy the Supreme Court instructed that when the moving party establishes that there is no dispute of material fact (that is, no dispute about facts that could affect the outcome of the determination of the issue), the moving party is entitled to the Court's summary judgment or adjudication.2 It is only if the opposing party introduces admissible evidence of "specific facts showing that there is a genuine issue for trial" that the opposing party can avoid summary judgment or adjudication.3 Whether a contractual term is ambiguous is an issue of law for the Court, and if the contract is unambiguous, its interpretation is also an issue of law properly resolved by summary judgment.4 When the contract's terms are unambiguous summary judgment is appropriate, even if the parties dispute the meaning of the terms.5
Contract provisions are ambiguous only when they are reasonably capable of two different interpretations.6 Here, the provisions of the TLDA can reasonably be interpreted in one way only: the Supplemental Java Classes would run on the most current Java Reference Implementation -- that is, the Java Reference Implementation created by Microsoft to implement the Significant Upgrade that includes the Supplemental Java Classes. First, and most fundamentally, the TLDA does not provide that the Supplemental Java Classes are to run on the "then current" Java Reference Implementation, as Microsoft contends. Had the parties meant to structure Microsoft's obligations regarding the execution of Supplemental Java Classes in that fashion, they could have. But they did not. Instead the parties chose to require that the Supplemental Java Classes TLDA to run on the "most current" Java Reference Implementation.7 Second, the contractual context in which section 2.7(a) appears makes clear that "most current" means the Microsoft implementation that incorporates the Significant Upgrade that includes the Supplemental Java Classes. The TLDA expressly allows Sun to deliver new and enhanced "Technology," including Supplemental Java Classes, in the form of Upgrades. Section 2.6, entitled "Compatibility," sets forth the progression of events by which Sun may require Microsoft to incorporate such modifications or enhancements in the Products Microsoft distributes by designating an Upgrade as a Significant Upgrade. Microsoft must thereupon incorporate the enhancements or modifications made in that Significant Upgrade -- including Supplemental Java Classes - into a new Compatible Implementation of the Java Reference Implementation that passes the Sun test suite that accompanied the Significant Upgrade. It is only after Microsoft has built, tested, and delivered to Sun a Compatible Implementation that satisfies the requirements of section 2.6(a)(iv), that the last sentence of section 2.7(a) comes into play. Section 2.7(a) creates a narrow exception to Microsoft's obligation to bundle and ship all of the elements of its Compatible Implementation in each Product Microsoft distributes. Section 2.7(a) allows Microsoft to choose not to bundle the Supplemental Java Classes in a Product -- but if Microsoft makes that choice, section 2.7(a) requires that Microsoft make the Supplemental Java Classes available on an expedited basis on its website (within 30 days) and through its Microsoft Developer Network (MSDN). These requirements ensure that developers will obtain the Supplemental Java Classes so that, when they begin developing application programs for the beta and other pre-releases of Microsoft's upgraded Java Reference Implementation, those applications can quickly be made to run on the upgraded Java Reference Implementation. Although section 2.7(a) gives Microsoft the right to choose not to bundle Supplemental Java Classes as a part of its Products, section 2.6(a)(viii) makes explicit that any Product shipped without Supplemental Java Classes must still pass the same Java Test Suite as Products shipped with them. These compatibility requirements are consistent with and follow from other provisions of the agreement that confirm Sun's control over the Technology. For example, the TLDA includes a license requiring Microsoft to display Sun's Compatibility Logo in association with the Products Microsoft distributes. Because the Products that Microsoft distributes are to be branded with Sun's Java COMPATIBLE Logo, thus designating Sun as the source of the Technology contained in all such Products, Sun - not Microsoft - must control the content and quality of the Technology. Similarly, the fact that Microsoft is Sun's distributor demonstrates yet again that it is Sun - not Microsoft - that controls the Technology that is the subject of the license. Finally, as the Court itself has repeatedly observed, the over-riding objective of the contract, to "maintain[] compatibility among Java Language based products" (TLDA Recital 1), is attainable only insofar as the agreement is construed to require adherence to a single, uniform standard specified by Sun.
Microsoft appears to assert that the purpose of section 2.7(a) is to require Sun's Significant Upgrade to be "backward compatible" -- that is, to run on Microsoft's prior Java Reference Implementation. Microsoft's assertion is simply not plausible. First, to the extent there is any requirement in the TLDA regarding "backward compatibility" of Upgrades delivered by Sun, that requirement is expressly set forth in section 2.6(a)(iii), which provides that "[e]ach Upgrade delivered by Sun to Licensee shall pass the Java Test Suite that accompanied such Upgrade and the test suite that accompanied the prior two (2) Upgrades." Second, if the last sentence of section 2.7(a) were in fact intended by the parties to be a condition or limitation on Sun's ability or right to deliver Upgrades, then presumably it would have appeared in section 2.6(a)(iii), which is the provision of the contract that expressly deals with such matters, not section 2.7(a), which deals with Microsoft's obligation to distribute Supplemental Java Classes over its website and through its Developer Network. Third, if Microsoft's construction were correct, it would contradict the parallel provisions of section 2.9(a) that clarify Sun's right to modify, alter or ignore Microsoft's implementation of the Technology, and 2.9(f) that allow Sun to use the Test Suites to require Microsoft to modify its implementation. Finally, if Microsoft's construction were correct, it would require the definition of Java Test Suite to be changed from "SUN's publicly available test suites for validating that products which interpret Java bytecodes comply with the SUN specification of the AAPI as of the date of the test suites," to add "except with respect to Supplemental Java Classes."8
In addition, Microsoft's interpretation would have the perverse effect of either of forcing Sun to cede control of the evolution of the Technology to Microsoft, or fragment the runtime and programming environments by delivering two incompatible versions of the Technology: one that conforms to Sun's specification of the Technology, and the other in conformance with Microsoft's specification. That hardly "maintain[s] compatibility among Java language based products." Microsoft's interpretation also conflicts with the manifest purpose of section 2.7(a) -- to speed the delivery of new JAVA technology to the market. If, as Microsoft contends, the contract were construed to require Supplemental Java Classes to run on the preceding version of Microsoft's Reference Implementation, the practical effect would simply be to delay the distribution of Supplemental Java Classes, not change their design or content in any respect. Applying Microsoft's construction of section 2.7(a), Sun would be required to deliver the upgraded technology needed to modify the Runtime Interpreter, Java Classes, and Java Compiler to run Supplemental Java Classes in a first Significant Upgrade of the Technology, and then once that Significant Upgrade was implemented, to deliver the Supplemental Java Classes themselves in a second, later Significant Upgrade. Obviously, rather than accelerate Microsoft's distribution of new JAVA technology to the market as section 2.7 was designed to accomplish, Microsoft's construction of the clause would simply delay that distribution. But most importantly, Microsoft's construction is not plausible. As Microsoft would construe section 2.7(a), the tail wags the dog. Under Microsoft's interpretation, Microsoft would be elevated from one of many distributors of Sun's technology to a position of effective control over the Technology. Under Microsoft's interpretation, Microsoft not Sun - would control the evolution of the JAVA technology. Under Microsoft's interpretation, Microsoft, not -- Sun, would control the content and quality of the technology associated with Sun's Java COMPATIBLE Logo. Under Microsoft's interpretation, the central purpose of the JAVA technology -- to level the playing field by affording developers an opportunity to write one version of code that can be executed on multiple implementations - is compromised. There is, of course, a wealth of evidence supporting Sun's position. Microsoft's in-house counsel Erich Andersen admitted in deposition testimony that the last sentence of § 2.7(a) was added at Microsoft's request during the last negotiation session, without much discussion, and that it "was a pretty noncontroversial addition to the agreement."9 Given the dramatic effects of Microsoft's construction as discussed above, it is not plausible that it would have been "noncontroversial" for Sun to accept a change implementing those effects.
The 30(b)(6) testimony of Sun's Alan Baratz, who signed the TLDA on Sun's behalf, was that Sun understood the last sentence of § 2.7(a) as Sun explains it here,10 and Sun's correspondence with Microsoft on this issue was similarly consistent.11 Mr. Baratz further explained in his deposition that
In short, there is a wealth of extrinsic evidence supporting Sun's construction, which is consistent with the TLDA's plain terms. Microsoft's asserted construction, however, is not, which is why the Court must disregard whatever parol evidence Microsoft submits. The last sentence of section 2.7(a) is clear and specific, and the TLDA's purpose and structure confirm that the sentence means what it says. Because the issue is so clear, Microsoft may try to introduce parol evidence (internal self-serving emails and other evidence) to the effect that what the last sentence of section 2.7(a) means is that when Sun delivers a Significant Upgrade (which Microsoft must then incorporate into an upgraded Java Reference Implementation), those Supplemental Java Classes must run on then-current Java Reference Implementation. The Court should not be misled. As the Ninth Circuit has explained,
The TLDA contains an integration clause, and "[t]hus, parol evidence of terms not included in the written contract is not admissible."14 Therefore, parol evidence is admissible only if, after the Court preliminarily considers it, the Court concludes that the TLDA provisions at issue are reasonably susceptible of the interpretation Microsoft proffers.15 As the Ninth Circuit has explained, "[i]f the Court finds after considering this preliminary evidence that the contract is not reasonably susceptible of [the proffered] interpretation and is unambiguous, extrinsic evidence cannot be received for purposes of varying the terms of the contract."16 And as the California appellate courts have explained, "When a dispute arises over the meaning of contract language, the first question to be decided is whether the language is `reasonably susceptible' to the interpretation urged by the party [offering extrinsic evidence]. If it is not, the case is over."17 As explained more fully above, the TLDA is not susceptible of the meaning Microsoft asserts. No matter what documents or testimony Microsoft proffers, it cannot alter the TLDA's plain meaning. The last sentence of § 2.7(a) can mean only one thing. The Supplemental Java Classes Sun delivered as part of a Significant Upgrade shall run on the Java Reference Implementation that Microsoft must thereafter build, deliver to Sun, and distribute (if Microsoft chose to distribute any Product). If the parties had meant for the Supplemental Java Classes to run on the then-current Java Reference Implementation, they would have written "then current" instead of "most current," would have changed other parts of the TLDA, including the trademark license, and would have discussed thoroughly the implications of such a sea change in the Sun/Microsoft relationship and the JAVA technology's place in the industry generally. But the parties did not do so. The TLDA is unambiguous on this point, and no parol evidence that Microsoft proffers can alter that fact.
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
