Tech Law Journal

Capitol Dome
News, records, and analysis of legislation, litigation, and regulation affecting the computer, internet, communications and information technology sectors

TLJ Links: Home | Calendar | Subscribe | Back Issues | Reference
Other: Thomas | USC | CFR | FR | FCC | USPTO | CO | NTIA | EDGAR

Sun's Corrected Memorandum in Support of Motion for Preliminary Injunction for Unfair Trade Competition Under Cal. Bus. & Prof. Code.
Re: Sun v. Microsoft, U.S.D.C., N.D. Cal., San Jose, Case No. 97-20884. 

Date: Original filed May 12, 1998; corrected version filed July 31, 1998; and this version filed and made public on October 21, 1998. (?)
Source: Sun Microsystems. This document has been edited for HTML, but not for content.   Footnotes have been converted into sidenotes.

LLOYD R. DAY, JR. (90875)
JANET L. CULLUM (104336)
Five Palo Alto Square
3000 El Camino Real
Palo Alto, CA 94306-2155
Telephone: (650) 843-5000

Attorneys for Plaintiff


a Delaware corporation,



a Washington corporation,


No. C 97-20884 RMW (PVT) ENE

BUS. & PROF.CODE § 17200 et seq.

Date: July 31, 1998
Time: 9:00 a.m.
Judge: Hon. Ronald M. Whyte
Crtrm: 6

Refiled Pursuant to
10/21/98 Order of the Court


A. Microsoft's Three-Part Scheme. 10
B. Step 1: Fragment the JAVA Environment. 12
1. Microsoft's Original Effort To Fragment and Appropriate Sun's JAVA Technology 13
2. Microsoft's Latest Efforts to Fragment and Appropriate the JAVA Technology. 14
C. Step 2: Induce Developers To Create Microsoft-Dependent Applications. 18
D. Step 3: Exploit Windows Monopoly To Grab Market Share. 20
A. A Few Well-Established Principles Of Unfair Competition Law Mandate An Injunction Against Microsoft 23
B. Microsoft Seeks To Destroy The Value Of Sun's JAVA Technology 25


Allied Grape Growers v. Bronco Wine Co., 203 Cal. App. 3d 432, 452 (1988) 24
Barquis v. Merchants Collection Ass'n, 7 Cal. 3d 94, 112 (1972) 23
Committee on Children`s Television, Inc. v. General Foods Corp., 35 Cal. 3d 197, 209-10 (1983) 23
Hewlett v. Squaw Valley Ski Corp., 54 Cal. App. 4th 499, 540 (1997) 24
Locke v. Warner Bros., Inc., 57 Cal. App. 4th 354, 363 (1997) 25
People v. Cappuccio, Inc., 204 Cal. App. 3d 750, 760 (1988) 24
Podolsky v. First Healthcare Corp., 50 Cal. App. 4th 632, 648 (1996) 24
Saunders v. Superior Court, 27 Cal. App. 4th 832, 839 (1994) 24
State Farm Fire & Casualty Co. v. Superior Court, 45 Cal. App. 4th 1093, 1103 (1996) 23
Sunbelt Television, Inc. v. Jones Intercable, Inc., 795 F.Supp. 333, 338 (C.D. Cal. 1992) 24
Sutherland v. Barclays American/Mortgage Corp., 53 Cal. App. 4th 299, 314 (1997) 25
Tippet v. Terich, 37 Cal. App. 4th 1517, 1536 (1995) 23
United States Surgical Corp. v. Origin Medsystems, Inc., 27 U.S.P.Q.2d 1526 (N.D. Cal. 1993), 1993 WL 379579 at *1. 23


"Strategic Objective
"Kill cross-platform Java by grow[ing] the polluted Java market"
--Microsoft Pricing Proposal for VJ++ 6.01
1 Armstrong Decl., Exh. 1


Microsoft is exploiting its unrivalled monopoly power in desktop operating systems in an effort to wrest control of Sun's JAVATM technology from Sun by flooding the market with products that effectively transform Sun's standard JAVA environment into an incompatible Microsoft-dependent environment.

This Court has already determined that Sun is likely to prevail in showing that Microsoft's Internet Explorer ("IE") 4.0 browser and Software Development Kit for JAVA ("SDKJ 2.0") fail to pass Sun's relevant test suite, and therefore fall outside the scope of Microsoft's license to distribute products that incorporate Sun's JAVA technology. The Court's earlier ruling notwithstanding, Microsoft persists in distributing its unlicensed, incompatible products, and is poised to launch yet additional products that will greatly exacerbate the irreparable injury already caused to Sun, its other distributors, and to developers and consumers in general.

Microsoft's campaign to fragment and hijack Sun's JAVA technology has taken on fresh urgency in the wake of its new product announcements since Sun's earlier motion. Microsoft is currently in the process of releasing two new JAVA development tools, VJ++6.0 and SDKJ 3.0, and has announced plans to release in late June 1998 its next generation operating system, Windows98, containing incompatible, Microsoft-dependent implementations of Sun's JAVA technology. Microsoft's distribution of these new products, which Microsoft describes as taking "Windows-specific Java . . . fully public" (Armstrong Decl., Ex. 26), threatens to complete the fragmentation of Sun's JAVA programming environment begun in SDKJ 2.0 and Internet Explorer 4.0, and wrest control of Sun's JAVA technology away from Sun. Significantly, Microsoft plans to bundle its non-conforming JAVA implementations with Windows98, thereby flooding the market with more than 1 million new PCs per month pre-installed with "Windows-specific Java." Baratz Decl., ¶ 2.

In deliberate violation of its contractual undertakings and Sun's property rights, Microsoft is drawing on its vastly superior distribution channels for desktop operating systems and browsers to inundate the market for desktop computers with an unlicensed, incompatible version of Sun's JAVA environment in a blatant effort to devalue Sun's technology and establish its own, corrupted version as a de facto industry standard. Unwilling to rely on its distribution channels alone, Microsoft also has unlawfully secured the agreement of its various licensees and distributors to refrain from incorporating conforming implementations of Sun's JAVA technology in the products they distribute, and instead agree to re-distribute Microsoft's incompatible, Windows-dependent version of Sun's technology. Abusing its monopoly in desktop operating systems, Microsoft has also extracted the agreement of original equipment manufacturers, Internet service providers and Internet content providers not to distribute the JAVA-based browsers of Sun's other licensees, including Netscape, thereby effectively closing another important channel of distribution for Sun's technology.

Flagrantly abusing its monopoly control over the distribution of operating systems software, Microsoft seeks to appropriate for itself alone the benefits of Sun's pathbreaking JAVA technology, while simultaneously neutralizing its commercial appeal as a competitive alternative to Microsoft's operating systems monopoly. By flooding the market with desktop systems and browsers that support only Microsoft's corrupted version of Sun's JAVA environment, and not the standard JAVA environment, Microsoft is acting to destroy the promise of an industry-wide, uniform programming environment, as well as the economic incentive of consumers and developers alike to adopt and use the standard JAVA environment. By simultaneously distributing unlicensed toolkits designed to induce developers to create and distribute applications using Microsoft's corrupted JAVA environment, Microsoft similarly seeks to flood the market with applications that are tied to and dependent on the use of Microsoft's corrupted JAVA environment and the products that support it.

If Microsoft is permitted to proceed with its unfair and monopolistic scheme, no relief this Court can subsequently grant will undo or fully remedy the harm that will befall Sun, its many other licensees, and particularly the consumers and software developers who have relied on Microsoft's obligation to comply with its license.

The issue presented by this motion is straightforward: Will Microsoft be permitted to distribute incompatible implementations of Sun's JAVA technology in its operating systems, browsers and related toolkits, where the necessary -- and intended -- effect of its wrongful conduct will be the destruction of the competitive market Sun's technology and license agreements create?


Microsoft and Sun compete with one another in the distribution of programming environments for personal computers, browsers and other systems platforms. Microsoft's Windows brand of operating systems dominates the market for PC operating systems, and its Internet Explorer browser program is poised to dominate the PC market for browsers. Microsoft's Windows operating systems and its Internet Explorer browser create platform-dependent programming environments. Application programs developed for Microsoft's platform-dependent environments specifically require and function only with Microsoft's Windows operating system, browser or virtual machine, and will not function on any other vendor's operating system, browser or virtual machine. Baratz Decl., ¶ 4.

The platform-dependent nature of Microsoft's programming environments, coupled with its overwhelmingly dominant share of PC systems, enables Microsoft to maintain its dominance of the market for PC operating systems by raising substantial barriers to competition. These barriers result from a dynamic interplay between the increasing returns to scale achieved in the production of application programs and network effects among consumers. Arrow Decl., ¶¶ 7-15. Since most of the costs incurred in developing application programs occur in the development of the program, the marginal cost of producing an additional copy of an already-written program is virtually zero. Because the fixed costs of program development are high, and the marginal costs are low, there is a strong incentive to develop applications for environments with a large installed base of users in preference to a smaller base. Consequently, the number and variety of programs will be greatest for the operating system with the largest market share. At the same time, consumer demand will be greatest for operating systems with the largest number and greatest variety of application programs. These factors create a feedback effect in which more programs lead to more consumer demand, which leads to more programs. That phenomenon, coupled with the obvious desire to achieve compatibility with the largest installed base of other systems, serves to perpetuate and even expand Microsoft's dominance of the market. Arrow Decl. ¶¶ 10-15.


In contrast to Microsoft's platform-dependent programming environments, Sun's JAVA technology creates a platform-independent environment that can be compatibly implemented by many different competing vendors. Deutsch Decl., ¶¶ 27-28. Since applications developed for the JAVA programming environment can run on any system or browser that implements the JAVA technology in conformance with Sun's requirements and test suites, a vendor who compatibly implements the JAVA technology can immediately obtain the benefit and use of every application developed for the JAVA programming environment, not just those that are specifically developed for its particular operating system or browser. The availability of applications that are capable of running on competing operating systems as well as Microsoft's operating systems significantly reduces the competitive advantage Microsoft enjoys. Sun's JAVA technology thus reduces the barriers to competition that confront the operating system and browser manufacturers who wish to compete with Microsoft's operating systems and browsers. Arrow Decl., ¶ 21.

By licensing other systems vendors and distributors, including Microsoft, to produce and distribute products that implement its JAVA programming environment, Sun has created a rapidly expanding market for applications and systems that implement and use the JAVA programming environment. Baratz Decl., ¶ 8. So long as Microsoft's implementation of the JAVA programming environment is compatible with those of Sun's other licensed distributors, the fact that Microsoft's operating systems have an overwhelmingly dominant share of the market is not alone sufficient to induce developers to develop platform-dependent applications for Microsoft's systems, particularly since the JAVATM programming environment would allow them to reach an even larger installed base of systems, and thus a larger potential return on their investment in program development. The same is true for consumers, who will no longer be constrained to buy Microsoft systems if they wish to run programs that can operate on Microsoft and other systems. Arrow Decl., ¶¶ 16-22.

Because the JAVA programming environment is implemented on many different systems, including Microsoft's systems, the potential market it offers software developers for applications development is even larger than the potential market for Windows applications. By offering an alternative environment for applications development, one that has a market potential that is even larger than the Windows market, Sun's JAVA technology has the potential to render the Windows operating system and the programming environment it supports significantly less important to developers and consumers alike. Arrow Decl., ¶ 22. Sun's JAVA technology thus acts to counter if not eliminate the feedback effect that sustains Microsoft's monopoly, and threatens its foundation. Arrow Decl., ¶ 22-24.

For that and other reasons, Microsoft has a strong incentive to neutralize the cross-platform compatibility of the JAVA environment. Arrow Decl., ¶ 24. Insofar as Microsoft is licensed to distribute products that implement the JAVA environment, and toolkits for development of applications for that environment, it is particularly important that it do so in a manner that is compatible with the standard JAVA environment if the cross-platform potential of the JAVA environment is to be achieved. The fact that Microsoft commands such a large share of the market for products that implement the environment, such as personal operating systems and browsers, creates an opportunity for it to abuse its market share to seize control of the standard JAVA environment and transform it to a Microsoft-dependent environment. Because Microsoft accounts for the great majority of the products shipped that implement the JAVA environment, it can effectively seize control of that environment simply by differentiating its implementation of the environment from all others in the market. Arrow Decl., ¶ 23.


Microsoft's senior management immediately appreciated the threat posed by Sun's JAVA technology to the foundations of Microsoft's monopoly. As one Microsoft analyst observed in a November 1995 white paper entitled "What Should We Do About Java?":

"[A]ny Java application or applet can be run on any Java enabled platform without machine specific or OS specific knowledge or restrictions. In effect, the machine and OS specifics have been made irrelevant. A new and complete interface has developed that completely hides the machine franchise and indeed, goes a long way toward hiding the OS franchise. The Java language is the only net interface the program sees. This hiding of the Microsoft franchise is certainly not good for Microsoft."

Armstrong Decl., Ex. 2 at 4. Indeed, so pronounced is the threat to Microsoft's monopoly that it prompted Bill Gates to warn his staff in September 1996:

"This scares the hell out of me.

"Its still very unclear to me what our OS will offer to JAVA client applications code that will make them unique enough to preserve our market position.

"Understanding this is so important that it deserves top priority."

Armstrong Decl., Ex. 3.

At the same time, Microsoft also coveted the commercial and technical benefits that Sun's JAVA technology provides. As a March 1996 Microsoft white paper states:

"The growth of the Internet has made the cross-platform nature of technologies a significant deciding factor for customers. . . . The increasing importance of the Intranet [networks] also increases the importance of cross-platform technologies. MIS managers want applications to be available to all their users independent of platform. Java is popular on the Internet and Intranet because of its simplicity and cross-platform nature."

Armstrong Decl., Ex. 4.

Confronted with this dilemma, Microsoft had three legitimate choices:

It could ignore Sun's technology and hope that it failed in the market;

It could independently develop and distribute products that incorporated its own technology to compete against the JAVA technology without license from Sun; or

It could license the JAVA technology from Sun and become a distributor of products that incorporate Sun's technology.

Ostensibly, Microsoft chose the third alternative, and took on the rights -- and the obligations -- of a licensed distributor of products that implement Sun's JAVA environment. It did so by promising Sun that the products Microsoft distributed would implement Sun's technology in conformance with Sun's requirements, and that promise is embodied in Microsoft's agreement that it would only distribute such products as have passed Sun's compatibility test suites. Section 2.6(a) of the agreement expressly requires that before Microsoft distributes any product that incorporates the JAVA technology, that product must first pass Sun's compatibility test suite. Batchelder Decl., Ex. F. As this Court previously held, the course of dealing between Microsoft and Sun "establishes that Microsoft's products must pass all the tests in the JCK test suite, unless Sun indicates otherwise." 3/24/98 Court Order at 15. "Pursuant to section 2.6(a)(iv), each new version of any Microsoft product that incorporates Sun's JAVA technology must pass the test suites of the JCK" before Microsoft can distribute it. Id. at 4.

There can be no doubt that Microsoft understood and agreed that the products it was licensed to distribute were required to incorporate Sun's JAVA programming environment, not an incompatible version tied to and dependent on Microsoft's Windows operating system. As Alan Baratz, JavaSoft's president and a lead negotiator of the distribution agreement, testified:

"I believe that we communicated to and Microsoft was well aware of the fact that compatibility was the core value proposition behind the Java technology, behind the Java platform . . . and it was the most important aspect of this agreement in that . . . we would ensure that Microsoft product that integrates the technology would remain compatible with every other licensee products that integrate the technology . . . So write it once. Run it anywhere . . . That is the value that Java brings to developers, and the value Java brings to consumers, and the value that Java brings to hardware and software OEMs. And we entered into this agreement for Microsoft to be a channel for delivering that technology compatibility [sic], i.e., preserving that value proposition within their products. And yes, I believe they fully understood that."

Armstrong Decl., Ex. 5. As the recitals make plain, and as one of Microsoft's lead negotiators, Robert Muglia, acknowledged, the reason Microsoft was licensed to distribute products that incorporated Sun's technology was to secure the widespread compatible distribution of Sun's JAVA programming environment:

"Sun wanted Microsoft to license the technology to help validate the JAVA technology, given our important market presence, as well as to provide a distribution vehicle for the technology inside Microsoft's products."

"Alan [Baratz] did indicate that he wanted the JAVA technology to be widely available to developers on Microsoft platforms. And given the fact that Microsoft ships a large number of copies of Windows, this was a good distribution vehicle for him."

Armstrong Decl., Ex. 6. Sun did not grant Microsoft the right to distribute products incorporating Sun's technology so that Microsoft could fight with Sun for control of Sun's technology. And it certainly did not agree that Microsoft would be allowed to use its vastly superior distribution channels to wrest control of Sun's technology from Sun by flooding the market with products that create a non-conforming, Microsoft-dependent version of the JAVA environment. As the Court previously concluded, the notion that Sun agreed to let Microsoft use Sun's technology to distribute products that are incompatible with the JAVA programming environment is implausible on its face:

"Microsoft's manipulation of the ambiguities surrounding section 2 of the TLDA . . . cannot be reconciled with the purpose behind the TLDA and the JAVA technology itself. Microsoft's reading of the TLDA would essentially allow Microsoft to destroy the cross-platform compatibility of the JAVA programming environment."

3/24/98 Court Order at 15 (emphasis added). "Microsoft's interpretation of the TLDA is inconsistent with JAVA's objective of cross-platform compatibility." Id. at 14 n.3.


Even as Microsoft was promising Sun that the products it would distribute would conform to Sun's requirements, it was secretly preparing to undermine the value and appeal of Sun's JAVA technology by distributing something very different. In February 1996, even before signing the distribution agreement, Microsoft's Executive Vice President, Paul Maritz, outlined Microsoft's strategy to win the browser war with Netscape and simultaneously "neutralize Java" by "tying" the "user interface" and "APIs" "back to Windows," by "get[ting] control of JAVA with JAVA support/tools", and by "get[ting] control of then leverag[ing] the programming model." Armstrong Decl., Ex. 7 at 10-12.

That scheme, clearly documented in Microsoft's senior-most management briefings weeks before the contract was signed, and further elaborated in the years following the execution of the agreement (Armstrong Decl., Ex. 8), seeks to maintain and expand Microsoft's monopoly in desktop operating systems by unfairly abusing Microsoft's status as a licensed distributor of Sun's JAVA technology to wrest control of the standard platform-independent JAVA environment from Sun and transform it into a Microsoft-dependent environment, one that is uniquely tied to and operable only with the virtual machine and Windows operating system that Microsoft alone distributes.

As reported to Bill Gates in April 1997 by the manager responsible for execution of Microsoft's strategy:

"When I met with you last, you had a lot of pretty pointed questions about Java, so I want to make sure I understand your issues/concerns. . . .

  1. What is our business model for Java?
  2. How do we wrest control of Java away from Sun?
  3. How do we turn Java into just the latest, best way to write Windows applications?
  4. What are we doing to leverage/expose Windows to Java developers?
  5. Implications of our Sun contract to our evolution of Java?"

Armstrong Decl., Ex. 9. Microsoft's recent product announcements provide the answers.

To "turn Java into just the latest, best way to write Windows applications," Microsoft is distributing tools deliberately designed to destroy the cross-platform capability of the JAVA applications they create. As poignantly described in Microsoft's pricing strategies for its upcoming VJ++ 6.0 JAVA development suite, the "strategic objective" of its new toolkit is to "Eliminate/contain cross-platform Java by growing the polluted Java market," "migrate and lock Java developers to Win32 Java," and ultimately to "kill cross-platform Java by grow[ing] the polluted Java market." Armstrong Decl., Exs. 10-11, 1. Recognizing that "cross-platform capability is by far the number one reason for choosing/using Java," and that Microsoft's Windows-dependent products do "not cater to the current market demand," Microsoft deliberately plans to set a low price point for its tools. Why? Because Microsoft "need[s] high distribution of a product that is not demanded by the market." Armstrong Decl., Ex. 10.

To "wrest control of JAVA away from Sun," Microsoft is leveraging its monopoly in PC operating systems to make its polluted JAVA environment dominant as well. As recounted in a March 1997 e-mail outlining Mr. Gates's strategy to the head of Microsoft's JAVA development program:

"What I think Bill says:
. . .
"We give away the Java VM to ISVs (to ship without royalty), but only on Windows. (I think he confirmed that we could charge OEMs a royalty for our VM, once it became ubiquitous) . . . This is interesting. It leverages our desktop dominance to help our Java VM become dominant, and avoids giving away value in the form of a capable VM on other OSs. Our VM can be capable on other OSs, but we get paid for that value and thus reduce the value of those OSs. For Windows our VM can have value, but the link to Windows means we get paid for it there via Windows royalties. This seems really smart to me."

Armstrong Decl., Ex. 38.

In short, Microsoft is deliberately working to destroy the very market it agreed to help Sun and all other JAVA distributors to create. Now, two years after the agreement was signed, Microsoft has finally dropped all pretense of any intent to fulfill its express contractual obligation. Instead, it is deliberately abusing its status as Sun's distributor, exploiting its monopoly power in the market for personal computer operating systems to maintain and expand that monopoly, and unfairly using its dominance of the distribution channels for operating systems, browser programs and related software development tools to wrest from Sun control of Sun's JAVA programming environment. Arrow Decl. ¶ 31-32.

A.  Microsoft's Three-Part Scheme.

Microsoft's unlawful scheme to destroy the cross-platform promise of the JAVA technology, while simultaneously hijacking it for Microsoft's benefit alone, entails three essential steps.

First, having obtained the right to distribute products incorporating Sun's technology on the pretext that its products would conform to Sun's standards, Microsoft immediately set out to fragment Sun's JAVA technology, that is, to alter the technology implemented in the products Microsoft distributes in ways contrived by Microsoft to render the programming and runtime environments supported by its products incompatible with the standard JAVA environment supported by the products of all other JAVA distributors. As one senior Microsoft vice president succinctly stated, "I would explicitly be different -- just to be different.... [W]ithout something to pollute Java more to Windows (show new cool features that are only in Windows) we expose ourselves to more portable code on other platforms." Armstrong Decl., Ex. 12. By fragmenting the JAVA environment into two, incompatible environments, Microsoft forces developers and consumers to choose which environment they will support. Forced to choose, Microsoft can safely rely on its dominant market share, together with the economic incentive of developers to develop applications for the environment having the largest share of installed systems, to cause developers and consumers alike to adopt whatever environment Microsoft products support. Arrow Decl., ¶ 26. Second, to render its polluted JAVA environment commercially attractive to consumers, Microsoft must induce independent software developers to create applications for that environment. Armstrong Decl., Exs. 14, 15, 18. To that end, Microsoft must also develop and distribute the tools needed to do so. The distribution of tools designed to create applications that will run only on Microsoft's products and no others is an essential component of Microsoft's strategy to fragment the JAVA market and lock-in consumers. As succinctly stated in an October 1996 "Java Strategy," Microsoft must "Get developers to write very rich Windows applications, controls, etc. in Java." Armstrong Decl., Ex. 15. Doing so proved difficult, however, particularly since it was the cross-platform appeal of Sun's technology that so attracted developers. For that reason, Microsoft publicly downplayed its true intentions in an effort to seduce independent software vendors and others into using Microsoft-specific APIs before ever realizing they had bought-in to the Microsoft platform.

"As i [sic] told charlesf [Fitzgerald] on the phone, at this point its [sic] not good to create MORE noise around our win32 java classes. Instead we should just quietly grow j++ share and assume that people will take advantage of our classes without ever realizing they are building win32-only java apps."

Armstrong Decl., Ex. 23.

Third, Microsoft set out to obtain a dominant market share for its Microsoft-dependent environment. As detailed in Microsoft's October 1996 "Java Strategy," the "key" objective is to "[d]rive MS Java VM and classlibs (w/ Win32 extensions!) to broad installed base." Armstrong Decl., Ex. 15. Unless a sufficiently large share of systems in the market support the Microsoft-dependent environment, developers will have little or no incentive to create applications for it. As the market share of products implementing the Microsoft-dependent environment grows, so too will the economic incentive of developers to create applications for it, and the economic incentive of consumers to use it. Indeed, if the share of products that implement the Microsoft-dependent environment becomes dominant, Microsoft can effectively wrest control of the JAVA technology away from Sun, since its non-conforming, Microsoft-dependent environment would then provide the largest potential market for development of "JAVA" applications. Arrow Decl., ¶¶ 23, 26.

As Microsoft well appreciates, its principal "lever" to achieve a dominant market share for its polluted JAVA environment is "Distribution (w/ Windows)." Armstrong Decl., Ex. 16. Indeed, it is precisely to obtain that market share dominance that Microsoft now seeks to exploit its Windows monopoly to distribute its non-conforming implementation as part of Windows98. By bundling its Microsoft-dependent environment with Windows98, Microsoft hopes to grab a ubiquitous market share for its non-conforming version of Sun's JAVA environment and thereby wrest control of Sun's JAVA technology away from Sun. Arrow Decl. ¶ 31.

B.  Step 1: Fragment the JAVA Environment.

As cogently explained by Dr. Kenneth Arrow, a Nobel laureate Stanford economist whose life's work includes the study of innovation and industrial organization, Microsoft has a pronounced economic incentive to fragment the JAVA environment. By fragmenting the JAVA environment, Microsoft can effectively force developers and consumers to choose which of two different and incompatible environments they will support. Confronted with such a choice, the relative market share enjoyed by the systems that support each environment is likely to be a determinative consideration in the minds of consumers and developers alike. To the extent that Microsoft commands the dominant share of installed systems that implement a JAVA environment, and to the extent that Microsoft is able to differentiate the environment its systems support from the standard JAVA environment supported on all other systems, it can exploit its market share advantage to drive the adoption of its non-standard environment. Arrow Decl. ¶ 26.

To achieve Microsoft's objectives, differentiation alone is not enough. To neutralize JAVA, while simultaneously preserving its monopoly position, Microsoft must also ensure that the applications developed for its fragmented environment are Microsoft-dependent, that is, tied to and dependent on the products Microsoft alone supplies. Arrow Decl. ¶¶ 25, 29, 31; Armstrong Decl., Ex. 18. By fragmenting JAVA into two, incompatible programming environments, Microsoft effectively defeats the promise of cross-platform compatibility created by Sun's JAVA technology and the open licensing program that accompanies it. Arrow Decl., ¶ 25. By rendering the applications developed for its incompatible environment dependent on the use of products it alone distributes, Microsoft's scheme locks consumers and developers alike into dependency on its platforms and thereby re-establishes the feedback effect that Sun's JAVA technology is designed and licensed to eliminate. Arrow Decl., ¶¶ 25, 29. Simply by being different, that is, by forcing developers and consumers to choose between two incompatible programming and runtime environments, the standard JAVA environment licensed by Sun and the corrupted environment distributed by Microsoft, Microsoft can exploit its overwhelming share of installed and newly shipping systems to cause developers and consumers to adopt the environment that is present on the largest share of desktop platforms: Microsoft's corrupted, platform-dependent environment. Arrow Decl., ¶¶ 23, 26, 29, 31.

1.  Microsoft's Original Effort To Fragment and Appropriate Sun's JAVA Technology

2  See generally 11/16/97 Hankinson Decl., filed in Support of Sun's Motion for Preliminary Injunction dated 11/17/97. In particular, Microsoft altered Sun's java.* core classes by adding a number of Microsoft APIs, deleting certain Sun APIs, and excluding Sun's standard Java Native Interface ("JNI") from its product implementations in favor of its Microsoft-dependent interfaces tied to its Windows OS.

As soon as Microsoft obtained the right to distribute products that incorporate Sun's JAVA technology, it deliberately set out to modify Sun's technology to render it dependent on and tied to the products that Microsoft alone distributes.2 Armstrong Decl., Ex. 20. As early as October 1996, Microsoft's "Java Strategy" laid out the scheme to "pollute" Sun's core JAVA classes "with Win-specific class libs," "[l]et Java class library space fragment, so that `write once, run anywhere' does not happen," then "[d]rive MS Java VM and classlibs (w/Win 32 extensions!) to broad installed base," to provide Microsoft ownership of "the de facto Java class library platform" tied to the Windows OS. Armstrong Decl., Ex. 15.

Significantly, Microsoft could have complied with its distribution license by implementing any new functionality it wished to add to Sun's standard set of java.* classes simply by packaging all such non-standard additions outside Sun's public classes and labeling them as Microsoft-specific "COM.MS" classes. TLDA § 2.8(d). Batchelder Decl., Ex. F. It chose covert action instead, and deliberately attempted to hide its changes to Sun's APIs by deceptively planting them within the existing java.* class hierarchy in direct violation of the express restrictions of the agreement. TLDA § 2.8(d).

"If we can get away with it, I would no[t] comment on our Java class extensions . . . I don't think we should push or publicize our java class work or the fragmentation that is occurring with Java in the industry."

Armstrong Decl., Ex. 23.

2.  Microsoft's Latest Efforts to Fragment and Appropriate the JAVA Technology.

Since this Court's March 24, 1998 Order, Microsoft's efforts to fragment and misappropriate the JAVA technology have, if anything, intensified. Indeed, Microsoft has developed and pre-released for worldwide distribution new toolkit products (VJ++ 6.0 and SDKJ 3.0) that not only replicate many of the impermissible alterations embedded in IE 4.0 and SDKJ 2.0, but also contain a new set of alterations to the JAVA technology further calculated to tie programs developed using such alterations to Microsoft's operating system, browser, and virtual machine.

VJ++ 6.0 and SDKJ 3.0 exacerbate Microsoft's earlier efforts to "neutralize Java" by tying it "back to Windows." Armstrong Decl., Ex. 21. Paul Gross, Microsoft's vice president in charge of tools development clearly spelled out the purpose behind Microsoft's VJ++ 6.0, for Steve Ballmer and Paul Maritz in January 1998:

"When people see the next version of VJ++, they will finally get what we mean by `making Java a great language for building Windows apps.' What they will see is Ironwood -- a framework that replaces our AFC and Sun's AWT and JFC. Ironwood is built on Jdirect so it basically provides an encapsulation of the Windows api easily accessible from Java. You build forms that are either ironwood or HTML or both. You don't build forms from Java Beans (the industry `standard' Java component model).

Basically, the #1 thing that draws people to Java is cross platform. VJ 1.1 held its own for a while as being a good tool for Sun's Java. VJ 6.0 will be a good tool for Microsoft's Java and not Sun's and hence not cross platform. Developers will scream. (But some will love it and recognize its inherent `elegance').

Is this all inevitable? Yes, with the course we chose. We decided rather than trying to outrun sun at their game to change the rules. Share will be the penalty. I do believe though that the write once run anywhere myth is slowly being debunked. And this will just be another nail. I believe we will prevail with this strategy in the long run."

Armstrong Decl. Ex. 34

a.  Microsoft's Improper "Extensions" Of The JAVA Language.

Microsoft has pre-released VJ++ 6.0, SDKJ 3.0 and Windows98 to effect further unauthorized incompatibilities with the standard JAVA environment by "extending" Sun's specification of the JAVA language. Cast in the form of new, unauthorized "keywords" and "compiler directives," these extensions further erode cross-platform compatibility by creating, in effect, a new programming language that is operable only on Microsoft's Windows platform using Microsoft's corrupted implementations of the JAVA technology. 5/11/98 Deutsch Decl., ¶¶ 4, 32, 52, 67-70, 73.

These new language features, which violate Sun's JAVA Language Specification and Sun's Virtual Machine Specification, will cause a compiler that conforms to the JAVA standards specified by Sun to reject or misinterpret any programs written using these new features. Deutsch Decl., ¶¶ 4, 32, 52, 57-58, 64-76, 73. These added features also will prevent the default configuration of Microsoft's compiler (which has been altered to accommodate these new language features) from compiling some valid programs written in the JAVA programming language specified by Sun.

Microsoft's most recent corruptions of the JAVA technology are deliberate attempt to undermine the cross-platform compatibility created by the JAVA technology and Sun's licensing program. Microsoft's non-conforming extensions gratuitously introduce both source and binary code incompatibility. Deutsch Decl., ¶¶ 4, 21-27, 32, 52, 64-70, 73. As a result, any developer wishing to create applications using Microsoft's non-standard features must do so using Microsoft's non-standard toolkit products (rather than the JAVA Compatible implementations and toolkits of Microsoft's competitors), and any applications using these new features will function only on Microsoft's corrupted compiler and virtual machine, and only in the context of the Windows operating system. Id. These newest alterations, the functionality of which could have been accomplished without destroying cross-platform compatibility (Deutsch Decl., ¶¶ 71, 90), manifest Microsoft's anticompetitive purpose, namely, to fragment rather than unify the JAVA programming environment. Even Microsoft's own senior developers see no merit to such gratuitous changes. Indeed, as the project manager of Microsoft's virtual machine development program candidly observed:

"I don't see why we need keywords for eventing. I've just finished a reasonable amount of work mapping the Beans model to ActiveX, and it seems perfectly sufficient for the eventing scenarios we've got. Is there some reason we'd want to do something different than support a simple model which works on all platforms, works with ActiveX, and doesn't require VM or compiler changes?"

Armstrong Decl., Ex. 40. Unless Microsoft's purpose is to fragment the JAVA programming environment, the answer is clearly no.

b.  Microsoft's Continuing Exclusion of JNI.

This Court found on March 24 that Microsoft's IE 4.0 and SDKJ 2.0 products failed Sun's compatibility tests for JNI, the standard JAVA interface by which native code may call services provided by a virtual machine. 3/24/98 Order at 7. Notwithstanding this Court's Order, Microsoft's pre-release versions of VJ++ 6.0, SDKJ 3.0, and Windows98 exclude JNI, just as IE 4.0 and SDKJ 2.0 did. Schroer Decl., ¶¶ 15, 19, 23.

The JNI interface enables developers to create native methods that can call JAVA code and access JAVA objects in a manner that will compatibly operate on any other JAVA Compatible virtual machine that runs on a given host system. Deutsch Decl., ¶ 5. Rather than include JNI, Microsoft's VJ++ 6.0, SDKJ 3.0 and Windows98 each contain non-standard native method interfaces, called RNI, J/Direct and Java/COM, that are tied to Microsoft's corrupted implementations of the JAVA technology. Using the Microsoft native method interfaces, the resulting native method programs will operate correctly only on the Microsoft virtual machine, and will fail to operate correctly on any other JAVA Compatible virtual machine developed for Microsoft's Win32 programming environment, such as those of Sun, Borland, Oracle and IBM. Deutsch Decl., ¶ 5.

Like Microsoft's addition of unauthorized language features (Deutsch Decl, ¶¶ 71, 90), Microsoft's refusal to implement JNI, and its exclusion from VJ++ 6.0, SDKJ 3.0, and Windows98, is totally unnecessary, and can only be calculated to defeat the cross-VM compatibility created by JNI. Microsoft could, for example, have implemented JNI in each of its products along with the Microsoft native method interfaces without degradation in performance. Deutsch Decl., ¶ 6.

Microsoft's exclusion of JNI from its product and toolkit implementations of the JAVA technology forces application developers, tool developers and end users to choose between Microsoft's non-conforming virtual machine implementation and the conforming virtual machine implementations of Sun's other licensees. Deutsch Dec., ¶ 7. Microsoft's exclusion of JNI from its implementations of the JAVA technology also forces application developers who wish to develop native code for use with JAVA applications on Microsoft's virtual machine to use Microsoft's toolkit products to do so, since only Microsoft's toolkits provide the means to develop native code compatible with the native code interfaces supported by Microsoft's virtual machine implementation. Id.

Microsoft's decisions to exclude JNI from VJ++ 6.0, SDKJ 3.0, and Windows98, and to further alter these products with incompatible language features, undermines the fundamental promise of the JAVA technology: that a program written to function on any implementation of the JAVA programming environment will correctly function across other implementations of the JAVA programming environment. Deutsch Decl., ¶¶ 8, 91-96.

C.  Step 2: Induce Developers To Create Microsoft-Dependent Applications.

Once Microsoft developed a non-conforming JAVA environment uniquely tied to its product implementations, it needed to induce independent software developers to create applications for it. To accomplish this, Microsoft had to persuade the developers and consumers who were rapidly turning to Sun's JAVA technology for its cross-platform capability that Microsoft's products would satisfy their needs, even while Microsoft secretly altered the standard JAVA environment to make it Microsoft-dependent. Armstrong Decl., Exs. 18, 20.

Microsoft's market research consistently shows that cross-platform compatibility is the single most important reason developers choose to use the JAVA environment for applications development. Armstrong Decl., Exs. 1, 10, 11; Armstrong Decl., Exs. 23. Knowing full well that the ability to create cross-platform applications was the single most important capability developers sought in JAVA tools, Microsoft purposefully concealed its platform-dependent ambitions from them. Armstrong Decl., Exs. 1, 10, 11, 16, 23. For this reason, it was important to Microsoft to alter its implementation in ways that would be imperceptible to developers, while still rendering the applications they create using Microsoft's tools dependent on Microsoft's other products, such as Microsoft's IE 4.0 or its Windows operating system. That is why John Ludwig, the Microsoft vice president in charge of JAVA development, advised his senior colleagues that, in competing with the JAVA technology, "subversion has always been our best tactic. . . . subversion is almost invariably a better tactic than a frontal assault . . . it leaves the competition confused, they don't know what to shoot at anymore . . ." Armstrong Decl., Ex. 16. That is also why Microsoft has deceptively modified the "java." methods and "java." fields in the standard "java." packages and "java." classes contained in each of the product implementations it distributes (IE 4.0, Windows98 beta, SDKJ 2.0 and 3.0, and VJ++ 6.0). Schroer Decl. ¶¶ 20-24, Exs. I, J, Schroer Supp'l Decl. 1/29/98, Ex. A, B. And that is why Microsoft continues to display Sun's JAVA Compatible logo on its non-conforming products, including its pre-release versions of VJ++ 6.0 and SDKJ 3.0, notwithstanding the Court's injunction. Armstrong Decl., Exs. 29, 30.

Remarkably, even after this Court's March 24, 1998 Order (3/24/98 Order at 17), and despite Sun's demand that Microsoft not do so (Batchelder Decl., Exs. B, C), Microsoft continues to use the "JAVA Compatible" logo to promote its SDKJ 3.0 and VJ++ 6.0 tool kit products (Armstrong Decl., ¶¶ 32-33 and Exs. 29, 30), notwithstanding the fact that these products contain the same non-conforming implementation as SDKJ 2.0.1, and fail the same JCK 1.1a test suite, in the same ways, for the same reasons as does SDKJ 2.0.1. See generally, Schroer Decl., ¶ 23, Ex. H filed in Support of Sun's Motion for Preliminary Injunction. Microsoft's continuing infringement of Sun's "JAVA Compatible" logo in connection with these non-conforming tool kit products can only be designed to deceive developers into believing that its latest toolkit products -- unlike the enjoined SDKJ 2.0 -- are authorized by Sun, pass Sun's JCK 1.1a test suite, and can be relied upon for generating programs that will operate on compatible implementations of the JAVA Technology.

To further induce independent developers to create programs for Microsoft's incompatible implementations of the JAVA technology, Microsoft has engaged in a systematic and long-running campaign of misrepresentations and false advertising. For example:

(a) Microsoft misleadingly advertises that the TLD Agreement designates Microsoft's implementation of the JAVA Technology as "the official reference implementation" for Win32-based systems platforms and browsers (Armstrong Decl., Ex. 31);

(b) Microsoft falsely advertises that "[t]he JAVA applications created with the SDKJ will run on any platform." (Armstrong Decl., Ex. 32 at 3); and

(c) Microsoft has falsely advertised and -- even after this Court's March 24, 1998 Order to the contrary -- continues to advertise its incompatible SDKJ and VJ++ 6.0 products as "JAVA Compatible." (Armstrong Decl., Exs. 29, 30.)

These public misrepresentations by Microsoft are improper, and can only have been calculated to induce developers to write programs for Microsoft's incompatible and non-conforming JAVA programming environment.

As yet another means to cause developers to use its incompatible toolkits for JAVA development, Microsoft unlawfully distributes its incompatible implementation of Sun's JAVA runtime interpreter, called the Microsoft Virtual Machine for JAVA, on a standalone basis, and requires developers who wish to display or use its "Designed for Windows95/NT" logo to promote the application programs they distribute to use Microsoft's Virtual Machine for JAVA in the products they distribute. Schroer Decl., ¶ 27, Exs. M, N. Because Microsoft dominates the market for desktop operating systems, many developers consider it essential to be able to use Microsoft's "Designed for Windows95/NT" logo to promote their products. Baratz Decl., ¶¶ 17-19. Microsoft's requirement effectively constrains developers to use Microsoft's Virtual Machine for JAVA in the programs they develop regardless of whether they would otherwise choose to do so, Baratz Decl., ¶ 19, and have no economic justification, save to constrain developers to use Microsoft's incompatible tools and implementations as the price they must pay to earn Microsoft's seal of approval. Arrow Decl. ¶ 31.

D.  Step 3: Exploit Windows Monopoly To Grab Market Share.

Above all else, Microsoft understands that the single most effective inducement it can create for software developers to write applications for its incompatible environment is to rapidly obtain a large market share of systems on which its incompatible environment is installed. Indeed, if the share of systems implementing the Microsoft-dependent environment becomes sufficiently dominant, Microsoft can exploit the incentive of developers to create applications for the environment having the largest installed base to establish its environment as the de facto standard in the market. At that point, simply by virtue of its dominant share of installations in the market, Microsoft can effectively wrest control of the JAVA technology away from Sun. Arrow Decl., ¶ 26.

Consequently, the third essential step in Microsoft's scheme to "kill cross-platform JAVA" (Armstrong Decl., Ex. 1) is the manipulation of the distribution channels for JAVA technology to expand the installed base of systems that support Microsoft's incompatible implementations. To secure a dominant share of the market for its implementations and tools, Microsoft is unlawfully exploiting its market power as a monopolist of desktop operating systems to bundle its incompatible "JAVA" environment with Windows®98. If Microsoft is allowed to distribute its non-conforming version of Sun's JAVA technology in Windows98, virtually every new PC will come pre-installed with Microsoft's incompatible version of Sun's JAVA technology.

Never one to leave things to chance, Microsoft is simultaneously acting to constrict or close the channels of distribution for JAVA compatible implementations distributed by others. Armstrong Decl., Ex. 15. For example, Microsoft's Windows distribution agreements with original equipment manufacturers ("OEMs") effectively require OEMs to distribute its Microsoft-dependent "Java" environment, in the form of Internet Explorer 4.0, in preference to any other browser. Armstrong Decl., Ex. 41. Microsoft has also entered into contracts with third parties that require such third parties exclusively to use and distribute the incompatible, Microsoft-dependent environment in the products they distribute, and to refrain from using or distributing products that implement the standard JAVA environment. As provided in one such contract, Microsoft has required its licensee to:

"(a) redistribute the Microsoft virtual machine for Java included in the Licensed Software (the "MS Java VM") as part of Company Product and not any other virtual machine;

(b) use only the Microsoft native code interfaces (J/Direct, RNI, Java/COM) that are part of the MS Java VM for any native code calling"

Armstrong Decl., Ex. 35. Such agreements effectively prevent or restrict the distribution of products other than Microsoft's that implement the JAVA technology and have no legitimate economic justification. Arrow Decl., ¶ 31.


Microsoft is abusing its monopoly power in operating systems software to defeat the cross-platform compatibility of Sun' JAVA technology, to destroy the value of that technology to Sun and its licensees, and to reap for itself the technical advantages and good will associated with that technology. Largely because of Microsoft's monopoly power in the desktop OS market, its predatory tactics threaten success. If Microsoft is permitted to bundle its incompatible implementation of Sun's JAVA technology with the Windows98 operating system, the installed base of that incompatible implementation will quickly mushroom into a de facto standard. Arrow Decl., ¶¶ 26-29.

These circumstances, coupled with Microsoft's imminent distribution of its VJ++ 6.0 and SDKJ 3.0 tool kit products, cry out for injunctive relief to preserve the integrity of the JAVA technology and the competitive market forces it creates. If Microsoft's new products, and Microsoft's other non-conforming implementations of the Java technology, are not barred from distribution, the damage to Sun's JAVA technology, to the nascent market it supports, and to each participant in that market, will quickly become irreversible. Id.; Deutsch Decl., ¶¶ 8, 91-96; see also generally LeFaivre, Sueltz, Entenmann Decls., filed in Support of Sun's Reply Motion for Preliminary Injunction, dated 2/13/98.

The irreparable harm caused by Microsoft's misconduct is far-reaching. Third party independent application developers are denied the assurance that a program written to function on one implementation of the JAVA technology will function across all implementations. Id. Third party tool developers are forced to choose between conforming to Sun's standard cross-platform technology, and conforming to Microsoft's incompatible implementations of that technology. Id. End users are denied the full range of lower-cost cross-platform compatible programs, compilers and virtual machines capable of operating compatibly in the Windows environment that would have existed but for Microsoft's incompatibilities. They are also denied the benefits of increased innovation in new technologies challenging Microsoft's existing monopoly power. Id. Perhaps most poignantly, Sun and its licensees are irreparably harmed as a result of the decrease in value of the JAVA technology to developers, tool vendors and customers, and as a result of the lost opportunity they each directly suffer.

The longer Microsoft is permitted to distribute its non-conforming products, the greater the incentive for Sun's existing and potential licensees of the JAVA technology to abandon their conformance with Sun's standard version of the technology in favor of pursuing compatibility with Microsoft's rapidly expanding base of non-conforming products.


A.  A Few Well-Established Principles Of Unfair Competition Law Mandate An Injunction Against Microsoft

3  For the Court`s convenience, a copy of this opinion is attached as Exhibit D to the Declaration of James Batchelder (Batchelder Decl.) filed herewith.

California Business and Profession Code section 17200 et seq. sets out a comprehensive statutory remedy for Microsoft's subversion of Sun's JAVA technology. As an initial matter, familiar federal standards govern Sun's entitlement to a preliminary injunction on this California law claim. United States Surgical Corp. v. Origin Medsystems, Inc., 27 U.S.P.Q.2d 1526 (N.D. Cal. 1993), 1993 WL 379579 at *1.3   Specifically, Sun is entitled to an injunction "if it can show either: (1) a likelihood of success on the merits and the possibility of irreparable injury; or (2) serious questions going to the merits and a balance of hardships tipping it its favor." Id. (citations omitted).

California's unfair competition law mandates injunctive relief against "[a]ny person performing or proposing to perform an act of unfair competition within this state." Cal. Bus. & Prof. Code § 17203. The statute broadly defines "unfair competition [to] mean and include any unlawful, unfair or fraudulent business act or practice." Id. at § 17200. The statute protects business competitors and consumers alike. Tippet v. Terich, 37 Cal. App. 4th 1517, 1536 (1995).

California courts have consistently emphasized the remedial purpose of the California statute. "The section was intentionally framed in its broad, sweeping language precisely to enable judicial tribunals to deal with the innumerable `new schemes which the fertility of man's invention would contrive.'" Barquis v. Merchants Collection Ass'n, 7 Cal. 3d 94, 112 (1972); see also Committee on Children's Television, Inc. v. General Foods Corp., 35 Cal. 3d 197, 209-10 (1983) (noting statute's intent to "enjoin wrongful business conduct in whatever context such activity might occur"). Business conduct need not be illegal to support an injunction under Section 17200. State Farm Fire & Casualty Co. v. Superior Court, 45 Cal. App. 4th 1093, 1103 (1996). Rather, the "test under section 17200 is that a practice merely be unfair." Allied Grape Growers v. Bronco Wine Co., 203 Cal. App. 3d 432, 452 (1988).

The statute's test for "unfairness" is straightforward and based on common sense. Actions or practices "`that violate[] fundamental rules of honesty and fair dealing'" also violate Section 17200. Barquis, 7 Cal.3d at 112 (citation omitted); see also Sunbelt Television, Inc. v. Jones Intercable, Inc., 795 F.Supp. 333, 338 (C.D. Cal. 1992) (same) (citing People v. Casa Blanca Convalescent Home, Inc., 159 Cal.App. 3d 509, 530; State Farm, 45 Cal. App. 4th at 1104 ("An `unfair' business practice occurs when that practice `offends an established public policy or when the practice is immoral, unethical, oppressive, unscrupulous or substantially injurious to consumers.'").

Business conduct that is "fraudulent" constitutes a separate and independent ground for a Section 17200 injunction. See State Farm, 45 Cal. App. 4th at 1102 (noting that, because Section 17200 "is disjunctive, a `business act or practice' is prohibited if it is `unfair,' or `unlawful,' or `fraudulent.'") In the Section 17200 context, "'fraudulent . . .does not refer to the common law tort of fraud.'" Saunders v. Superior Court, 27 Cal. App. 4th 832, 839 (1994). Rather, it requires only that "members of the public are likely to be deceived." Podolsky v. First Healthcare Corp., 50 Cal. App. 4th 632, 648 (1996). "A violation can be shown even if no one was actually deceived, relied upon the fraudulent practice, or sustained any damage." Id at 647-48; see also Allied Grape, 203 Cal. App. 3d at 452 (same).

4  Section 17200 also authorizes restitution of `lost moneys or properties resulting from the unfair competition.` Allied Grape, 203 Cal. App. 3d at 453.

To redress unfair practices, Section 17200 authorizes sweeping injunctive relief. "The remedial power granted under this section is `extraordinarily broad.'" Hewlett v. Squaw Valley Ski Corp., 54 Cal. App. 4th 499, 540 (1997) (citation omitted). "Injunctive relief `may be as wide and diversified as the means employed in perpetration of the wrongdoing.'" Id. Consequently, Section 17200 gives this Court wide discretion "to make orders to prevent such activities from occurring in the future," id., and to enjoin "past activity and out-of-state activity," Stop Youth Addiction, 17 Cal. 4th 553 at 570 (citing Bus. & Prof. Code § 17203) (injunction reaches any "person who engages, has engaged, or proposes to engage in unfair competition"). The statute's remedies are cumulative to and independent of the remedies or penalties available under any other law. Hewlett, 54 Cal. App. 4th at 520; State Farm, 45 Cal. App. 4th at 1093.4

B.  Microsoft Seeks To Destroy The Value Of Sun's JAVA Technology

At its core, Microsoft has denied Sun the fundamental benefit of its distribution rights under the TLDA. As discussed above, Sun expressly entered into the TLDA to obtain the benefits of Microsoft's unrivalled capacity for ubiquitous distribution of Sun's JAVA technology. As a matter of basic contract law, Microsoft was obligated not only to discharge all of its express obligations in the TLDA, but also to satisfy its obligations of good faith and fair dealing not to destroy or injure Sun's rights to the fruits of the TLDA. See Sutherland v. Barclays American/Mortgage Corp., 53 Cal. App. 4th 299, 314 (1997) ("Every contract imposes upon each party a duty of good faith and fair dealing in its performance and its enforcement'"); Locke v. Warner Bros., Inc., 57 Cal. App. 4th 354, 363 (1997) ("neither party shall do anything which will have the effect of destroying or injuring the right of the other party to receive the fruits of the contract.'"). Instead, Microsoft breached the express letter of the TLDA and its fundamental purpose by distributing its own non-conforming implementation of the JAVA technology. On this basis alone, Microsoft should be enjoined under Section 17200 from making any further distributions. See State Farm, 45 Cal. App. 4th 1093 at 1105 (breach of duty of good faith and fair dealing supports injunction based on unfair competition finding).

Dated: May 14, 1998


            Lloyd R. Day, Jr.

Attorneys for Plaintiff SUN MICROSYSTEMS, INC.


Subscriptions | FAQ | Notices & Disclaimers | Privacy Policy
Copyright 1998-2008 David Carney, dba Tech Law Journal. All rights reserved.
Phone: 202-364-8882. P.O. Box 4851, Washington DC, 20008.