U.S. vs. Microsoft WebConnect Network3Com Layer 3 Switching
Navigation Bar
Navigation Bar

Johns Hopkins University
Partners:
 Latest Story
 Trial Basics
 Case Timeline
 Key Players
Trial Archive
 Documents

Bag The Best Bargains Online at Discover ShopCenter
Crest Cleaners
Apartments.com
 
court updates
Check frequently for dispatches from Post reporter Rajiv Chandrasekaran and for all the Post coverage.

Sun-Microsoft Trial:
Preliminary Injunction Order

On Tuesday, November 17, a federal judge in San Jose issued a preliminary injunction order backing Java technology claims by Sun Microsoystems and gave Microsoft 90 days to modify its Windows 98 operating system or pull it from the market. The full text of the order is below:

                 IN THE UNITED STATES DISTRICT COURT
               FOR THE NORTHERN DISTRICT OF CALIFORNIA
SUN MICROSYSTEMS, INC.,                   NO. C 97-20884 RMW(PVT)
a Delaware Corporation,
                                          ORDER RE SUN'S MOTIONS FOR
        Plaintiff,                        PRELIMINARY INJUNCTION AGAINST
                                          MICROSOFT
        V.
MICROSOFT CORPORATION,
a Washington Corporation,                 [Re Docket Nos. 258, 265, 632]
        Defendant.
Plaintiff's motions for preliminary injunctive relief based on 17 U.S.C. 
section 502 and section 17200 of the California Business and Professions 
Code were heard on September 8-10,  1998.  The court has read the moving 
and responding papers, considered the witness testimony and heard the 
oral argument of counsel.  For the reasons set forth below, the court 
grants in part plaintiff s motions for preliminary injunctive relief.
                            I.  BACKGROUND
According to Sun Microsystems, Inc. ("Sun"), Microsoft Corporation's
("Microsoft") Internet Explorer 4.0 ("IE 4.0"), Software Development
Kit for Java ("SDKJ") versions 2.0 and 3.0, Visual J++ 6.0 ("VJ 6.0")
and Windows98 products infringe Sun's copyrights for the source code
embodying the Java Technology.  More specifically, Sun asserts that
Microsoft's license to distribute products which use Sun's copyrighted
source code depends on compliance with Sun's applicable test suite for
the version of the technology which Microsoft's products incorporate.
Sun submits that the above-mentioned products fail to pass the
applicable compatibility test suite and that, therefore, Microsoft's
distribution of these products infringes Sun's copyrights.
Sun now seeks to immediately enjoin Microsoft from reproducing,
distributing or selling SDKJ 2.0 and 3.0, and VJ 6.0, unless and until
Microsoft has demonstrated that these products successfully pass Sun's
compatibility test suite and comply with all other compatibility and
certification requirements provided for in the Technology License and
Development Agreement between Sun and Microsoft.  Sun also challenges
Microsoft's right to distribute IE 4.0 and Windows98 in their current
configurations.  However, Sun's proposed injunction as to these
products would allow Microsoft ninety days to modify IE 4.0 and
Windows98 such that these products also pass Sun's compatibility test
suite.
A.      SUN'S JAVA TECHNOLOGY
Sun's Java Technology is a collection of programming components that
create a standard, platform-independent programming and runtime
environment.  Sun's Java Technology has two basic elements: the Java
programming environment and the Java runtime environment.
The Java programming environment allows software developers to create
a single version of program code that is capable of running on any
platform which possesses a compatible implementation of the Java
runtime environment.  The Java programming environment comprises (1)
Sun's specification for the Java language, (2) Sun's specification for
the Java class libraries and (3) the Java compiler.
The Java runtime environment comprises the Java class libraries and
the Java runtime interpreter.  A system platform or browser program
that implements the Java runtime environment can execute application
programs developed using the Java programming environment.
Sun's Java programming and runtime environments are available to
software developers in the form of the Java Developer's Kit ("JDK")
which is a tool embodying the language, class libraries and the
compiler.  Sun also licenses the source code for its JDK software to
systems and browser manufacturers (e.g., Apple, IBM, Microsoft,
Netscape, etc.) to enable them to incorporate the Java Technology in
their own operating systems, browsers and software development tool
kits.
B.      LICENSE AGREEMENT BETWEEN SUN AND MICROSOFT
The negotiations between Sun and Microsoft which resulted in the
Technology License and Distribution Agreement ("TLDA") comprised
several rounds of telephone conferences, e-mail communications and
face-to-face negotiations.  On December 6, 1995, Sun and Microsoft
executed a Letter of Intent ("LOI") setting forth the general subject
matter and basic terms of the agreement to be negotiated.  See McMahon
Decl.  Ex. 36.  During the negotiations of the LOI, Sun and Microsoft
contemplated that any license agreement would grant Microsoft the
right to include the Java Technology only in.its Internet browsers
and.software development tools.  See Baratz Reply Decl. ¶ 27;
Patch Reply Decl. ¶ 9.[1] However, the proposed agreement was
soon expanded to encompass Microsoft's use of the Java Technology in
operating systems.  
Near the end of February 1996, the intensity and frequency of the
negotiations resulting in the TLDA increased.  Microsoft planned a
Professional Developers Conference for mid-March 1996 during which it
would announce the details of Microsoft's Internet strategy to
technical system developers.  Muglia Decl.  ¶ 12.  This
conference marked a deadline for Microsoft's contract negotiations
with Sun.  Id.  Even on the day before the conference, Microsoft and
Sun had not finalized many material terms and details of the
agreement.  Microsoft's negotiators flew down to Sun's offices in
Cupertino to begin discussions at 10:00 a.m. on Monday morning, March
11, 1996.  Muglia Decl.  ¶ 15.  After almost 19 hours of
negotiations, Sun and Microsoft executed the final agreement at 4:45
a.m. on March 12, 1996.[2] Id.  Less than fours hours later, Microsoft
announced the execution of the TLDA at the conference.  Id.  ¶
17.  
Pursuant to the TLDA, Sun granted to Microsoft a nonexclusive
license "under the Intellectual Property Rights of SUN to make,
access, use, copy, view, display, modify, adapt, and create Derivative
Works of the Technology in Source Code form for the purposes of
developing, compiling to binary form and supporting Products.  "
Batchelder Decl.  Ex.  C (TLDA § 2. 1 (a)).  Sun also granted
Microsoft a license to "make, use, import, reproduce, license, rent,
lease, offer to sell, sell or otherwise distribute to end users as
part of a Product or an upgrade to a Product, the Technology and
Derivative Works thereof in binary form."  TLDA § 2.2(a)(iii).
However, as to browser and operating systems, the TLDA also provides
that each new version of any "Product" that incorporates Sun's Java
Technology must pass Sun's compatibility test suite prior to its
commercial distribution.  TLDA §§ 2.6(a)(iv), (vi).  The
TLDA defines the "Java Test Suite" as "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." TLDA § 1. 1 5. The AAPI or Applet Application
Programming Interface is defined 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.
TLDA § 1. 1. The TLDA permits Microsoft to extend or make
additions to the AAPI, referred to as "Value Added Open Packages" or
"VAOPs." TLDA §§ 1.28, 2.8(a).  However, the TLDA restricts
Microsoft to a specific naming convention for any VAOPs.  See TLDA
§ 2.8(d). Additionally, the TLDA proscribes any modification or
addition to the names of the public Java classes "whose names begin
with 'Java', 'COM.sun' or their equivalents."  TLDA § 2.8(d).
Microsoft's products which include Java compilers are subject to a
slightly different compliance standard.  Any Microsoft product having
a Java language compiler "shall include a mode which a Tool Customer
may use to permit such Product to pass the Java Language Test Suite[3]
that accompanied the Significant Upgrade." TLDA §
2.6(b)(iv). Microsoft argues that this provision allows it to develop
compiler directives and keyword extensions which optimize the Java
Technology for software developers who wish to write applications
solely for the Win32 platform, as long as the compiler includes a mode
that disables these compiler directives and extensions.  See Muglia
Decl.  ¶¶ 5, 9, 1 1.  Sun, on the other hand, argues that
section 2.6(b)(iv) only allows Microsoft to include in its compilers
the ability to compile code for prior compatible versions of the Java
Technology that were incorporated in earlier products.  See Baratz
Reply Decl.  ¶¶ 15, 18-21; Patch Reply Decl.  ¶¶
62-68.  Sun also avers that Microsoft never discussed the possibility
of extending the Java, language.. Patch Reply Decl... ¶ 68; but
see Muglia Decl.  ¶ 11.
C.      ASSERTED INCOMPATIBILITIES OF MICROSOFT'S PRODUCTS
Sun contends that Microsoft's Windows98 and IE 4.0 products fail to
pass the JNI tests of Sun's JCK 1. 1 a test suite.  Schroer Supp.
Decl.  ¶¶ 5, 6 & Ex.  A. Microsoft's SDKJ 2.02 and 3.0 and
VJ 6.0 software development tools, according to Sun, do not support
Sun's JNI and RMI technology and, therefore, fail (1) Sun's JNI tests,
and (2) St&s RMI Compiler tests.  Sun also contends that Microsoft's
use of incompatible keywords and compiler directives cause its
compiler to generate output which fails to properly execute on the JDK
1.1 virtual machine.  See Schroer Supp.  Decl. ¶¶ 7, 8, 9 &
Ex.  A. Sun also contends that SDKJ 2.02 fails two required compiler
tests.  Schroer Supp. Decl.  ¶ 7(d).  
Sun's original testing indicated that Microsoft's products generated
107 "Signature Test" failures.  However, this testing was performed on
so-called "beta- versions" of Microsoft's products.  Sun no longer
asserts that Microsoft's products generate these Signature Test
errors.
1. RMI Compiler Tests
As to the RMI test failures, Microsoft argues that Sun's RMI Compiler
or "rmic" constitutes Supplemental Java Classes under the TLDA.  See
TLDA §§ 1.23, 2.7(a). Microsoft notes that the TLDA does not
require it to include Supplemental Java Classes in its products.
Rather, Microsoft must only post Supplemental Java Classes on its
website to satisfy its obligations under the TLDA.  Sun appears to
agree with this contention as its reply brief offers no opposing
argument.
2. SDKJ 2.02
As to the two compiler test errors generated by SDKJ 2.02, Microsoft
asserts that one of these tests (the "601 test") is in fact passed and
that the failure of the other test (the "2003 test") resulted from a
program bug which was fixed in SDKJ 3.0.  Golde Decl.  ¶¶
2-4.  Microsoft submits that it will fix this bug in SDKJ 2.02.
Id. ¶ 4.  Sun maintains, however, that Microsoft's claim that
SDKJ 2.02 passed the 601 test is most likely based upon an improper
execution of the test.  See Schroer Reply Decl. ¶¶ 26-29.
3. Java Native Interface ("JNI")
Since the Java Technology does not have all of the functionality which
a software developer may require, Sun developed a native method
interface to the Java runtime interpreter.  See Deutsch Decl.  ¶
75.  In Sun's JDK 1. I product, this native method interface is
called the Java native in terrace or "JNI." According to Sun, JNI is
an upgrade or enhancement to the native method interface (originally
called "nmi") in the JDK 1.0 version of the Java Technology originally
shipped to Microsoft.  Sueltz Decl. ¶ 7. When functionality not
available from the Java Technology is needed, the software developer
will write part of the application in the Java language and the
remaining portion in a native language supported by the particular
platform for which the program is written.  This native language, such
as C or C++, is platform-dependent; hence, any program written in the
Java language which invokes a native method is also platform-
dependent.
According to Sun, JNI is a public application programming interface to
the Java runtime interpreter.  Lindholm Reply Decl.  ¶ 4. JNI
"links Java code to native code through the Java virtual machine, and
provides native code with access to the Java Virtual Machine."
Id. ¶ 3.  JNI allows a Java/native application to run on any
Java-compatible virtual machine.  Gosling Decl.  ¶ 15; Lindholm
Reply Decl. ¶ 3.  
Microsoft's runtime interpreters or virtual machines do not support
Sun's JNI.  Rather, Microsoft's runtime interpreters support native
method interfaces called RNI, Java/COM and J/Direct.  Java/COM and
J/Direct allow software developers to call to Windows-specific native
functionality when using Microsoft's software development toolkits,
such as SDKJ or VJ 6.0.  Software applications that use RNI, J/Direct
or Java/COM, says Sun, will not run on Java runtime interpreters
supporting only Sun's JNI.  See Gosling Decl.  ¶ 16.  This
incompatibility, according to Sun, "fragments" the Java programming
environment for the Windows platform.  Id.  ¶ 17.  Furthermore,
Sun contends that Java/native applications which use RNI, J/Direct or
Java/COM only run properly on Microsoft's virtual machine.  Id.
¶¶ 16, 17.
Sun argues that JNI clearly falls within Microsoft's compatibility
obligations under the TLDA.  Sun submits that the TLDA permits Sun to
test for compliance with Sun's specification of the AAPI, including
upgrades thereto.  Sun reasons that since JNI is a programming
interface to the Java Runtime Interpreter which itself constitutes
part of the Java Applet Environment, it falls within Microsoft's
compliance obligations.  See Sueltz Decl.  ¶ 7; Day Decl.  Ex.  D
(Silverberg Depo. at 38:3-10).  
Microsoft, on the other hand, submits that the TLDA does not require
its products to support JNI or pass any compatibility tests relating
thereto.  According to Microsoft, the issue is whether Sun's JNI is
part of the AAPI and, more specifically, whether JNI is part of "the
public application programming interface to the Java Applet
Environment (JAE) reflected in the Technology as identified in Exhibit
A."  TLDA § 1. 1 (a); Opposition at 9.  Microsoft contends that,
as evidenced by section 1.2, section 1. 1 (a) of the TLDA was only
intended to define Java applet interfaces and that JNI does not fit
this definition.  See TLDA § 1.2. As Microsoft explains, JNI is
an interface available to C or C++ programmers which allows a native
program to invoke a Java virtual machine and provides a connection
mechanism for programmers to target when writing native code.  Huhns
Decl.  ¶ 40; Deutsch Decl.  Ex. 28 (Java Native Interface
Specification at 1).  Indeed, Microsoft asserts that it specifically
rejected Sun's proposed contract language granting Sun control of the
native interfaces to Microsoft's "Java Reference Implementation."
McMahon Decl.  Ex. 17 (Muglia Depo. at 117:14-118:10).
4. Keyword Extensions and Compiler Directives
Microsoft contends that the TLDA authorizes its specific
implementation of keyword extensions and compiler directives in its
Java-based products.  Microsoft developed its compiler directives to
provide direct, more efficient calling of native functionality which
already exists on the Windows platform.  See Gosling Decl.  ¶ 16.
The "@dll" and "@com" directives support Microsoft's native method
interfaces called "J/Direct" and "Java/COM," respectively.  These
directives allow a software developer to access non-Java code in
"dynamic link libraries" and "COM libraries," respectively.  Lee Decl.
¶ 37.  The "@security" directive disables certain security
features implemented on Microsoft's virtual machine.  Id.  A software
developer who wishes to use these compiler directives inserts them
into source code as documentation comments.  See Lee Decl.  ¶ 43.
Usually, a compiler ignores information in documentation comments;
however, in its extended mode, Microsoft's compiler- recognizes the
@dll, @corn, and @security directives.[4] 
Microsoft's keyword extensions, "multicast" and "delegate," are used
as part of a class declaration to create method pointers and were
designed to handle the problem of "event handling." See Deutsch Decl.
¶ 34, Exs. 3, 4; Lee Decl.  ¶ 37.  When Microsoft's compiler
in its extended mode encounters the "delegate" and "multicast"
keywords, it generates class files that extend the "delegate" and
"multicast" classes.  The resulting class file has attributes that
reference the two classes developed by Microsoft
("com.ms.lang.Delegate" and "com.ms.lang.MulticastDelegate"). See
Deutsch Decl.  ¶ 58, Ex. 2 (Delegates in Visual J++ 6.0 at 1).
If a particular virtual machine, such as Sun's, does not implement
these classes, compiled code which references them will not run on
that virtual machine.  Deutsch Decl.  Ex. 6 (DeMichillie Depo. at
61:8-63:14).  Microsoft's delegate class is implemented natively by
the Microsoft Virtual Machine, rather than being implemented as
separate Java classes.  DeMichillie Depo. at 62:10-22.
As to Microsoft's allegedly incompatible compiler, Microsoft points
out that its compiler has an "enhanced mode in which the user has
available three families of compiler directives and two keywords."
Opposition at 3. Microsoft also submits that SDKJ 2.0 and 3.0 as well
as VJ 6.0 allow the software developer to turn this enhanced mode on
and off as contemplated by section 2.6(b)(iv) of the TLDA.  Huhns
Decl.  ¶ 58.  Moreover, Microsoft asserts that its compiler
executes properly regardless of whether the enhanced mode is employed.
Lee Decl.  ¶¶ 14, 15; Huhns Decl.  ¶¶ 59, 60.
Further, Microsoft contends that use of its compiler directives in
source code does not result in errors even when Sun's compiler
compiles that source code.  Lee Decl.  ¶ 15.  However, Microsoft
does admit that a software.  developer's use of Microsoft,s keyword
extensions (,"delegate" and "multicast") in its source code will
generate errors with a non-Microsoft compiler.  Lee Decl. ¶ 16.
Microsoft asserts, however, that this would be patently obvious to
almost any software programmer who would simply avoid these extensions
when writing platform-independent code.  Lee Decl.  ¶¶ 8,
13, 16.
According to Sun, the mode switch in Microsoft's compiler does not
allow generation of class files which pass the JCK l.la test suite.
See Hankinson Decl.¶¶7,8.  However,this contention only appears
to be valid when the source code being compiled includes Microsoft's
language extensions.  See id.  ¶¶ 37, 38.  In any event, Sun
asserts that Microsoft's use of compiler directives and keyword
extensions exceeds the scope of the license granted in the TLDA.
As to Microsoft's keyword extensions ("multicast" and "delegate"), the
evidence indicates that Microsoft's compiler, when it encounters these
extensions, generates output in a class file that is byte code
compatible; however, the compiled instructions cause the virtual
machine to look for classes which only Microsoft's virtual machine
possesses.  See Deutsch Decl. ¶ 58; Deutsch Reply Decl.  ¶
6. Microsoft's compiler directives, on the other hand, cause the
Microsoft compiler to insert non-standard attributes into the
resulting binary files.  Deutsch Reply Decl.  ¶ 9. According to
Microsoft, this does not violate the Java Language Specification or
the Java Virtual Machine Specification since the "semantics of class
and interface types" remain unaffected and any Java runtime ignores
attributes that it does not recognize.  Lee Decl.  ¶¶ 40-42.
In any event, source code containing Microsoft's compiler directives,
when compiled using Microsoft's compiler and run on Sun's JDK 1. 1
virtual machine, generates an error message, rather than executing the
desired native function.  For example, with respect to the "@dll"
compiler directive, a non-Microsoft virtual machine will ignore the
attribute created by use of this compiler directive and will
consequently fail to invoke the associated native DLL function thereby
causing the virtual machine to generate an error message.  See
September 9, 1998 Hearing Transcript (Gosling Test. at 250:20-252:24,
255:2-15); see also September 8, 1998 Hearing Transcript (Lee Test. at
133:5-135:21); Hankinson Decl. ¶ 36.
D.      MICROSOFT'S ALLEGED UNFAIR COMPETITION
Sun's motion for preliminary injunctive relief based on unfair
competition under section 17200 of the California Business and
Professions-Code is primarily based on Microsoft's alleged scheme to
neutralize the threat that Sun's Java Technology apparently poses to
Microsoft's continued dominance of the operating systems market.
According to Sun, Microsoft's plan is to leverage its dominant market
share in operating systems to "pollute" the market for the Java
Technology with non-compliant browsers, operating systems and software
development tools.  Sun fears that the resulting installed base of
Microsoft's incompatible implementations of the Java Technology will
become the defacto standard.  Arrow Decl. ¶¶ 26-29.  
In addition to complaining about the alleged purposeful injection of
Java-incompatible products into the market, Sun challenges Microsoft's
licensing practices relating to its implementations of the Java
Technology.  Specifically, Sun contends that Microsoft's license
agreements with re- sellers and developers restrict them to developing
software only for Microsoft's version of the Java Technology.  See
Armstrong Reply Decl.  Ex. 15 ("[Licensee] shall ...  redistribute the
Microsoft virtual machine for Java ... and not any other virtual
machine; ... use only the Microsoft native code interface that is part
of the MS Java VM for any native code calling."); Ex. 22 ("[Licensee]
shall . . .. 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 with respect to the such interfaces."); see also Armstrong
Decl.  Ex. 35.  Microsoft, on the other hand, states that its current
licensing program does not require exclusive use of Microsoft's
virtual machine or methods of calling native code.  Further, it
submits that its prior license agreements which do require exclusive
distribution of Microsoft's virtual machine are no longer "in force."
See McMahon Decl.  Ex. 19 (Plamondon Depo. at 40:6-41:19).  
Sun also alleges that Microsoft has made certain misrepresentations in
its effort to induce software developers to create programs written
for Microsoft's incompatible implementation of the Java Technology.
Unfair Comp.  Motion at 19.  According to Sun, Microsoft misleadingly
advertises that the TLDA designates Microsoft's implementation the
"official reference implementation" of the Java Technology for
Win32-based systems.  Armstrong Decl.  Ex. 31. Sun also objects to
Microsoft's advertising that "Java applications created with the SDKJ
will run on any platform." Armstrong Decl.  Ex. 32 at 3. Sun further
decries Microsoft's designation of SDKJ and VJ 6.0 as "Java
Compatible." Armstrong Decl.  Exs. 29, 30. Microsoft argues that these
statements are true and not likely to mislead software developers.
Microsoft's software development tools, according to Microsoft,
include a mode that allows a software developer to generate Java
compatible code.  Microsoft points out that its use of language
extensions is well publicized and is no surprise to software
developers.  See Hejlsberg Decl.  Exs.  A, B.  
E. SUN's REQUESTED RELIEF
 As discussed above, Sun seeks an order enjoining Microsoft from
reproducing, distributing or selling IE 4.0, SDKJ 2.0 and 3.0. VJ 6.0
and Windows98, unless and until Microsoft has demonstrated that these
products successfully pass Sun's compatibility test suite and comply
with all other compatibility and certification requirements provided
for in the TLDA.  Sun, however, recognizes the harm to innocent third
parties which the requested relief may cause.  Sun's Copyright Reply
at 15.  As to Windows98 and IE 4.0, Sun requests an order enjoining
Microsoft from distributing copies of these products ninety days after
entry of this order unless each product include a Java runtime
interpreter that passes the JCK 1.1a test suite.  Sun also
contemplates an extension to this ninety-day period if Microsoft can
demonstrate good cause for it.  As to Microsoft's development tools
(VJ 6.0 and SDKJ 2.0 and 3.0), Sun seeks an order immediately
enjoining Microsoft's distribution of these products unless and until
they successfully pass Sun's JNI and Compiler Output Requirement
tests.
F.      MICROSOFT'S MOTION TO STRIKE SUN's NEW AND CHANGED THEORIES
Microsoft moves to strike certain arguments and evidence which, it
alleges, were first presented in Sun's reply briefs.  Microsoft
explains that Sun's reply papers contain arguments and evidence vastly
different from those asserted by Sun in its initial moving papers.
For example, in its initial moving papers, Sun primarily relied on the
failure of Microsoft's products to pass Sun's Signature Tests.  Sun's
motion, says Microsoft, contained only minor references to JNI.  In
its reply, Sun has, according to Microsoft, shifted its main emphasis
to Microsoft's allegedly wrongful failure to support JNI and
Microsoft's use of compiler directives and keyword extensions.
Microsoft now moves to strike these "new" arguments and supporting
evidence raised by Sun.  
The court denies Microsoft's motion to strike Sun's allegedly new and
changed theories as Microsoft has failed to demonstrate any unfair
surprise or prejudice.  Microsoft's oppositions to Sun' motions and
its presentation to the court during the technology tutorial
demonstrate that Microsoft was fully apprised of the main issues in
Sun's motions.  Moreover, Microsoft had ample opportunity to mitigate
any prejudice it now claims during the two-day evidentiary hearing
conducted pursuant to its request.  As to JNI, Sun's initial moving
papers clearly assert that the TLDA requires Microsoft's products to
support JNI.  See Copyright Motion at 9:4-5; Unfair Comp.  Motion at
16:26-18:5; see also Deutsch Decl.  ¶¶ 5-8, 74-89.  In
addition, Sun's argument as to why the TLDA requires support for JNI
is the same as that advanced by Sun it its first motion for
preliminary injunctive relief.  See March 24, 1998 Order at 16:15-27.
As to Microsoft's compiler directives and keyword extensions, Sun
provided Microsoft with sufficient notice of Sun's challenge.  See
Second Amended Complaint (May 12, 1998) ¶ 83; Schroer June 17,
1998 Decl.  ¶¶ 5(a)-(c), 11(e), 12(f), 13(f).  Sun's
arguments and evidence submitted in reply respond in the main to
Microsoft's argument that the "mode" language in section 2.6(b)(iv) of
the TLDA allows Microsoft to create language extensions.  
         II. LEGAL STANDARD FOR PRELIMINARY INJUNCTIVE RELIEF
A plaintiff seeking preliminary injunctive relief must demonstrate
"either a likelihood of success on the merits and the possibility of
irreparable injury, or that serious questions going to the merits were
raised and the balance of hardships tips sharply in its favor." Sega
Enterprises Ltd. v.  Accolade.  Inc., 977 F.2d 1510, 1517 (9th
Cir. 1992) (citations omitted).  The alternatives in the above
standard represent "extremes of a single continuum," rather than two
separate tests.  Benda v. Grand Lodge of Int'l Ass'n of Machinists &
Aerospace Workers, 584 F.2d 308, 315 (9th Cir.  1978).  A "serious
question" is one to which the movant has a "fair chance of success on
the merits."Sierra On-Line.  Inc. v. Phoenix Software.  Inc., 739 F.2d
1415, 1421 (9th Cir. 1984).  Generally, evaluation of the relative
hardships of the parties should precede an analysis of the "likelihood
of success on the merits" since the balance of hardships determines
how strong and substantial the plaintiff s showing must be.  See
Alaska v. Native Village of Venetie, 856 F.2d 1384, 1389 (9th
Cir. 1988).  Where a public interest is involved, the court should
also consider if the grant of a preliminary injunction favors the
public interest.  Westlands Water Dist. v. Natural Resources Defense
Council, 43 F.3d 457, 459 (9th Cir. 1994).  
The Copyright Act specifically provides for temporary and permanent
injunctive relief against infringers. 17 U.S.C. § 502(a).  In the
copyright infringement context, a plaintiff need only establish a
reasonable likelihood of success to support a district court's grant
of a preliminary injunction.  Johnson Controls v. Phoenix Controls
Systems, 886 F.2d 1173, 1174 (9th Cir. 1989) ("showing of a reasonable
likelihood of success on the merits raises a presumption of
irreparable harm.").  
    III.  ANALYSIS A. LIKELIHOOD OF SUCCESS ON THE MERITS OF SUN'S
                     COPYRIGHT INFRINGEMENT CLAIM
To establish copyright infringement, a plaintiff must prove (1)
ownership of a valid copyright and (2) copying of expression protected
by its copyright.  Triad Systems Corp. v.  Southeastern Express Co.,
64 F.3d 1330, 1335 (9th Cir. 1995).
1. Ownership of a Valid Copyrights 
Sun's certificates of copyright registration raise a rebuttable
presumption that Sun owns valid copyrights in the JDK source code. 17
U.S.C. § 410(c); Entertainment Research v. Genesis Creative
Group, 122 F.3d 1211, 1217 (9th Cir. 1997); see generally Crean
Decl. and Crean Supp.  Decl.  Microsoft attempts to rebut the
presumption of validity by arguing that certain "chunks" of the JDK
1. 1 source code were contributed by third-party sources.  However,
Sun submits evidence indicating that less than ten percent of the
source code files for JDK 1. 1 potentially contain third-party code.
Lindholm Reply Decl. ¶ 44.  Moreover, Sun's certificates of
registration indicate that the registered source code incorporates
third-party computer programs.  See Crean Decl.  Exs.  D, E; Crean
Supp.  Decl.  Exs.  A. B, C.  Microsoft cites no authority indicating
that the acknowledged presence of third-party code in copyrighted
software is sufficient to rebut the presumption of validity.  
2. Copying of Expression Protected by Sun's Copyrights
Microsoft does not dispute that it has copied Sun's JDK 1.1 product.
Microsoft contends, however, that Sun has not met its burden of
demonstrating that its copyright extends to material copied by
Microsoft given the presence of third-party code.  However, Sun
submits evidence that shows Microsoft's copying of source code files
original to Sun.  See Deutsch Reply Decl, ¶¶ 30-35.
3. Whether Microsoft's Use of Sun's Copyrighted Source Code is
Authorized
Sun argues that Microsoft's IE 4.0, SDKJ 2.0 and 3.0, VJ 6.0 and
Windows98 fail to pass Sun's compatibility test suite and that,
therefore, distribution of these products falls outside the scope of
the license granted to Microsoft in the TLDA.  Microsoft, on the other
hand, contends that the TLDA carves out the tests to be passed and
that Microsoft's products pass these tests.  
A licensee infringes the licensor's copyright if it exceeds the scope
of the license.  S.O.S., Inc. v. Payday, Inc., 886 F.2d 1081, 1087
(9th Cir. 1989).  "[C]opyright licenses are assumed to prohibit any
use not authorized."  Id. at 1088.  Therefore, the affirmative grants
of the TLDA determine the scope of Microsoft's license.  See Cohen
v. Paramount Pictures Corp., 845 F.2d 851, 853-54 (9th Cir. 1988) ("[A
copyright] license must be construed in accordance with the purpose
underlying federal copyright law.").  
Here, the issue is whether Microsoft's use of the Java Technology
exceeds the scope of its license.  Section 2.2(a)(iii) grants
Microsoft the right to distribute the Java Technology and "Derivative
Works thereof " "as part of a Product." Section 2.6(a)(vi) of the TLDA
limits this distribution right to "Products" which pass Sun's relevant
test suite.  Therefore, the contractual issues distill down to (1)
whether the TLDA requires Microsoft to support JNI and (2) whether the
TLDA allows Microsoft to incorporate keyword extensions and compiler
directives into its products.  
a. Whether the TLDA Requires Microsoft to support JNI
Sun has demonstrated a reasonable likelihood of success on its claim
that the TLDA requires compliance with Sun's specifications for
JNI. Under the TLDA, the "Java Test Suite" means "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."  TLDA § 1. 15. The TLDA expressly
defines the AAPI as, in part, "the public application programming
interface to the Java Applet Environment (JAE) reflected in the
Technology as identified in Exhibit A [to the TLDA] as modified by Sun
during, the term of this agreement."  TLDA § 1. 1. Exhibit A
states that the Java Applet Environment consists of certain Java
Classes and the Java Runtime Interpreter.  "Technology" comprises the
"Java Runtime Interpreter, Java Classes, Supplemental Java Classes,
Java Compiler, and all Upgrades." TLDA § 1.25.  According to Sun,
JNI is an upgraded, public application programming interface to the
Java Runtime Interpreter which is intended to allow a Java/native
application to run on all virtual machines, designed for a specific
platform.  See Sueltz Decl.  ¶ 7; Gosling Decl.  ¶ 15;
Deutsch Decl.  Ex. 28 (JNI Specification at 1).  Microsoft appears to
agree that JNI is an application programming interface to the virtual
machine.  See Huhns Decl.  ¶ 40.  Day Decl.  Ex.  D (Silverberg
Depo. at 38:3-10); see also Deutsch Decl.  Ex.  21.  Sun also points
out that the TLDA defines native code interfaces as interfaces to the
virtual machine.  TLDA § 2.9(e). It follows that, since JNI is an
application programming interface to the Java Runtime Interpreter
which, according to Exhibit A of the TLDA, is part of the Java Applet
Environment, JNI falls within Microsoft's compliance obligations under
section 2.6 of the TLDA.  
The Java Language Specification and Java Virtual Machine Specification
further support Sun's contention as both contemplate invoking native
methods.  See Lindholm Reply Decl.  ¶¶ 14-19; Java Virtual
Machine Specification ("JVMSpec.") at 104, Table 4.4.  Sun's
specifications indicate that the functionality of the Java runtime
interpreter includes the ability to call native code.  The Java
Virtual Machine Instruction Set includes the terms "invokeinterface,"
"invokespecial," "invokestatic" and "invokevirtual" which cause native
code to be loaded and linked to the virtual machine.  JVMSpec. at
258-69; Lindholm Reply Decl.  ¶ 14.  Additionally, the Java
Language Specification environment and native code is particular to a
specific platform (and often written for a specific software
application), an interface is required to allow communication between
the Java virtual machine and the native code.  See Lindholm Reply
Decl.  ¶ 15.
Other provisions of the TLDA support the court's interpretation.
Section 2.9(b) of the TLDA requires that Microsoft's runtime
interpreter "include the necessary Source Code to implement the
functionality of the Java Runtime Interpreter."  Accordingly, the TLDA
requires Microsoft's runtime interpreter to implement the
functionality encompassed by JNI, Sun's native interface to the Java
Runtime Interpreter.  Section 2.9(f) also contemplates Sun's testing
of the interfaces to the "Reference Implementation VM." See TLDA
§ 2.9(f) ("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.").
Furthermore, the negotiation history of the TLDA, as evidenced by the
draft agreements, undermines Microsoft's contention that exclusive
control over the programming interfaces to its runtime interpreter was
a "deal breaker."  Specifically, Microsoft's proposed draft of March
10, 1996 appears to allow Sun to test Microsoft's invocation interface
to the runtime interpreter.  See March 10, 1996 Draft § 1.9
("'Invocation Interface' means the public interface to the Reference
Implementation VM ... including any Derivative Works or Independent
Works thereof which meet the compatibility requirements set forth in
Section 2.6 of this Agreement."). The invocation interface allows a
native code program to invoke the Java runtime environment.  See
September 8, 1998 Hearing Transcript (Muglia Test. at 31:1-5).  The
invocation interface, as defined in the March 10 draft agreement and
previous drafts, relates directly to one of the two aspects of JNI.
As discussed above, JNI comprises two sets of functionality: 1) an
interface that allows Java code to invoke native methods, and 2) a set
of native interfaces which allows a native program to invoke the Java
runtime environment.
Microsoft argues that JNI is not part of the AAPI since, according to
Microsoft, AAPI or "Applet API" only refers to the interface to the
Java Classes, which are all that Applets require in order to run
properly.  See TLDA Ex.  A § I(A).  Microsoft relies on the
definition of "Applet" in the TLDA and Sun's definitions of the "Java
Applet API" in documentation to JDK 1.0 and a so-called Sun "White
Paper" to support its interpretation.  See Huhns Decl.  Exs.  B, C;
see also TLDA § 1.2 ("'Applet means a program written in the Java
Language which (i) runs on the AAPI and (ii) consists of Java byte
codes executable by the Java Runtime Interpreter (but does not include
or incorporate the Java Runtime Interpreter, or Java
Classes)."). Microsoft further asserts that its definition corresponds
to the meaning of the term as understood by both Sun and Microsoft. in
the negotiations resulting in the TLDA.  McMahon Decl. Ex.  17 (Muglia
Depo. at 108:23-109:17), Ex. 13 (Joy Depo. at 277:11-278:3).  However,
Microsoft ignores the fact that AAPI, regardless of how it is defined
outside the TLDA, is expressly defined in the TLDA to include
application programming interfaces to the Java Applet Environment
which includes the Java Runtime Interpreter.  Java/native applications
embody native modules as well as Java Applets.  Microsoft's asserted
interpretation attempts to insert "Applet" into the definition of AAPI
in section 1. 1 (a) and results in the replacement of the term "Java
Applet Environment" with the term "Java Classes."  See TLDA
§§ 1.1, 1.3.  
Moreover, since the TLDA is an integrated agreement (TLDA § 12.3)
and Sun has demonstrated likely success in showing that the definition
of AAPI is not ambiguous, the parol evidence rule may bar Microsoft's
reliance on extraneous documents, letters-of-intent, and prior
negotiations to excise interfaces to the Java Runtime Interpreter from
the express definition of AAPI. See A. Kemp Fisheries, Inc. v. Castle
& Cooke, Inc., 852 F.2d 493, 495 (9th Cir.  1988) ("[T]he parol
evidence rule operates to exclude evidence that is not 'relevant to
prove a meaning to which the language of the instrument is reasonably
susceptible.'  . . . '[E]xtrinsic evidence is not admissible to add
to, detract from, or vary the terms of a written contract.')
(citations omitted); see also California State Auto.  Ass'n Inter-Ins.
Bureau v. Antonelli, 94 Cal.  App. 3d I 1 3, 118 (1979) (stating that,
where a term is expressly defined and used consistently throughout an
agreement, the fact that the ordinary or commonly understood meaning
of the term is narrower does not render the contract term ambiguous).
Furthermore, Microsoft's own draft of March 10, 1996 vitiates
Microsoft's contention that th term "Applet" in "Applet Application
Programming Interface" limits the range of Sun's permissible testing
to programs written solely in the Java language.  Section 1. 1 of the
March 10 draft states that the AAPI "means the application programming
interface to the Technology, including the interface to the Applet
Classes (as defined below)." The definitions of "Applet" and "Java
Test Suite" in the March 10 draft are identical to that contained in
the TLDA.  March 10, 1996 Draft §§ 1.2, 1.16. Microsoft's
own March 10 draft quite clearly states that the invocation interface,
an interface to the Reference Implementation VM, falls within the
compatibility requirements of section 2.6. See, March 10, 1996 Draft
§ 1.9. 
According to Microsoft, JNI is not part of Sun's "specification for
the AAPI" under section 1. 15 of the TLDA and, therefore, JNI falls
outside of the TLDA's compatibility obligations.  Microsoft argues
that "Sun's specification for the AAPI" is limited to the documents
referenced in sections 1.1 (b), (c) and (d) of the TLDA and that these
documents do not refer at all to JNI.  However, Microsoft's
interpretation cannot be squared with- the unambiguous language of the
TLDA.  The term "specification for the AAPI" finds no express
definition in the TLDA.  The TLDA's definition of AAPI contains four
sub-parts, including "the public application programming interface to
the Java Applet Environment.  " TLDA § 1.  1 (a).  Therefore, the
TLDA appears to contemplate that Sun's test suite would validate
compliance with Sun's specification for the Java Applet Environment
which includes the Java Runtime Interpreter.  See TLDA § §
1. 1 5, 1.1 & Ex.  A.
Microsoft also argues that the TLDA's definition of AAPI in section
1.1 (a) is limited to that identified in Exhibit A and excludes
upgrades.  However, Microsoft's asserted interpretation overlooks the
language at the end of section 1. 1 which reasonably appears to
contemplate modifications and upgrades to the AAPI.  TLDA § 1. 1
( "'AAPI' means (a) 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.  ")  (emphasis added).  
Microsoft also submits that JNI is a "Supplemental Java Class" and
that, therefore, it has no obligation to include JNI in its runtime
interpreters.  See TLDA § 2.7(a). However, "Supplemental Java
Classes" are Sun's additions to the Java Classes provided in Exhibit
A, while JNI is an interface to the Java Runtime Interpreter.  See
TLDA § 1.23 ("'Supplemental Java Classes' means the Java classes
that SUN delivers to [Microsoft] after the Effective Date (i.e., in
addition to the "Java Classes") pursuant to section 3.1 of this
Agreement."). Furthermore, Microsoft ignores section 2.9(b) of the
TLDA which requires Microsoft's virtual machine to include "the
necessary Source Code to implement the functionality of the Java
Runtime Interpreter."  
Microsoft argues that Sun cannot permissibly test for compliance with
JNI since Sun does not require some of its other licensees to comply
with JNI.  Microsoft contends that even Sun's JavaOS fails the JNI
related tests.  Sun points out, however, that Sun's JavaOS is
specifically designed to exclude "dynamic loading of native code" and
does not implement JNI or any other native method interface.  Schroer
Reply Decl. ¶ 19.  Furthermore, Microsoft's reliance on the
recommendations of Ms. Schroer as to whether a particular licensee
should be required to support JNI in certain, well-defined instances
is unavailing as no showing has been made (1) that she speaks
conclusively for Sun and (2) that Sun has granted any such exemptions.
Finally, Microsoft argues that the extent of Sun's testing is limited
to the Java Virtual Machine Specification and that including JNI in
the definition of AAPI results in a meaning that is "arbitrary and
unconstrained." However, section 1.1(a) of the TLDA appears to limit
Sun's testing to public application programming interfaces to the
runtime interpreter, rather than tool interfaces or other interfaces
to the runtime interpreter.  Furthermore, as discussed above, Sun's
Java Virtual Machine Specification contemplates invoking native code.
b. Microsoft's Keyword Extensions and Compiler Directives 
The TLDA, according to Microsoft, allows it to optimize the Java
Technology for the Windows platform and expressly contemplates
extensions to the Java language.  Furthermore, Microsoft contends that
its specific implementation of keyword extensions and compiler
directives is not incompatible with Java and does not violate Sun's
Java Language Specification or the Java Virtual Machine Specification.
Microsoft submits that Sun has not identified a single test which
Microsoft's compilers fail.  Opposition at 17.  However, Sun contends
that Microsoft's software development tools fail the Compiler Output
Requirement when the source code compiled with Microsoft's compiler
includes Microsoft's extended keywords and compiler directives.  Sun
also states that Microsoft's language extensions violate both the Java
Virtual Machine Specification and the Java Language Specification.
Sun also argues that the TLDA does not authorize Microsoft to extend
the Java language.
The evidence submitted by the parties indicates that as long as a
software programmer avoids using Microsoft's keyword extensions and
compiler directives, source code will properly compile with any Java
compatible compiler and run on any Java virtual machine.  Accordingly,
the issue distills down to whether the TLDA permits Microsoft to
create and distribute its own extended version of the Java language
and corresponding compiler, provided that its tool products also have
the capability of passing Sun's relevant test suites.  The affirmative
license grants of the TLDA control this issue.  See Cohen, 845 F.2d at
853-54. 
The meaning of section 2.6(b)(iv) appears to be dispositive.
Microsoft does possess the right to modify and create derivative works
of the Java Technology.  Section 2. 1 (a) of the TLDA grants Microsoft
a license to modify, adapt, and create derivative works[5] of the
"Technology" in source code form for the purposes of "developing,
compiling to binary form and supporting Products."  "Technology"
consists of the "Java Runtime Interpreter, Java Classes, Supplemental
Java Classes, Java Compiler, and all Upgrades." TLDA §
1.25. However, the TLDA confines Microsoft's right to distribute
derivative works of the Java Technology to compatible implementations.
The TLDA separately authorizes Microsoft to distribute "Products"
including derivative works of the "Technology" provided that they pass
Sun's relevant test suite.  TLDA §§ 2.2(a)(ii), (iii);
2.6(a), (b).  The TLDA sets forth Microsoft's compatibility
obligations with respect to its compiler.  See TLDA § 2.6(b)(iv)
(Microsoft's compiler "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.").  
Sun and Microsoft attribute materially different meanings to section
2.6(b)(iv). Microsoft contends that section 2.6(b)(iv) evidences the
parties' understanding that Microsoft could extend the Java language
as long as its compiler includes a mode which disables these
extensions and, therefore, passes Sun's test suite.[6] Sun, on the
other hand, asserts that the "mode" language of section 2.6(b)(iv)
only allows Microsoft "to include in its compilers the ability to
compile code for prior, compatible versions of the Java Technology
that were incorporated in earlier products."  Reply at 12.  
Sun has demonstrated a reasonable likelihood of establishing that the
TLDA does not authorize Microsoft's extension of the Java language and
its corresponding modifications to the Java language compiler.  Sun's
showing of likely success as to Microsoft's language extensions is not
as strong as its demonstration of likely success as to JNI; however,
Sun's showing warrants some form of preliminary injunctive relief.
The literal language of section 2.6(b)(iv) supports the interpretation
of both Sun and Microsoft.  Similarly, the extrinsic evidence offered
by Sun as to what was understood by the "mode" language directly
conflicts with Microsoft's extrinsic evidence.  However, the Java
Language Specification and the context in which section 2.6(b)(iv)
appears in the TLDA support Sun's position that Microsoft's language
extensions and modified compiler are not authorized.  
The compatibility requirements set forth in the TLDA, with respect to
both the runtime interpreter and compiler, mandate compliance with the
Java Technology as reasonably upgraded by Sun.  See generally TLDA
§§ 2.6(a), (b).  The TLDA contemplates that Sun will upgrade
the technology and designate "Significant Upgrades."  TLDA
§§ 2.6(b)(iii), (iv).  "[A]ny new version of a Product that
includes the Java Language compilation function shall include a mode
which... permit[sl such Product to pass the Java Language Test Suite
that accompanied the Significant Upgrade." TLDA §
2.6(b)(iv). Against this backdrop, section 2.6(b)(iv) appears only to
allow Microsoft to include in its compiler modes that compile code for
earlier versions of the Java Technology, as long as it also includes a
mode which compiles code in conformance with Sun's most recent
Significant Upgrade of the Java Technology.  Microsoft points to no
other language in the TLDA that purports to affirmatively allow
Microsoft to modify the Java compiler to accept nonstandard keywords
and compiler directives.  Indeed, Microsoft's asserted interpretation
is antithetical to one of the stated purposes of the TLDA.  See TLDA
Recitals ("SUN wishes to license its Java technology, while
maintaining compatibility among Java language based products."); see
also JLSpec. at xxiii ("[A] Java program should compute the same
result on all machines and in all implementations.").  
The Java Language Specification also suggests that Microsoft's keyword
extensions are prohibited.  The Java Language Specification defines
all of the keywords for the language and reserves two keywords which
are not currently used.  JLSpec. at 18-19., The authors of the current
Java Language Specification intended that "the behavior of every
language construct [be] specified [in the Java Language
Specification], so that all implementations of Java will accept the
same programs." JLSpec. at xxiii.  Therefore, adopting non-standard
keywords and modifying a compiler to accept them violate Java's main
objective that a "Java program should compute the same result on all
machines and all implementations." Id.  
Furthermore, Microsoft's compiler directives violate the Java Virtual
Machine Specification. Id.  ¶¶ 31, 32.  The Java Virtual
Machine Specification states that "[a]ttributes not defined in this
specification are not allowed to affect the semantics of the class
file, but only to provide additional descriptive information (§
4.7.1)." JVMSpec.  § 4.6; see also JVMSpec.  § 4.7.l. As
Microsoft's own experts indicate, when, for example, the "@dll"
compiler directive is encountered by a Microsoft compiler in its
default (extended) mode, the resulting binary file contains (1) a
method with the ACC_NATIVE flag set to indicate that native code must
be connected and 2) a new attribute providing necessary additional
information.  See Huhns Decl.  ¶ 59; Lee Decl.  ¶ 39.
Dr. Lee, one of Microsoft's experts, states that semantics "refers to
the actual meaning or behavior of a program or file format." Lee Decl.
¶ 35.  The Java Virtual Machine Specification indicates that the
runtime interpreter should ignore any attribute which it does not
recognize.  JVMSpec. at 106, 107.  However, with respect to the "@dll"
and "@corn" compiler directives, the proper functioning of a software
application requires recognition of a new attribute which contains
necessary additional information, rather than mere descriptive
information which a virtual machine can safely ignore.  Accordingly,
the binary file which results from use of Microsoft's compiler
directives violates the Java Virtual Machine Specification since it
contains a new attribute that affects program behavior.[7] 
At least with respect to Microsoft's compiler directives, Sun has also
demonstrated that Microsoft's compilers in its development tools fail
Sun's Compiler Output Requirement test as contemplated by the TLDA.
The JCK 1.1a Test Suite documentation states that the output of a
licensee's compiler implementation must execute properly with the
JavaSoft Virtual Machine.  Schroer Reply Decl.  ¶ 4 & Ex.
A. Accordingly, Microsoft's "extended" compiler fails the
compatibility mandates of the TLDA since it generates output which
contains non-standard attributes that affect program semantics and,
therefore, fails Sun's Compiler Output Requirement.  See Schroer Reply
Decl.  ¶¶ 7, 8, 11, 12 & Ex.  A; Gosling Decl.  ¶¶
18-23 33.
On the other hand, Sun's contention that use of Microsoft's keyword
extensions generates output that fails the Compiler Output Requirement
is somewhat difficult to reconcile with Microsoft's expressly granted
ability to add new functionality to its implementation of Java in the
form of additional Java classes.  See TLDA § 2.8(a) ("The parties
understand and agree that ...  [Microsoft] 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')."); see also TLDA § 1.28 ("'VAOPs' "delegate," it
generates a crass file having attributes that reference two classes
developed by Microsoft ("com.ms.lang.Delegate" and
"com.ms.lang.MulticastDelegate"). If a virtual machine, such as Sun's,
does not implement these classes, compiled code which calls these
classes will not run on that virtual machine.  Deutsch Decl.  Ex. 6
(DeMichillie Depo. at 61:8- 63:14).  However, this would appear to
occur regardless of the manner in which the compiler generates a class
file (i.e., whether it recognized Microsoft's, added keywords and
generated the class file or whether it compiled standard Java source
code implementing this class file).  Furthermore, a class file having
an attribute which references a VAOP/Java class apparently would not
run on Sun's JDK 1. I virtual machine if it did not support that
VAOP/Java class.[8] In the present case, however, it is unclear
whether com.ms.lang.Delegate and com.ms.lang.MulticastDelegate are in
fact VAOP/Java classes.  While these classes are named according to
the convention set forth in section 2.8(d) of the TLDA, they appear to
be integrated into Microsoft's Java virtual machine, rather than
implemented as separate class files.[9] See DeMichillie Depo. at
62:10-22.  In any event, the court makes no determination as to
whether Microsoft's delegate and multicast classes are in fact VAOPs.
Even assuming that these classes are VAOPs, the TLDA does not
authorize Microsoft's use of additional keywords ("multicast" and
"delegate"') and a modified compiler to generate class files which
extend these classes.  
3. SDKJ 2.02 and "Test 601"
In light of the evidence discussed in Section I.C.2., Sun has raised a
reasonable likelihood of success of establishing that SDKJ 2.02 fails
"Test 601" and "Test 2003."
4. Waiver
Microsoft submits that Sun waived its claim of breach by continuing to
accept payments from Microsoft under the TLDA.  However, waiver
requires the intentional relinquishment of a known right.  See
U.S. v. King Features Entertainment, Inc. , 843 F.2d 394, 399 (9th
Cir. 1988).  Sun's acceptance of payment from Microsoft, even when Sun
knew that Microsoft was breaching the TLDA's compatibility provisions,
does not constitute a waiver of a claim for breach of the TLDA.
Section 12.3 of the TLDA requires waivers to be in writing.  Further,
in light of the circumstances existing between the parties at the time
of payment, Sun could not be viewed as intending to relinquish its
claims of breach by accepting payment.
B.      IRREPARABLE HARM AND BALANCE OF HARDSHIPS
Demonstrating a reasonable likelihood of success on the merits raises
a presumption of irreparable harm.  Johnson Controls v. Phoenix
Controls Systems, 886 F.2d 1173, 1174 (9th Cir. 1989) (citing Apple
Computer Inc. v. Formula Int'l.  Inc., 725 F.2d 521, 525 (9th Cir.
1984)).  The adequacy of money damages does not rebut this
presumption.  Cadence Design Systems, Inc. v. Avant! Corp., 125 F.3d
824, 827 (9th Cir. 1997).  Additionally, where a plaintiff has
established a likelihood of success on the merits, the harm which a
defendant may suffer from an order enjoining its infringing activity
generally becomes a minor consideration.  Id. at 829-30.  Significant
public injury resulting from an injunction, however, may support the
denial of injunctive relief.  See Abend v. MCA, Inc., 863 F.2d 1465,
1479 (9th Cir. 1988), aff'd sub nom., Stewart v. Abend, 110 S.Ct. 1750
(1990).
As to compliance with JNI and Microsoft's unauthorized extension of
the Java language, Sun has demonstrated a reasonable likelihood of
success on the merits and, thus, enjoys a presumption of irreparable
harm.  Microsoft's argument that, under USAR Systems, Inc. v. Brain
Works, Inc., 887 F Supp. 84 (S.D.N.Y. 1995), Sun does not enjoy a
presumption of irreparable harm merely rehashes it argument, which the
court has rejected, that Sun's claims arise out of breach of contract
rather than copyright infringement.  
Microsoft also argues that Sun's delay in seeking to enjoin Microsoft
rebuts the presumption of irreparable harm.  However, the
circumstances of the present case do not appear to establish
unreasonable delay by Sun.  Sun filed its motions before the
commercial release of Windows98 and VJ 6.0. See Forry,
Inc. v. Neundorfer.  Inc., 837 F.2d 259, 267 (6th Cir. 1988) (holding
that 22-month delay in filing copyright infringement action did not
rebut presumption of irreparable harm).
As to the balance of hardships, the potential harm to Microsoft
arising out of an injunction requiring support for Sun's JNI does not
appear to be unduly burdensome.  Sun's application for preliminary
injunctive relief only seeks Microsoft's inclusion and support of JNI.
Sun does not object to Microsoft's concurrent use of other native
interfaces such as RNI or J/Direct.  Microsoft estimates that
inclusion of support for JNI in Windows98 would require at least
ninety days for redevelopment, testing, documentation and
distribution.  Akerlind Decl.  ¶ 12.  Microsoft also states that
the process of reworking VJ 6.0 to support Sun's JNI would take 180
days and cost about $5 million.  Button Decl.  ¶ 5.  
Sun's requested relief does implicate the public interest.  Microsoft
submits evidence demonstrating that a variety of third parties would
be harmed by an injunction precluding the distribution of Windows98,
IE 4.0 and Microsoft's development tools.  Specifically, OEM PC
Manufacturers would be significantly harmed if Windows98 were
immediately enjoined.  See Akerlind Decl.. ¶¶ 2-11, 14;
Mitchell Decl.  An injunction affecting Windows98 also has the
potential to significantly harm software distributors and resellers.
Schiro Decl.  ¶¶ 4-14, 16-18.  Additionally, third party
software developers who have used SDKJ or VJ 6.0 to develop client
Windows-specific applications would be significantly harmed by any
injunction affecting Windows98, IE 4.0 or any of Microsoft's software
development products.  Button Decl.  ¶¶ 3, 9. Further, book
and magazine publishers who have developed products relating to VJ 6.0
could be harmed.  Id. ¶¶ 4, 1 0.  
Sun's willingness to temper its requested relief mitigates some of the
potential harm asserted by Microsoft.  As discussed above, Sun does
not seek recall of any Microsoft product already in the distribution
channel.  As to Windows98 and IE 4.0, Sun is willing to allow
Microsoft ninety days to develop and distribute versions which pass
Sun's test suites (i.e.  support JNI).  This ninety-day period, with
the right to extend for good cause, should allow Microsoft adequate
time to modify its virtual machine to support JNI.  
Sun's requested relief as to Microsoft's development tools, however,
would cause significant harm to innocent third party software
developers.  Therefore, the court declines to require Microsoft to
immediately cease all further distribution of SDKJ 2.0, SDKJ 3.0 and
VJ 6.0 in their present forms prior to a trial on the merits.
Nevertheless, Sun is entitled to some preliminary relief which will
lessen the harm caused by Microsoft's violation of the TLDA but not
cause significant harm to the public.  
Third party developers would not be significantly harmed by
prohibiting Microsoft from adding new compiler directives, keywords or
other language extensions pending trial.  Nor would developers be
harmed if the mode switch on Microsoft's compiler were changed so that
the default mode disallowed Microsoft's extensions and a warning
issued if a developer enabled the extensions.  
C. SUN'S CLAIM OF UNFAIR COMPETITION 
The court's disposition of Sun's motion for preliminary injunctive
relief based on copyright infringement achieves much of the relief
sought by Sun.  Therefore, the court only addresses those aspects of
Sun's motion based on unfair competition to the extent that it seeks,
to enjoin certain of Microsoft's licensing practices and statements to
developers.
 Any person or entity who has engaged, engages or threatens to engage
"in unfair competition may be enjoined in any court of
competent jurisdiction." Cal.  Bus. & Prof.  Code §§
17201, 17203.  "Unfair competition" includes "any unlawful, unfair or
fraudulent business act or practice and unfair deceptive, untrue or
misleading advertising." Cal.  Bus. & Prof.  Code § 17200.
Business conduct need not be illegal to be enjoined under section
17203.  State Farm Fire & Casualty Co. v. Superior Court, 45 Cal.
App. 4th 1093, 1103-05 (1996) (holding that breach of duty of good
faith and fair dealing supports injunction under section 17200).
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).  This test involves balancing the "the impact of the
practice or act on its victim ... against the reasons, justifications
and motives of the alleged wrongdoer." Klein v. Earth Elements, Inc.,
59 Cal.  App. 4th 965, 969-70 (1997).
As discussed above, Sun challenges Microsoft's licensing policies to
the extent that Microsoft requires its licensees to exclusively
distribute Microsoft's virtual machine and to call native code only by
use of Microsoft's interfaces (RNI, J/Direct and Java/COM).  Sun
submits two licensing agreements which contain the offending terms.
Sun also objects to Microsoft's "Designed for Windows95/NT" logo
licensing program.  Sun alleges that Microsoft unfairly requires
software developers who wish to use the logo to use only Microsoft's
virtual machine in the products they distribute.  See Schroer Decl.
Ex.  L, M, N.  Microsoft submits that no Java program developer has
ever attempted to certify an application.  Thibodeaux Decl. ¶ 3.
Microsoft contends that this part of the program will be dropped for
lack of interest.  McMahon Decl.  Ex. 19 (Plamondon Depo. at
139:14-140:7).
The court finds that negotiating for or enforcing the above-mentioned
licensing terms constitutes an unfair business practice.  Microsoft
does not argue that these licensing provisions bear any utility which
outweighs the harm asserted by Sun.  That Microsoft apparently no
longer requires its licensees to adhere to such terms and that it
plans to abandon its logo licensing program as to Java provides an
insufficient basis for denying Sun its requested relief.[10] See Polo
Fashions, Inc. v. Dick Bruhn Inc., 793 F.2d 1132, 1135-36 (9th Cir.
1986).
Additionally, the court finds that Microsoft's designation of its
virtual machine as the "Official Reference Implementation of Java on
Windows 32-bit platforms" is misleading.  The TLDA defines "Reference
Implementation VM" as "[Microsoft]-authored Derivative Works or
Independent Works of the Java Runtime Interpreter for Win3 2
Platforms."  TLDA § 1. I 0.  However, this definition does not
expressly state or imply that Microsoft's runtime interpreter is the
Sun designated, official reference implementation for Win32 platforms.
Microsoft directs the court to no other language in the TLDA which
supports its position.
                              IV. ORDER
Since the court finds that Sun is likely to prevail on the merits and
that it may suffer irreparable harm if Microsoft is not enjoined, a
preliminary injunction is hereby issued against Microsoft, and its
officers, agents, servants, employees, attorneys, and those in active
concert or participation with them who receive actual notice of this
order by personal service or otherwise, pending trial, from: 
(A) Selling or distributing, directly or indirectly, any operating
system or browser product containing or implementing computer program
code copied or derived from any Sun copyrighted program code for the
Java Technology as that term is defined in the TLDA (i.e., the Java
Runtime Interpreter, Java Classes, Supplemental Java Classes, Java
Compiler, and all Upgrades), including Windows98 and IE 4.0, ninety
(90) days after the date of this order unless such product includes a
Java runtime implementation which supports Sun's JNI in a manner which
passes the compatibility test suite accompanying the latest version of
the Java Technology contained in, implemented by, or emulated by such
product; 
(B) Selling or distributing, directly or indirectly, any software
development tool or product containing or implementing computer
program code copied or derived from any Sun copyrighted program code
for the Java Technology; as that term is defined in the TLDA,
including SDKJ 2.0, SDKJ 3.0 and VJ 6.0, ninety (90) days after the
date of this order unless such product: 
(1) includes a Java runtime implementation which supports Sun's JNI
(including help files, header files, etc.) in a manner which passes
the compatibility test suite accompanying the latest version of the
Java Technology contained in, implemented by, or emulated by such
product, 
(2) has the default mode in the compiler configured such that (a)
Microsoft's keyword extensions and compiler directives are disabled
and (b) has the compiler mode switch such that it enables, rather than
disables, such keyword extensions and compiler directives, and 
(3) includes a warning which appears when a user elects to use the
extended mode of the compiler (either when the user accesses the
compiler from a DOS command line or when the user checks a box
provided during execution of the compiler software) and which warns
the user (a) that use of Microsoft's language extensions will result
in compiled code which may not run on all compatible virtual machines,
and (b) that future versions of Microsoft's development tools may be
prohibited by court order from incorporating keyword extensions and
compiler directives not contained in Sun's Java Language
Specification; however, nothing in this order prevents Microsoft from
removing the mode switch, keyword extensions and compiler directives
from its Java software development tools and distributing or selling
such resulting implementations.  
(C) Selling or distributing SDKJ 2.02 unless such product passes Test
601 and Test 2003; 
(D) Conditioning the right to use the "Designed for Windows95(98)/NT"
logo on the exclusive distribution of Microsoft's Java virtual
machine; 
(E) Conditioning any license to any Microsoft product on exclusive use
or distribution of Microsoft's Java virtual machine; 
(F) Entering into any agreement, condition or arrangement with any
third party that requires such third party to exclusively use
Microsoft's interfaces to its runtime interpreter when invoking native
code; 
(G) Advertising any product that contains, implements or emulates the
Java Technology as the "official" Java reference implementation;
however, nothing in this order prevents Microsoft from making
advertising claims with respect to the performance of its reference
implementation; and 
(H) Incorporating any additional Microsoft keyword extensions or
compiler directives into its Java software development tools.
Microsoft may seek a reasonable extension of the ninety-day period
provided in sections IV(A) and (B) of this order upon a showing of
good cause.  
Nothing in this order requires Microsoft to recall any product or from
upgrading its products so long as they do not include additional
Microsoft keyword extensions or compiler directives.  This order does
not prevent any purchaser of Microsoft's products from continuing to
use them.  However, Microsoft shall provide upgrades that meet the
requirements of IV(A) and (B) above (for example, by way of service
packs on its Website).  
Microsoft shall, within fifteen (15) days of this order, notify its
customers of this order and the corrective steps to be taken.  Such
notice shall expressly indicate that the court has preliminarily found
that Microsoft has violated its licensing agreement to Sun's Java
Technology and that if a final judgment is entered consistent with the
court's preliminary findings, Microsoft's keywords and compiler
directives not contained in Sun's Java Language Specification (i.e.
"multicast," "delegate," "@dll," "@corn," and "security") may be
prohibited from being included in any future Microsoft software
development tool for Java.  Such notice shall be prominently posted on
Microsoft's website and included in the next quarterly-release of the
Microsoft- Developer Network.  
As a condition of this preliminary injunction, Sun shall give security
within ten (10) days of this order in the amount of $15,000,000 for
the payment of such costs and damages as may be suffered by Microsoft
if it is found to have been wrongfully enjoined.  
DATED: 11/17/98
RONALD M. WHYTE 
United States District Judge
Copy of Order mailed on NOV 17 1998 to:
Lloyd R. Day, Jr.
Vernon Winters
Day, Casebeer, Madrid, Winters & Batchelder
20400 Stevens Creek Boulevard, Suite 750
Cupertino, CA 95014
Janet Cullum
Cooley Godward LLP
Five Palo Alto Square
3000 El Camino Real
Palo Alto, CA 94306-2155
     Counsel for Plaintiff
David T. McDonald
Karl J. Quackenbush
Preston, Gates & Ellis
701 Fifth Avenue, Suite 5000
Seattle, WA 98104-7078
Terrence P . McMahon
Barbara A. Caulfield
Orrick, Herrington, & Sutcliffe LLP
1020 Marsh Road
Menlo Park, CA 94025
Allen Ruby
Ruby & Schofield
60 South Market Street, Suite 1500
San Jose, CA 95113
Thomas Burt
Microsoft Corporation
One Microsoft Way, Bldg. 8
Redmond, WA 98052
     Counsel for Defendant
Edward P. Davis, Jr.
Skjerven, Morrill, MacPherson, Franklin & Friel LLP
25 Metro Drive, Suite 700
San Jose, CA 95110
Roger R. Myers
Steinhart & Falconer
333 Market Street, 32nd Floor
San Francisco, CA 94105-2150
     Counsel for Media Entities
-----------------------------
FOOTNOTES:
[1]     Certain language in the LOI supports Sun's contention that the
parties initially contemplated only a "browser" deal.  See McMahon
Decl. Ex. 36 at 1 ("Assuming that we are able to reach a definitive
agreement that is consistent with this letter and attachment,
MICROSOFT will supply Java support in the Internet Explorer for
Windows95 and its successors."); Id. at 4 ("If MICROSOFT is to agree
to incorporate the necessary and sufficient Java runtime execution
environment and AAPI binaries into MICROSOFT's Internet Explorer
browser products....").
[2]     The conditions under which the final terms of the TLDA were
negotiated may explain why the recollections of Sun's and Microsoft's
respective negotiators differ substantially as to several material
issues.
[3]     The TLDA defines "Java Language Test Suite" as "SUN's publicly
available test suites for validating that products which compile the
Java Language comply with the then-current Java Language Specification
as of the date of the test suites."  TLDA § 1.13.
[4]     Microsoft points out that Sun has created a compiler directive
called "@deprecated."  The @deprecated directive causes the compiler
to print a warning under certain circumstances and does insert a
"deprecated" attribute into the output class file.  Deutsch Reply
Decl. ¶ 8; Gosling Decl. ¶ 36; see also Huhns Dec. ¶
55.  However, the deprecated attribute does not affect the behavior of
the class file.  See Deutsch Dec. Ex. 20
[5]     The TLDA defines a derivative work as "any revision,
modification, ... abridgment, ... expansion... or other form in which
an existing work may be recast, transformed, ported or adapted and
which is a 'derivative work' under U.S. copyright law."  TLDA §
1.5.
[6]     Beyond Microsoft's license to create derivative works of the
Java Technology and section 2.6(b)(iv) of the TLDA, Microsoft points
to no other provision in the TLDA which purports to authorize
Microsoft to extend the Java language.
[7]     Microsoft's "@security" directive also affects program
semantics, but is "used to disable special security facilities
implemented on Microsoft's Virtual Machine."  Lee Decl. ¶ 37.
[8]     According to Sun's logic, the Compiler Output Requirement test
would be failed.
[9]     If com.ms.lang.Delegate and comp.ms.lang.MulticastDelegate
are VAOPs, the fact that a class file containing references to them
would fail to execute on Sun's JDK 1.1 Virtual Machine would not
appear to be an appropriate basis for asserting that Microsoft's
compiler fails the compatibility requirements of the TLDA.
Furthermore, even if these classes are not VAOPs, the court makes no
determination as to whether the TLDA prevents Microsoft from
integrating added functionality directly into its virtual machine.
[10]    Moreover, since Microsoft alleges that it no longer seeks such
terms from its licensees, it will suffer no harm from this aspect of
the court's injunction.

© Copyright 1998 The Washington Post Company

Back to the top

Navigation Bar
Navigation Bar
 
yellow pages
Bell Atlantic Small Business Solutions NextCard Internet Visa - Apply Now