# Massachusetts v. Microsoft Corp.

> Court of Appeals for the D.C. Circuit · June 30, 2004 · 373 F.3d 1199

URL: https://www.frixlaw.com/law-library/cases/186212

## Case

- **Full name:** Commonwealth of MASSACHUSETTS, Ex Rel., Appellant, v. MICROSOFT CORPORATION, Appellee; United States of America, Appellee, v. Microsoft Corporation, Et Al., Appellees. the Computer and Communications Industry Association and the Software and Information Industry Association, Appellants
- **Court:** Court of Appeals for the D.C. Circuit
- **Decided:** June 30, 2004
- **Citations:** 373 F.3d 1199; 362 U.S. App. D.C. 152; 2004 WL 1462298
- **Precedential status:** Published
- **Opinion:** Opinion by Ginsburg
- **Judges:** Ginsburg, Edwards, Sentelle, Randolph, Rogers, Tatel
- **Cited by:** 126 later opinions in the Frix Law Library

## Citator (automated)

- No negative treatment found by the automated citator. That is not the same as a confirmation that the case is good law; read the citing cases.
- Full citator and citing cases: https://www.frixlaw.com/law-library/cases/186212

## How later opinions describe it (automated extraction)

- concluding that the district court “did not abuse its discretion by adopting a remedy that denie[d] Microsoft the ability to take the same or similar actions to limit competition in the future”
- affirming the district court’s finding that the fruit of Microsoft’s anticompetitive conduct, which foreclosed avenues of distribution for nascent middleware products, was its “freedom from the possibility [that] rival middleware vendors would pose a threat to its monopoly of …
- explaining that, absent any claim of “inadequate notice,” there was “no reason to bar intervention based solely upon” the “technical defect” of failure to attach a pleading
- affirming the district court’s rejection of a remedy that would work a “substantial” effect upon Microsoft’s incentive to innovate and thereby harm consumers

## Opinion text

Notice: This opinion is subject to formal revision before publication in the
Federal Reporter or U.S.App.D.C. Reports. Users are requested to notify
the Clerk of any formal errors in order that corrections may be made
before the bound volumes go to press.

United States Court of Appeals
FOR THE DISTRICT OF COLUMBIA CIRCUIT

Argued November 4, 2003 Decided June 30, 2004

No. 02-7155

COMMONWEALTH OF MASSACHUSETTS, EX REL.,
APPELLANT

v.

MICROSOFT CORPORATION,
APPELLEE

Appeal from the United States District Court
for the District of Columbia
(No. 98cv01233)
–————

Bills of costs must be filed within 14 days after entry of judgment.
The court looks with disfavor upon motions to file bills of costs out
of time.
2

No. 03-5030

UNITED STATES OF AMERICA,
APPELLEE

v.

MICROSOFT CORPORATION, ET AL.,
APPELLEES

THE COMPUTER AND COMMUNICATIONS INDUSTRY ASSOCIATION AND
THE SOFTWARE AND INFORMATION INDUSTRY ASSOCIATION,
APPELLANTS

Appeal from the United States District Court
for the District of Columbia
(No. 98cv01232)
–————
Steven R. Kuney argued the cause for appellant Common-
wealth of Massachusetts, ex rel., in No. 02-7155. With him on
the briefs were Brendan V. Sullivan, Jr., Thomas F. Reilly,
Attorney General, Attorney General’s Office of the Common-
wealth of Massachusetts, and Glenn S. Kaplan, Assistant
Attorney General. John E. Schmidtlein and Nicholas J.
Boyle entered appearances.
Robert H. Bork argued the cause for appellants The Com-
puter and Communications Industry Association, et al., in No.
03-5030. With him on the briefs were Kenneth W. Starr,
Glenn B. Manishin, Stephanie A. Joyce, Mark L. Kovner,
and Elizabeth S. Petrela.
Kenneth W. Starr, Robert H. Bork, David M. Gossett,
Elizabeth S. Petrela, David M. Falk, and Mitchell S. Pettit
were on the brief of amici curiae The Computer and Commu-
nications Industry Association, et al., in support of appellant
in No. 02-7155. Glenn B. Manishin entered an appearance.
3

Deborah P. Majoras, Deputy Assistant Attorney General,
U.S. Department of Justice, argued the cause for appellee
United States of America in No. 03-5030. With her on the
brief were R. Hewitt Pate, Assistant Attorney General, and
Catherine G. O’Sullivan and David Seidman, Attorneys.
Michael Lacovara and Steven L. Holley argued the causes
for appellees. With them on the briefs were John L. War-
den, Richard J. Urowsky, Richard C. Pepperman II, Bradley
P. Smith, Thomas W. Burt, David A. Heiner, Jr., Charles F.
Rule, and Dan K. Webb.
Before: GINSBURG, Chief Judge, and EDWARDS, SENTELLE,
RANDOLPH, ROGERS, and TATEL, Circuit Judges.
Opinion for the Court filed by Chief Judge GINSBURG.

I. Background TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 5
II. Commonwealth of Massachusetts v. Microsoft,
No. 02-7155TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 10
A. Remedial Proposals TTTTTTTTTTTTTTTTTTTTTTTTT 11
1. Commingling TTTTTTTTTTTTTTTTTTTTTTTTTTTT 11
2. Java deceptionTTTTTTTTTTTTTTTTTTTTTTTTTTT 20
3. Forward-looking provisions TTTTTTTTTTTTTTT 24
a. Disclosure of APIs TTTTTTTTTTTTTTTTTTTT 24
b. Disclosure of communications proto-
cols TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 35
4. Web ServicesTTTTTTTTTTTTTTTTTTTTTTTTTTTT 39
5. Market Development ProgramsTTTTTTTTTTTT 42
6. Open Source Internet Explorer TTTTTTTTTTTT 44
7. Java must-carry TTTTTTTTTTTTTTTTTTTTTTTTT 50
B. Cross-cutting Objections TTTTTTTTTTTTTTTTTTTTT 51
1. ‘‘Fruits’’ TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 51
2. Presumption TTTTTTTTTTTTTTTTTTTTTTTTTTTT 54
III. CCIA and SIIA v. United States & Microsoft,
No. 03-5030TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 55
A. Intervention TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 55
B. The Public Interest Finding TTTTTTTTTTTTTTTTTT 59
1. Issues overlapping Massachusetts’ case TTTT 61
a. ComminglingTTTTTTTTTTTTTTTTTTTTTTTTT 62
b. Java TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 63
4

c. Disclosure of APIs TTTTTTTTTTTTTTTTTTTT 65
d. Adequacy of definitionsTTTTTTTTTTTTTTTT 67
e. ‘‘Fruits’’ TTTTTTTTTTTTTTTTTTTTTTTTTTTTT 69
2. Non-overlapping issues TTTTTTTTTTTTTTTTTTT 70
a. Enforcement TTTTTTTTTTTTTTTTTTTTTTTTT 70
b. User interfaceTTTTTTTTTTTTTTTTTTTTTTTT 73
c. Anti-retaliation TTTTTTTTTTTTTTTTTTTTTTT 75
C. Procedural ClaimsTTTTTTTTTTTTTTTTTTTTTTTTTTT 75
1. Government’s disclosure TTTTTTTTTTTTTTTTTT 76
2. Microsoft’s disclosureTTTTTTTTTTTTTTTTTTTTT 81
IV. Conclusion TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT 83
* * *
GINSBURG, Chief Judge: In United States v. Microsoft
Corp., 253 F.3d 34 (D.C. Cir. 2001) (Microsoft III), we
affirmed in part and reversed in part the judgment of the
district court holding Microsoft had violated §§ 1 and 2 of the
Sherman Antitrust Act, vacated the associated remedial or-
der, and directed the district court, on the basis of further
proceedings, to devise a remedy ‘‘tailored to fit the wrong
creating the occasion’’ therefor, id. at 107, 118-19. On re-
mand, the United States and certain of the plaintiff states
entered into a settlement agreement with Microsoft. Pursu-
ant to the Antitrust Procedures and Penalties (Tunney) Act,
15 U.S.C. §§ 16(b)-(h), the district court held the parties’
proposed consent decree, as amended to allow the court to act
sua sponte to enforce the decree, was in ‘‘the public interest.’’
Meanwhile, the Commonwealth of Massachusetts and several
other plaintiff states refused to settle with Microsoft and
instead litigated to judgment a separate remedial decree.
The judgment entered by the district court in their case
closely parallels the consent decree negotiated by the United
States.
Massachusetts alone appeals the district court’s entry of
that decree. It argues the district court abused its discretion
in adopting several provisions Microsoft proposed while re-
jecting several others Massachusetts and the other litigating
states proposed. Massachusetts also challenges a number of
the district court’s findings of fact. Based upon the record
5

before us in Microsoft III and the record of the remedial
proceedings following remand, we affirm the district court’s
remedial decree in its entirety.
The Computer and Communications Industry Association
(CCIA) and the Software and Information Industry Associa-
tion (SIIA) separately appeal the district court’s denial of
their motion, following the district court’s approval of the
consent decree between the United States and Microsoft, to
intervene in the case for the purpose of appealing the district
court’s public-interest determination. They argue the factors
the district court was to consider in determining whether to
allow them to intervene weighed in their favor. We agree
and reverse the district court’s denial of their motion to
intervene for the purpose of appealing that court’s public-
interest determination.
CCIA and SIIA make various arguments — some over-
lapping those raised by Massachusetts — that the consent
decree between the United States and Microsoft is not in the
public interest. They also argue the parties did not satisfy
the procedural requirements of the Tunney Act. For these
reasons, they seek vacatur of the district court’s order ap-
proving the consent decree and a remand for entry of ‘‘a
proper remedy.’’ We find no merit in any of CCIA’s and
SIIA’s objections, substantive or procedural. We therefore
uphold the district court’s approval of the consent decree as
being in the public interest.

I. Background
The facts underlying the present appeals have been re-
counted several times. See New York v. Microsoft Corp., 224
F. Supp. 2d 76 (D.D.C. 2002) (States’ Remedy); United States
v. Microsoft Corp., 231 F. Supp. 2d 144 (D.D.C. 2002) (U.S.
Consent Decree); see also Microsoft III. We therefore limit
our discussion of the facts and of the proceedings to a brief
review of events prior to our remand in 2001 and a more
detailed account of what has transpired since then.
In May 1998 the United States filed a complaint against
Microsoft alleging violations of federal antitrust laws. At the
6

same time, a number of states and the District of Columbia
filed a complaint against Microsoft alleging violations of both
federal and state antitrust laws. The two complaints, which
the district court consolidated, sought various forms of relief,
including an injunction against certain of Microsoft’s business
practices.
After a lengthy bench trial the district court entered find-
ings of fact, United States v. Microsoft Corp., 84 F. Supp. 2d
9 (D.D.C. 1999) (Findings of Fact), and held Microsoft had
violated §§ 1 and 2 of the Sherman Act by illegally maintain-
ing its monopoly in the market for ‘‘Intel-compatible PC
operating systems,’’ by attempting to monopolize the browser
market, and by tying its Windows operating system to its
Internet Explorer (IE) browser. United States v. Microsoft
Corp., 87 F. Supp. 2d 30 (D.D.C. 2000) (Conclusions of Law).
The district court also held Microsoft violated the antitrust
laws of the several states. Id. at 56. Based upon its findings
of fact and conclusions of law, the district court decreed that
Microsoft would be split into two separate companies, one
selling operating systems and one selling program applica-
tions. See United States v. Microsoft Corp., 97 F. Supp. 2d
59 (D.D.C. 2000) (Remedy I). Microsoft appealed the deci-
sions of the district court, alleging several legal and factual
errors.
We upheld the district court’s ruling that Microsoft violated
§ 2 of the Sherman Act by the ways in which it maintained its
monopoly, but we reversed the district court’s finding of
liability for attempted monopolization, and we remanded the
tying claim to the district court to apply the rule of reason
rather than the rule of per se illegality. See Microsoft III.
We also vacated the district court’s remedial decree, for three
reasons: ‘‘First, [the district court had] failed to hold an
evidentiary hearing despite the presence of remedies-specific
factual disputes’’; ‘‘[s]econd, the court did not provide ade-
quate reasons for its decreed remedies’’; and third, we had
‘‘drastically altered the scope of Microsoft’s liability, and it
[was] for the District Court in the first instance to determine
the propriety of a specific remedy for the limited ground of
liability which we ha[d] upheld.’’ Id. at 107.
7

On remand the district court ordered the parties to file a
Joint Status Report. This they did in September 2001,
whereupon the district court ordered them to undertake
settlement discussions. See United States v. Microsoft Corp.,
2001 U.S. Dist. LEXIS 24272 (D.D.C. Sept. 28, 2001). As a
result, the United States and the States of Illinois, Louisiana,
Maryland, Michigan, New York, North Carolina, Ohio, and
Wisconsin, and the Commonwealth of Kentucky, agreed to
enter into a consent decree with Microsoft. On November 6,
2001 the settling parties filed a Revised Proposed Final
Judgment, 1 Joint Appendix in No. 03-5030 (hereinafter J.A.
(I)) at 113-30, for the district court’s review. The States of
California, Connecticut, Florida, Iowa, Kansas, Minnesota,
Utah, and West Virginia, the Commonwealth of Massachu-
setts, and the District of Columbia refused to enter into the
consent decree. The district court therefore bifurcated the
remaining proceedings: On ‘‘Track I’’ was the district court’s
‘‘public interest’’ review of the proposed consent decree, as
required by the Tunney Act whenever the Government pro-
poses to settle a civil antitrust case, see 15 U.S.C. § 16(e); on
‘‘Track II’’ was the continuing litigation between the non-
settling states (hereinafter ‘‘the States’’) and Microsoft con-
cerning the remedy.
Track I
On November 15, 2001 the Government filed its Competi-
tive Impact Statement (CIS), 1 J.A. (I) at 136-202, as required
by the Act, 15 U.S.C. § 16(b), and on November 28, 2001 it
published in the Federal Register both the Revised Proposed
Final Judgment and the CIS for public comment. 66 Fed.
Reg. 59,452 (Nov. 28, 2001). In February 2002 the Govern-
ment filed with the district court its response to the more
than 32,000 public comments it had received, along with a
Second Revised Proposed Final Judgment, 6 Joint Appendix
in No. 02-7155 (hereinafter J.A. (II)) at 3664-81, reflecting
modifications agreed to by the settling parties in the light of
the public comments. The public comments, which the Gov-
ernment made available at its website in March 2002, were
subsequently published in the Federal Register as well. 67
Fed. Reg. 23,654 (May 3, 2002). The Tunney Act also
8

requires the defendant to file with the district court ‘‘any and
all written or oral communications TTT with any officer or
employee of the United States’’ relating to the proposed
consent judgment. 15 U.S.C. § 16(g). Microsoft made such
a filing in December 2001 and again in March 2002. See Part
III.C.2.
The Tunney Act provides the district court with several
procedural options to aid it in making its determination
whether the proposed consent decree is in the public interest.
The court may ‘‘take testimony of Government officials or
experts’’ as it deems appropriate, 15 U.S.C. § 16(f)(1); au-
thorize participation by interested persons, including appear-
ances by amici curiae, id. § 16(f)(3); review comments and
objections filed with the Government concerning the proposed
judgment, as well as the Government’s response thereto, id.
§ 16(f)(4); and ‘‘take such other action in the public interest
as the court may deem appropriate,’’ id. § 16(f)(5). The
district court exercised several of these options. It held a
hearing with the purpose of having the parties provide to the
court information it needed to decide whether to approve the
Second Revised Proposed Final Judgment. The district court
denied CCIA’s request to intervene in the case, see id.
§ 16(f)(3), but it did allow CCIA and SIAA to participate in
the hearing as amici curiae. In July 2002 the district court
concluded both the Government and Microsoft had complied
with the requirements of the Tunney Act and held that the
matter was ripe for the court to determine whether the
decree was in the ‘‘public interest.’’ United States v. Micro-
soft Corp., 215 F. Supp. 2d 1, 23 (D.D.C. 2002) (Tunney Act
Proceedings).
On November 1, 2002 the district court ruled the Second
Revised Proposed Final Judgment would be in the public
interest if modified in one respect: The parties would have to
provide for the district court to ‘‘retain jurisdiction to take
action sua sponte in conjunction with the enforcement of the
decree.’’ U.S. Consent Decree, at 202. This they did in a
Third Revised Proposed Final Judgment, which the district
9

court duly entered. United States v. Microsoft Corp., 2002
WL 31654530 (D.D.C. Nov. 12, 2002) (Final Consent Decree).1
On December 20, 2002 CCIA and SIIA filed a joint motion
for leave to intervene, as of right or alternatively by permis-
sion, see FED. R. CIV. P. 24, for the purpose of appealing the
district court’s judgment that the consent decree was in the
‘‘public interest.’’ The district court denied their motion,
United States v. Microsoft Corp., 2003 WL 262324 (D.D.C.
Jan. 11, 2003) (Order Denying Intervention), and the movants
now appeal both the district court’s denial of their motion for
leave to intervene and, if allowed, the district court’s public-
interest determination under the Tunney Act.
Track II
Pursuant to the district court’s scheduling order of Septem-
ber 28, 2001, Microsoft and the States submitted competing
remedial proposals in December of that year. This time the
States did not propose to divide Microsoft but, as discussed in
Part II.A.6, they did include proposals the district court
considered structural in nature, including requirements that
Microsoft offer ‘‘open source licensing for Internet Explorer’’
and ‘‘auction to a third party the right to port Microsoft
Office to competing operating systems.’’ Microsoft objected
to the States’ proposed remedy and offered as an alternative
the Revised Proposed Final Judgment to which it had agreed
in the Track I proceedings. Both sides later submitted
revised proposals. In February 2002 Microsoft submitted the
Second Revised Proposed Final Judgment, and in March the
1 The district court also held the ‘‘public interest’’ standard
made applicable to the Government’s case by the Tunney Act
should be applied to the settlement between the settling states and
Microsoft in order to meet the generally applicable requirement of
circuit law that any consent decree ‘‘fairly and reasonably resolve[ ]
the controversy in a manner consistent with the public interest.’’
New York v. Microsoft Corp., 231 F. Supp. 2d 203, 205 (D.D.C.
2002) (citing Citizens for a Better Env’t v. Gorsuch, 718 F.2d 1117,
1126 (D.C. Cir. 1983)). The district court’s public-interest determi-
nation in the settling states’ case is not at issue in the current
appeals.
10

States submitted a Second Proposed Remedy (SPR), 6 J.A.
(II) at 3160-3201. The Second Revised Proposed Final Judg-
ment and the SPR are the two proposals the district court
ultimately reviewed.
After an expedited discovery schedule, the hearing on
remedies began in March 2002 and ran for 32 trial days
spanning three months, over which time the court reviewed
written direct testimony and heard live testimony from doz-
ens of witnesses.2 States’ Remedy, at 87. The district court
issued its findings of fact and its legal conclusions in a
combined opinion. The final judgment in the proceedings on
Track II — that is, the remedy adopted by the district
court — is attached as an appendix to the district court’s
opinion. See States’ Remedy, at 266-77.
Massachusetts alone among the States appeals. We ad-
dress the Commonwealth’s appeal in Part II below and
CCIA’s and SIIA’s appeal in Part III.

II. Commonwealth of Massachusetts
v. Microsoft, No. 02-7155
We review the district court’s findings of fact for clear
error, United States ex rel. Modern Elec., Inc. v. Ideal Elec.
Sec. Co., 81 F.3d 240, 244 (D.C. Cir. 1996); see also FED. R.
CIV. P. 52(a) (‘‘[f]indings of fact TTT shall not be set aside
unless clearly erroneous’’), but resolve issues of law de novo,
2 The States presented the testimony of thirteen fact witnesses:
Peter Ashkin, James Barksdale, John Borthwick, Anthony Fama,
Richard Green, Mitchell Kertzman, Dr. Carl Ledbetter, Michael
Mace, Steven McGeady, Larry Pearson, David Richards, Jonathan
Schwartz, and Michael Tiemann; and of two expert witnesses: Dr.
Andrew Appel and Dr. Carl Shapiro. Microsoft presented the
testimony of fifteen fact witnesses: Dr. James Allchin, Linda Wolfe
Averett, Scott Borduin, David Cole, Heather Davisson, Brent Frei,
William Gates III, James Thomas Greene, Chris Hofstader, Chris-
topher Jones, Will Poole, W.J. Sanders III, Robert Short, Gregg
Sutherland, and Richard Ulmer; and of four experts: Dr. John
Bennett, Dr. Kenneth Elzinga, Dr. Stuart Madnick, and Dr. Kevin
Murphy.
11

Modern Elec., Inc., 81 F.3d at 244. We review the district
court’s decision whether to grant equitable relief only for
abuse of discretion. See Microsoft III, at 105; see also Ford
Motor Co. v. United States, 405 U.S. 562, 573 (district court
‘‘clothed with ‘large discretion’ to fit the decree to the special
needs of the individual case’’).
A. Remedial Proposals
Massachusetts objects to several provisions the district
court included in the remedial decree. The Commonwealth
also appeals the district court’s refusal to adopt certain other
provisions proposed by the States.
1. Commingling
In Microsoft III we upheld the district court’s finding that
Microsoft’s integration of IE and the Windows operating
system generally ‘‘prevented OEMs from pre-installing other
browsers and deterred consumers from using them.’’ 253
F.3d at 63-64. Because they could not remove IE, installing
another browser meant the OEM would incur the costs of
supporting two browsers. Id. at 64. Accordingly, OEMs had
little incentive to install a rival browser, such as Netscape
Navigator. Relying upon the district court’s findings of fact,
we determined that Microsoft took three actions to bind IE to
Windows: (1) it excluded IE from the ‘‘Add/Remove Pro-
grams’’ utility; (2) it commingled in the same file code related
to browsing and code used by the operating system so that
removal of IE files would cripple Windows; and (3) it de-
signed Windows in such a manner that, in certain circum-
stances, a user’s choice of an internet browser other than IE
would be overridden. Id. at 64-65. Although all three acts
had anticompetitive effects, only the first two had no offset-
ting justification and, therefore, ‘‘consitute[d] exclusionary
conduct[ ] in violation of § 2.’’ Id. at 67. As for overriding
the user’s choice of an internet browser, we held the plaintiffs
had neither rebutted Microsoft’s proffered technical justifica-
tion nor demonstrated that its justification was outweighed by
the anticompetitive effect. We therefore concluded Microsoft
was not ‘‘liable for this aspect of its product design.’’ Id.
12

On remand, turning to the commingling of IE and Windows
code, the district court stated that an appropriate remedy
‘‘must place paramount significance upon addressing the ex-
clusionary effect of the commingling, rather than the mere
conduct which gives rise to the effect.’’ States’ Remedy, at
156. The court was concerned about adopting any remedy
that would require Microsoft to remove Windows software
code — as the States’ proposed remedy would do — based
upon what it perceived to be a very difficult, even if not
‘‘technologically impossible,’’ task. Id. at 157. For instance,
the court found the States did not offer a reasonable method
of distinguishing ‘‘operating system’’ code from ‘‘non-
operating system’’ code, such as code that provides middle-
ware functionality.3 Id. Moreover, based upon ‘‘testimony of
various [independent software vendors (ISVs)] that the quali-
ty of their products would decline if Microsoft were required
to remove code from Windows,’’ the court concluded both
ISVs and consumers would be harmed if Microsoft were
forced to redesign Windows by removing software code. Id.
at 158. Finally, the district court was alert to ‘‘the admoni-
tion [in the case law] that it is not a proper task for the Court
to undertake to redesign products.’’ Id.; see also United
States v. Microsoft Corp., 147 F.3d 935, 948 (D.C. Cir. 1998)
(Microsoft II) (‘‘Antitrust scholars have long recognized the
undesirability of having courts oversee product design’’). Ac-
cordingly, the district court instead approved the proposed
requirement that Microsoft ‘‘permit OEMs to remove end-
3 As we explained in Microsoft III, the term ‘‘middleware’’
refers to software products that expose their ‘‘Applications Pro-
gramming Interfaces,’’ upon which software developers rely in
writing applications. 253 F.3d at 53; see also Findings of Fact
¶ 28, at 17. The middleware at issue in Microsoft III was primarily
web-browsing software. The district court’s remedy in this case,
however, covers a far broader array of middleware. Accordingly,
the district court was at pains to define Microsoft’s middleware and
that of its rivals. See States’ Remedy §§ VI.J, VI.K, VI.M, VI.N, at
275-76. We need not here recount the district court’s extensive
treatment of those definitions, see States’ Remedy, at 112-21, but
the definitions are discussed as needed below.
13

user access to aspects of the Windows operating system
which perform middleware functionality.’’ States’ Remedy, at
159. Specifically, § III.H of the decree requires Microsoft to
‘‘[a]llow end users TTT and OEMs TTT to enable or remove
access to each Microsoft Middleware Product or Non-
Microsoft Middleware Product TTTT’’ Id. at 270.
Massachusetts maintains the district court erred by ad-
dressing the remedy to the exclusionary effect of comming-
ling and not to the commingling itself. In response, Micro-
soft points out that in the liability proceedings the plaintiffs
were concerned primarily with end-user access and that the
decree originally entered by the district court likewise ad-
dressed Microsoft’s binding its middleware to its operating
system; the remedy was to allow both OEMs and end users
to remove access to Microsoft middleware. Remedy I, at 68.
That is why on remand the district court observed that
‘‘[n]othing in the rationale underlying the commingling liabili-
ty finding requires removal of software code to remedy the
violation.’’ States’ Remedy, at 158. We agree; the district
court’s remedy is entirely consistent with its earlier finding
that ‘‘from the user’s perspective, uninstalling Internet Ex-
plorer [with the Add/Remove Programs utility is] equivalent
to removing the Internet Explorer program from Windows.’’
Findings of Fact ¶ 165, at 51.
The district court’s decision to fashion a remedy directed at
the effect of Microsoft’s commingling, rather than to prohibit
commingling, was within its discretion. The end-user access
provision does this, and it avoids the drawbacks of the States’
proposal requiring Microsoft to redesign its software. Allow-
ing an OEM to block end-user access to IE gives the OEM
control over the costs associated with supporting more than
one internet browser. Indeed, had Microsoft not removed IE
from the Add/Remove Programs utility in the first place,
OEMs would have retained a simple and direct method of
avoiding such costs. See, e.g., Direct Testimony of Dr. Stuart
Madnick ¶ 177, 5 J.A. (II) at 2887.
Massachusetts says there is unrebutted testimony in the
record indicating the removal of end-user access is insuffi-
14

cient ‘‘to reduce OEMs’ disincentives to install rival middle-
ware.’’ Not so. The cited testimony is that end-users ‘‘may
accidentally trigger one program when they mean to trigger
another. This is especially so when, under Microsoft’s Pro-
posed Remedy, Windows is allowed to launch Microsoft mid-
dleware on a system on which a consumer has not chosen
Microsoft’s program to be the default version of the applica-
tion.’’ Direct Testimony of Peter Ashkin ¶ 78, 5 J.A. (II) at
3100; see also ¶¶ 77, 79-80, id. at 3100-01. First, this testimo-
ny indicates only that removal of end-user access to IE may
not eliminate every last ‘‘accidental’’ invocation of IE, not that
the incidence will not be reduced, as it no doubt will be.
Second, under § III.H.2 end users and OEMs may ‘‘designate
a Non–Microsoft Middleware Product to be invoked in place
of [a] Microsoft Middleware Product TTT in any case where
the Windows Operating System Product would otherwise
launch the Microsoft Middleware Product TTT,’’ States’ Reme-
dy § III.H.2, at 270-71, which apparently provides OEMs a
method to address the conduct about which Massachusetts is
concerned.
Finally, the accidental invocations claimed in the cited
testimony do not reflect the nature of the concerns OEMs
had at the time the district court made its Findings of Fact.
The district court found Microsoft had combined commingling
of code and removal of IE from the Add/Remove Programs
utility in a manner that ensured the presence of IE on the
Windows desktop. See Findings of Fact ¶ 241, at 69. The
lack of any way to remove end-user access to IE — now
squarely addressed in § III.H of the decree — made the IE
icon an ‘‘unavoidable presence’’ on the Windows desktop; that
was what led ‘‘to confusion among novice users.’’ Id. ¶ 217, at
63. More, that is, was involved than the occasional invocation
of IE by accident; IE was always present because Microsoft
prevented OEMs from removing both the code and the end-
user’s access to it. The accidental invocations of Microsoft
middleware claimed in the Ashkin testimony — to the extent
not already resolved by § III.H.2 — are hardly likely to
generate the level of support costs OEMs faced when the IE
15

icon was on every desktop. Certainly the cited testimony is
no evidence of such significant costs.
The district court fashioned a remedy aimed at reducing
the costs an OEM might face in having to support multiple
internet browsers. The court thereby addressed itself to
Microsoft’s efforts to reduce software developers’ interest in
writing to the Application Program Interfaces (APIs) exposed
by any operating system other than Windows. Far from
abusing its discretion, therefore, the district court, by reme-
dying the anticompetitive effect of commingling, went to the
heart of the problem Microsoft had created, and it did so
without intruding itself into the design and engineering of the
Windows operating system. We say, Well done!
But soft! Massachusetts and the amici claim the district
court nonetheless erred in rejecting a ‘‘code removal’’ remedy
for Microsoft’s commingling, principally insofar as the court
was concerned with ‘‘Microsoft’s ability to provide a consis-
tent API set,’’ which Microsoft referred to as the problem of
Windows’ ‘‘fragmentation.’’4 They argue that any effort to
keep software developers writing to Microsoft’s APIs — and
thereby avoiding ‘‘fragmentation’’ — is not procompetitive but
rather ‘‘an argument against competition.’’
The district court raised its concern about fragmentation in
connection with the States’ proposal that Microsoft be re-
quired to remove its middleware code from the code of its
Windows operating system, as follows:
Microsoft shall not, in any Windows Operating System
Product TTT it distributes TTT Bind any Microsoft Mid-
dleware Product to the Windows Operating System un-
less Microsoft also has available to license, upon the
4 Massachusetts also argues the district court erred insofar as
it rejected the States’ proposal because the proposal did not provide
adequate guidance for determining which code constitutes Microsoft
middleware and was otherwise too difficult technically. The district
court’s findings, however, discussed in part at the outset of this
section, fully support its reasons for rejecting the States’ unbinding
remedy. See States’ Remedy, 245-52; see also id. at 255.
16

request of any Covered OEM licensee or Third-Party
Licensee, and supports both directly and indirectly, an
otherwise identical but ‘‘unbound’’ Windows Operating
System Product TTTT
SPR § 1, 6 J.A. (II) at 3166. In other words, Microsoft
would be required to make it possible for OEMs and end
users to ‘‘readily remove or uninstall [from Windows] the
binary code’’ of any Microsoft Middleware Product (as that
term is defined in the States’ proposal). Id. §§ 22.d & 22.e, 6
J.A. (II) at 3193. The district court found evidence the
States’ proposal ‘‘would hinder, or even destroy Microsoft’s
ability to provide a consistent API set.’’ States’ Remedy, at
252. This evidence included testimony that it would be
impossible for Microsoft to maintain the same high level
of operating-system balance and stability on which soft-
ware developers and customers rely. Developers will be
less likely to write software programs to an unstable or
unpredictable operating system based on the risk that
their programs will not function as designed, thereby
reducing customer satisfaction.
Direct Testimony of Scott Borduin ¶ 61, 2 J.A. (II) at 1327.5
The district court concluded, ‘‘The weight of the evidence
indicates the fragmentation of the Windows platform would
be significantly harmful to Microsoft, ISVs, and consumers.’’
States’ Remedy, at 253.
Massachusetts argues the district court’s finding ‘‘ignores
and is at odds with this Court’s holding that Microsoft’s
desire to keep developers focused on its APIs was merely
another way of saying it ‘wants to preserve its power in the
operating system market,’ ’’ citing Microsoft III, at 71. In-
deed, as we stated in Microsoft III, ‘‘Microsoft’s only explana-
5 See also Madnick ¶ 197, 5 J.A. (II) at 2899 (‘‘To the extent
that licensees used the non-settling States’ remedies to create
multiple versions of Windows with differing combinations of APIs,
applications developers and consumers would lose one of the great-
est benefits of Windows — a platform for applications that supports
new functionality while providing backward compatibility for most
existing applications’’).
17

tion for its exclusive dealing [contracts with Internet Access
Providers (IAPs)] is that it wants to keep developers focused
upon its APIs — which is to say, it wants to preserve its
power in the operating system market.’’ Id. We went on to
state, however, that this ‘‘is not an unlawful end, but neither
is it a procompetitive justification for the specific means here
in question, namely, exclusive dealing contracts with IAPs.’’
Id.
Massachusetts would turn our observation about Micro-
soft’s rationale for its exclusive contracts with IAPs into a
critique of the district court’s concern with the extreme
fragmentation of Windows the court found was likely to occur
if it adopted the States’ code removal proposal. But the two
points cannot be equated. The States made a proposal the
district court found might have resulted in there being ‘‘more
than 1000’’ versions of Windows. See States’ Remedy, at 253
(citing Direct Testimony of Dr. John Bennett ¶¶ 47, 55, 5 J.A.
(II) at 2997-98, 3001). Letting a thousand flowers bloom is
usually a good idea, but here the court found evidence, as
discussed above, that such drastic fragmentation would likely
harm consumers. See also Direct Testimony of Dr. Kenneth
Elzinga ¶ 102, 5 J.A. (II) at 2739-40 (‘‘Lowering barriers to
entry by destroying TTT real benefits TTT harms consumers
and is not pro-competitive’’). Although it is almost certainly
true, as both Massachusetts and the amici claim, that such
fragmentation would also pose a threat to Microsoft’s ability
to keep software developers focused upon its APIs, address-
ing the applications barrier to entry in a manner likely to
harm consumers is not self-evidently an appropriate way to
remedy an antitrust violation. See Brooke Group Ltd. v.
Brown & Williamson Tobacco Corp., 509 U.S. 209, 224 (1993)
(‘‘It is axiomatic that the antitrust laws were passed for ‘the
protection of competition, not competitors,’ ’’ quoting Brown
Shoe Co. v. United States, 370 U.S. 294, 320 (1962) (emphases
in original)).
The district court’s end-user access provision fosters com-
petition by opening the channels of distribution to non-
Microsoft middleware. It was Microsoft’s foreclosure of
those channels that squelched nascent middleware threats
18

and furthered the dominance of the API set exposed by its
operating system. The exclusive contracts into which Micro-
soft entered with IAPs were likewise aimed at foreclosing
channels through which rival middleware might otherwise
have been distributed. Prohibiting Microsoft from continuing
those exclusive arrangements, see States’ Remedy § III.G, at
269-70, would not have the same deleterious effect upon
consumers as would the fragmentation of Windows.
Amici CCIA and SIIA seem to view fragmentation as
merely competition by another name. Accordingly, they see
fragmentation as a natural, if only temporary, consequence of
economic forces: ‘‘Competition of any kind will lead to a
multiplicity of standards, at least temporarily.’’ The redesign
of Windows required by the States’ proposal, however, would
not be the result of competition on the merits, as CCIA and
SIIA seem to suggest. Certainly they point to no economic
force that would prompt (or, if such a redesign were mandat-
ed, sustain) the degree of fragmentation the States’ proposal
is predicted to produce. Nor do they explain how such
fragmentation would, as they claim, ‘‘spark innovation that
benefits consumers.’’ They instead quote National Society of
Professional Engineers (NSPE) v. United States, 435 U.S.
679, 689 (1978), for the proposition that the Supreme Court
has ‘‘foreclose[d] the argument that because of the special
characteristics of a particular industry, monopolistic arrange-
ments will better promote trade and commerce than competi-
tion.’’ But that case provides no support for CCIA’s and
SIIA’s argument here. Like the two cases the Supreme
Court cited in making the statement just quoted, see United
States v. Trans-Missouri Freight Ass’n, 166 U.S. 290 (1897);
and United States v. Joint Traffic Ass’n, 171 U.S. 505 (1898),
NSPE involved an agreement among competitors limiting the
output of their services. Those arrangements, which were
analyzed under § 1 of the Sherman Act, are not analogous to
Microsoft’s monopoly of the market for operating systems,
which is due not only to the exclusionary practices we found
unlawful in Microsoft III but also to ‘‘positive network ef-
fects,’’ see Findings of Fact, at 20. Moreover, in NSPE the
district court made no findings there were any potential
19

benefits from the profession’s ‘‘ethical prohibition against
competitive bidding.’’ 435 U.S. at 686. In sharp contrast,
here the district court made extensive findings both about the
potential harm to consumers from fragmentation and about
the dubious benefits of the States’ proposal.6 From these
findings the court concluded, ‘‘There is no indication that
there is any competitive or economic advantage to [the degree
of fragmentation entailed in the States’ proposal] and, quite
to the contrary, such a result would likely be detrimental to
the consumer.’’ States’ Remedy, at 252-54. Although we
understand that competition on the merits itself would likely
elicit multiple standards — recall the competition between the
VHS and Beta videotape standards — or even that some as
yet unimagined technology might reduce the harm to consum-
ers from fragmentation, CCIA and SIIA fail to demonstrate
the district court was unduly concerned about the extent of
fragmentation likely to arise from the States’ proposal.
Finally, Massachusetts argues the district court’s findings
relating to fragmentation ‘‘fail to respect’’ the findings of fact
made in the liability proceedings. Specifically, the Common-
wealth points to Findings of Fact ¶ 193, at 56-57: ‘‘Micro-
soft’s contention that offering OEMs the choice of whether or
not to install certain browser-related APIs would fragment
the Windows platform is unpersuasive.’’ That statement was
addressed to the unbinding of IE and Windows, not to the
States’ proposal, from which the court anticipated far more
extensive fragmentation. The district court’s rejection of the
States’ proposal, therefore, is not inconsistent with any of the
findings of fact in the liability proceedings.
6 For example, the court found that ISVs would ‘‘fare worst’’
under the proposal because they ‘‘would not have any assurance
that a particular functionality was present in any given configura-
tion of the new unbound Windows [which,] at least in the short term
TTT would likely cause existing applications to fail. [In the longer
run there is the risk that] software code distributed with one ISV’s
application would conflict with that distributed with another ISV’s
application, leading to the so-called ‘DLL Hell’ problem that results
when multiple versions of the same basic components try to coexist
on a single PC.’’ States’ Remedy, at 253-54.
20

Relatedly, the amici point to ‘‘Microsoft’s own fragmenta-
tion’’ of Windows through the publication of successive ver-
sions, such as Windows 98, Windows 2000, and Windows XP.
The district court addressed this concern and found such
fragmentation to be of ‘‘relatively small degree’’ because
‘‘Microsoft is able to work towards maintaining backward
compatibility with previous versions.’’ States’ Remedy, at
253.
To be sure, the remedy the district court adopted does not
prevent all fragmentation of the Windows operating system;
indeed, it adopted the end-user access provision, which allows
OEMs to install rival browsers and other non-Microsoft mid-
dleware, with their associated APIs, and to remove the end
user’s access to IE. Accordingly, fragmentation may yet
occur, but if so it will be caused by OEMs competing to
satisfy the preferences of end users, not forced artificially
upon the market as it would be under the States’ proposal.
2. Java deception
Massachusetts argues the district court erred in not includ-
ing a remedy addressed specifically to Microsoft’s deception
of Java software developers. Unbeknownst to Java software
developers, Microsoft’s Java developer tools included certain
words and directives that could be executed only in Windows’
Java runtime environment. We held this deception ‘‘served
to protect [Microsoft’s] monopoly of the operating system in a
manner not attributable either to the superiority of the
operating system or to the acumen of its makers, and there-
fore was anticompetitive.’’ Microsoft III, at 77. Because
Microsoft failed to provide a procompetitive explanation for
its deception of software developers — indeed, there appears
to be no purpose at all for the practice that would not itself be
anticompetitive — we held its conduct was exclusionary, in
violation of § 2 of the Sherman Act. Id.
On remand the district court found a lack of ‘‘any evidence’’
Microsoft’s previous Java deception was a continuing threat
to competition. States’ Remedy, at 265. The Java deception
‘‘concern[ed] a single, very specific incident of anticompetitive
conduct by Microsoft,’’ which conduct Microsoft had ceased in
21

accordance with a consent decree into which it had entered in
another case in another court. Id. For these reasons, the
district court did not include a provision in the remedial
decree addressed to this unlawful but now terminated con-
duct.
Massachusetts, quoting United States v. W.T. Grant Co.,
345 U.S. 629, 632 (1953), claims that without specific relief
prohibiting such deception, Microsoft is ‘‘free to return to [its]
old ways.’’ Microsoft responds that Massachusetts does not
make a showing of the type of abuse contemplated by the
Supreme Court in W.T. Grant. We agree. That case in-
volved an interlocking directorate allegedly unlawful under
§ 8 of the Clayton Act. Soon after the Government filed suit,
the common director voluntarily resigned from the relevant
boards, after which the district court refused the Govern-
ment’s request for an injunction prohibiting him and the
corporations from violating § 8 in the future. The Supreme
Court held the defendants’ sworn profession of an intention
not to revive the interlock was insufficient to moot the case.
However, the Court also held — and this is key — the district
court was in the best position to determine whether there was
a ‘‘significant threat of [a] future violation,’’ and it had not
abused its discretion in refusing to award injunctive relief.
Id. at 635-36. Far from supporting Massachusetts’ argument,
therefore, W.T. Grant confirms the district court’s broad
discretionary power to withhold equitable relief as it reason-
ably sees fit.
Massachusetts maintains the district court abused its dis-
cretion insofar as it found ‘‘no evidence that this deception, or
any similar deception, has persisted.’’ States’ Remedy, at
190. Massachusetts here claims Microsoft’s Chairman and
Chief Software Architect, William Gates III, in testimony
‘‘admitted that Microsoft routinely makes knowingly inaccu-
rate claims regarding its compliance with industry stan-
dards,’’ into which the district court should have inquired
further. The cited testimony in fact concerns Microsoft’s
efforts to comply with frequently changing standards.7 Not
7 See 4/24/02 pm Tr. at 4988-89 (Gates trial testimony), 6 J.A.
(II) at 3141-42; see also Direct Testimony of Dr. Andrew Appel
22

surprisingly, nothing Gates said suggests anything in the
least nefarious.
Despite its failure to demonstrate any continuing competi-
tive threat from Microsoft’s previous deception of Java soft-
ware developers, Massachusetts presses the States’ proposed
‘‘truth in standards’’ provision, which would regulate certain
business practices that were not at issue in Microsoft III.
Specifically, the States’ proposal would require Microsoft to
(1) continue supporting any industry standard it has publicly
claimed to support ‘‘until it publicly disclaims such support or
the standard itself expires or is rescinded by the standard-
setting body,’’ and (2) ‘‘continue to support an industry stan-
dard any time it makes a proprietary alteration to the stan-
dard.’’ Id. at 190; see also SPR § 16, 6 J.A. (II) at 3183. As
an initial matter, our holding the district court did not abuse
its discretion in refusing to enjoin a recurrence of Microsoft’s
Java deception casts grave doubt upon the need for a broad
provision applicable not only to Java but to all industry
standards. Be that as it may, we address Massachusetts’
arguments in favor of such a provision.
First Massachusetts claims the district court erred as a
matter of law insofar as it regarded the proposed truth-in-
standards provision as being ‘‘unrelated to the violation found
by th[is] court.’’ That is not, however, how the district court
saw the matter. Addressing only the first requirement quot-
ed in the previous paragraph, the district court specifically
referred to Microsoft’s deception of Java developers in hold-
ing there was no showing a ‘‘broad order’’ prohibiting any
similar deception was ‘‘either appropriate or necessary.’’ See
States’ Remedy, at 190. It never said that requirement was
‘‘unrelated’’ to the violations found by this court in Microsoft
III. That much we think is unarguable.
As Microsoft correctly points out, it was the second aspect
of the truth-in-standards provision the district court deemed
‘‘unrelated to any finding of liability,’’ id. at 190, 263-64, and

¶ 145, 2 J.A. (II) at 1303-04 (stating Microsoft has ability to mislead
third parties with respect to standards, but giving neither instances
nor any indication of likelihood of such conduct).
23

correctly so. Indeed, this court held that Microsoft’s develop-
ment of the Windows Java Virtual Machine (JVM), which was
incompatible with Sun’s JVM, did not violate the antitrust
laws. Microsoft III, at 75. It was only Microsoft’s having
misled software developers into thinking the two were com-
patible that had an anticompetitive effect. Id. at 76-77. We
therefore hold the district court permissibly refused to re-
quire that Microsoft continue to support a standard after
making a proprietary modification to it, even if the modifica-
tion makes the standard incompatible with the original.
Massachusetts also complains the record does not support
the district court’s other reasons for rejecting the proposed
truth-in-standards provision. We disagree. The district
court found no evidence the ‘‘industry standard’’ provision
would ‘‘enhance competition in the monopolized market’’ for
Intel-compatible PC operating systems. States’ Remedy, at
264 & n.134. Compliance with industry standards is ‘‘largely
a subjective undertaking,’’ id. at 190, such that ‘‘full compli-
ance with a standard is often a difficult and ambiguous
process,’’ id. at 264 (quoting Madnick ¶ 208, 5 J.A. (II) at
2905). Massachusetts points to no specific instance in which
competition would have been or would be enhanced by com-
pelling Microsoft to support an industry standard after it
made a proprietary alteration thereto. Instead Massachu-
setts invokes expert testimony that Microsoft’s proprietary
control over ‘‘important interfaces’’ would make it ‘‘harder’’
for rival operating systems to compete with Windows. Direct
Testimony of Dr. Carl Shapiro ¶ 185, 2 J.A. (II) at 860. This
is far too general a statement from which to infer the
proposed truth-in-standards provision would enhance compe-
tition rather than merely assist competitors — and perhaps
retard innovation. The district court found that industry
standards can ‘‘vary widely in complexity and specificity, such
that various implementations of a particular standard are
often incompatible.’’ States’ Remedy, at 264 (quoting Mad-
nick ¶ 207, 5 J.A. (II) at 2904). Microsoft, therefore, may not
be able to comply with some of the industry standards
contemplated by the States’ proposal. And the States’ own
economic expert testified that ‘‘slow-moving standards bod-
24

ies’’ are commonly unable to keep up with rapidly changing
technology markets. 4/14/02 pm Tr. at 3677 (Shapiro trial
testimony), 8 J.A. (II) at 4572; see also CARL SHAPIRO & HAL
R. VARIAN, INFORMATION Rules 240 (1999) (advocating business
strategy that does not ‘‘freeze TTT activities during the slow
standard-setting process’’).
The district court aptly described the problems with the
States’ truth-in-standards proposal and correctly concluded
the proposed remedy went beyond the liability contemplated
by this court. The court did not abuse its discretion, there-
fore, in refusing to adopt the proposal.
3. Forward-looking provisions
The district court exercised its discretion to fashion appro-
priate relief by adopting what it called ‘‘forward-looking’’
provisions, which require Microsoft to disclose certain of its
APIs and communications protocols. Although non-
disclosure of this proprietary information had played no role
in our holding Microsoft violated the antitrust laws, ‘‘both
proposed remedies recommend[ed] the mandatory disclosure
of certain Microsoft APIs, technical information, and commu-
nications protocols for the purposes of fostering interopera-
tion.’’ States’ Remedy, at 171. In approving a form of such
disclosure — while, as discussed below, rejecting the States’
proposal for vastly more — the district court explained ‘‘the
remedy [must] not [be] so expansive as to be unduly regulato-
ry or provide a blanket prohibition on all future anticompeti-
tive conduct.’’ Id. (citing Zenith Radio Corp. v. Hazeltine
Research, Inc., 395 U.S. 100, 133 (1969)). We are also
mindful that, although the district court is ‘‘empowered to
fashion appropriate restraints on [Microsoft’s] future activi-
ties both to avoid a recurrence of the violation and to elimi-
nate its consequences,’’ NSPE, 435 U.S. at 697, the resulting
relief must ‘‘represent[ ] a reasonable method of eliminating
the consequences of the illegal conduct,’’ id. at 698.
a. Disclosure of APIs
The district court recognized the ‘‘hallmark of the platform
threat’’ to the Windows monopoly posed by rival middleware
25

is the ability to run on multiple operating systems: The
‘‘ready ability to interoperate with the already dominant
operating system will bolster the ability of such middleware
to support a wide range of applications so as to serve as a
platform.’’ States’ Remedy, at 172. In order to facilitate
such interoperation the district court required Microsoft to
disclose APIs ‘‘used by Microsoft Middleware to interoperate
with a Windows Operating System Product.’’ Id. § III.D, at
268.
Massachusetts objects to this provision on several grounds.
First, the Commonwealth argues ‘‘the middleware covered by
§ III.D lacks the platform potential of the middleware threat
that Microsoft thwarted’’ and, therefore, ‘‘will necessarily be
inadequate to restore competition.’’ The validity of Massa-
chusetts’ objection depends upon the meaning of ‘‘Microsoft
Middleware.’’
Microsoft Middleware is defined as ‘‘software code’’ that:
1. Microsoft distributes separately from a Windows Op-
erating System Product to update that Windows
Operating System Product;
2. is Trademarked or is marketed by Microsoft as a
major version of any Microsoft Middleware Product
TTT; and
3. provides the same or substantially similar functionali-
ty as a Microsoft Middleware Product.
Id. § VI.J, at 275. A ‘‘Microsoft Middleware Product’’ in-
cludes, among other things, ‘‘the functionality provided by
Internet Explorer, Microsoft’s Java Virtual Machine, Win-
dows Media Player, Windows Messenger, Outlook Express
and their successors in a Windows Operating System Prod-
uct.’’ Id. § VI.K, at 275.
In support of its argument, Massachusetts notes that Mi-
crosoft’s own experts ‘‘doubted the platform potential of
several forms of middleware included in what became the
remedy’s definition.’’8 In response, Microsoft points out that
8 E.g., Direct Testimony of Dr. Kevin Murphy ¶ 176, 5 J.A. (II)
at 2648 (‘‘the definition of ‘Middleware’ includes some products that
26

the definition of ‘‘Microsoft Middleware’’ adopted by the
district court is not faulty simply because Microsoft’s experts
discounted as platform threats some of the middleware prod-
ucts it covers. The logic of that response is obvious, which
makes it unsurprising that Massachusetts makes no reply.
Amici CCIA and SIIA take a different tack, claiming the
definition is defective because Microsoft itself determines
which software code to distribute separately. Microsoft re-
sponds that the amici ‘‘ignore[ ] the thousands of Windows
APIs that Microsoft publicly discloses in the ordinary course
of business,’’ and cites testimony, most of it conclusory,
extolling the adequacy of those APIs for software developers.
See, e.g., Direct Testimony of Brent Frei of Onyx Software
¶¶ 18-22, 6 J.A. (II) at 3413-15; Direct Testimony of Chris
Hofstader of Freedom Scientific ¶¶ 57-59, 9 J.A. (II) at 5453-
55. Be that as it may, the district court considered argu-
ments by the States similar to the one now advanced by the
amici, and it rejected the related testimony of the States’
witnesses. States’ Remedy, at 116-17. The court instead
found ‘‘Microsoft often distributes separately certain technol-
ogies which are included in new releases of Windows because
such distribution enables users of previous Windows versions
to take advantage of the latest improvements to these tech-
nologies.’’ Id. at 117 (citing Direct Testimony of Microsoft’s
Christopher Jones ¶ 61, 5 J.A. (II) at 2532, and Will Poole
¶ 76, 5 J.A. (II) at 2493). The court explained:
Such distribution benefits Microsoft, as it permits Micro-
soft to continually improve the quality of its products,
even after they are sold, and to expand the user base of
new technology without waiting for consumers to pur-
chase an entirely new operating system.
Id. These benefits would be lost to Microsoft if it were to
‘‘manipulate its products to exclude specific code from the
definition’’ of middleware. Id.

pose no apparent (even nascent) threat to the operating system’’);
Elzinga ¶ 135, id. at 2754 (‘‘particularly implausible that an email
client (such as Outlook Express) or instant messaging software
(such as Windows Messenger) will become a platform threat’’).
27

The amici do not deny Microsoft has routinely distributed
its middleware separately from Windows. Instead, they
speculate Microsoft may henceforth avoid separate distribu-
tion in order to avoid the disclosure contemplated by § III.D.
They claim an expanded definition of middleware, such as
that proposed by the States, is necessary to ‘‘prevent[ ]
Microsoft from defining its obligations into meaningless su-
perficiality.’’
Microsoft points to the district court’s finding, supported by
evidence in the record, that it is not necessary or even
desirable, in order to remove the artificial impediments erect-
ed by Microsoft to the establishment of a platform threat to
Windows, to expand the definition of Microsoft middleware to
cover all software that ‘‘expose[s] even a single API.’’ Id. at
118-19. The district court rejected the States’ broader defini-
tion of middleware in part because it wanted ‘‘bright lines by
which Microsoft can determine what portions of Windows
code are affected by the remedy.’’ Id. at 117. The amici do
not respond to the district court’s concerns about the expan-
sive scope of the States’ definition of middleware. Nor do
they explain how the States’ proposal would ‘‘identify the
specific pieces of Windows,’’ id., constituting middleware for
the purpose of Microsoft’s disclosure obligation. Instead,
they merely claim the States’ proposal ‘‘add[s] sufficient
precision to identify and enforce a concrete obligation.’’ This
unreasoned assertion is hardly a ground upon which to over-
turn the district court’s reasoned explanation for adopting a
‘‘bright line[ ]’’ approach to Microsoft’s disclosure obligation.
Further, the amici fail to refute the district court’s reasoning
that ‘‘economic forces TTT countervail the likelihood’’ that
Microsoft would stop separately distributing its software code
in order to avoid having to disclose APIs pursuant to § III.D.
Id.
We hold the district court did not abuse its discretion in
delineating the middleware covered for the purposes of disclo-
sure. As discussed, the term ‘‘Microsoft Middleware’’ both
includes and extends beyond the functionality of the middle-
ware at issue in this case. Id. §§ VI.J & VI.K, at 275-76; see
also id. at 115. The amici merely speculate that the middle-
28

ware covered by § III.D will not provide a serious platform
threat. Moreover, the district court’s reasons for believing
economic self-interest deters Microsoft from avoiding sepa-
rate distribution of its software code are persuasive. And we
should be particularly disinclined to require more disclosure
where, as here, the district court is adopting a forward-
looking provision addressing conduct not previously held to
be anticompetitive. See generally, Frank H. Easterbrook,
The Limits of Antitrust, 63 TEX. L. REV. 1, 14-15 (1984)
(supporting use of presumptions in antitrust law to avoid
condemning procompetitive practices). Nonetheless, out of
an abundance of caution the district court provided that, in
the event Microsoft were to ‘‘make a practice’’ of sacrificing
the advantages of separate distribution in order to frustrate
the purpose of the remedy, Massachusetts ‘‘could petition the
Court for relief on this point.’’9 States’ Remedy, at 117 n.34.
9 Massachusetts also argues the district court abused its discre-
tion by refusing to define Microsoft’s Common Language Runtime
(CLR) as a Microsoft Middleware Product and hence subject to the
API-disclosure requirement of § III.D. The district court de-
scribed the CLR as middleware similar to Java but a part of
Microsoft’s new ‘‘.NET framework,’’ a Web-services initiative com-
prising ‘‘server-based applications that can be accessed directly by
other software programs, as well as by the consumer through a
variety of devices, including the PC, cellular phone, and handheld
device.’’ States’ Remedy, at 126; see also Borduin ¶ 80, 2 J.A. (II)
at 1333 (explaining importance of CLR in .NET initiative). As
discussed in Part II.A.4 below, the district court refused to address
Web services in the remedial decree, stating that ‘‘this case cannot
be used as a vehicle by which to fight every potential future
violation of the antitrust laws by Microsoft envisioned by Micro-
soft’s competitors.’’ States’ Remedy, at 133. Just so, and the
district court therefore did not abuse its discretion by refusing to
list the CLR along with the other functionalities specified in the
definition of Microsoft Middleware Product. See id. at 275. Be-
cause Microsoft’s Web-services initiative and Microsoft Middleware
are not mutually exclusive categories, however, the CLR may yet
become subject to the disclosure requirement of § III.D if it
satisfies the definition of Microsoft Middleware in the decree, see
States’ Remedy § VI.J, at 275. That definition requires, among
29

Massachusetts further argues the district court made no
finding the required disclosure of APIs under the decree
would ‘‘meaningfully assist’’ developers of middleware. Mas-
sachusetts objects both to the breadth of disclosure — that is,
the number of APIs to be disclosed under § III.D — and to
the ‘‘depth’’ or detail of the disclosure, with respect to which
Massachusetts claims ‘‘the remedy fails to require the disclo-
sure of sufficient information to ensure that the mandated
disclosure may be effectively utilized.’’
As to breadth, § III.D by its terms expands the scope of
required disclosure beyond the functionality of the middle-
ware at issue in our decision on liability, as discussed above.
Such expanded but not unlimited disclosure ‘‘represents a
reasonable method’’ of facilitating the entry of competitors
into a market from which Microsoft’s unlawful conduct previ-
ously excluded them, NSPE, 435 U.S. at 698, particularly in
view of the inherently uncertain nature of this forward-
looking provision.
Moreover, in laying claim to still broader disclosure of
APIs, Massachusetts simply ignores the district court’s find-
ings with respect to the economic and technological effects of
disclosure. As Microsoft points out, however, these findings
reflect the district court’s concern that a forward-looking
provision requiring overly broad disclosure could undermine
Microsoft’s incentive to innovate and, more particularly, that
the States’ proposed disclosure provision could enable com-
petitors to ‘‘clone’’ Windows. The extremely broad scope of
the States’ proposal bears out the district court’s concern.
First, ‘‘interoperate’’ is defined in a way that makes it essen-
tially synonymous with ‘‘interchange.’’ See States’ Remedy,
at 227 (citing Madnick ¶ 86, 5 J.A. (II) at 2836-37). Mean-
while, § 4 of the SPR would require Microsoft to disclose ‘‘all
APIs’’ that enable any ‘‘Microsoft Middleware Product,’’ Mi-
crosoft application, or Microsoft software program to interop-
erate with ‘‘Microsoft Platform Software.’’ 6 J.A. (II) at

other things, the middleware to be ‘‘distribute[d] separately’’ from
Windows; according to Microsoft’s counsel at oral argument, there
is record evidence that has already occurred.
30

3172-73. Finally, ‘‘Microsoft Middleware Product’’ and ‘‘Mi-
crosoft Platform Software’’ are defined so broadly that, when
required to ‘‘interoperate’’ with one another, they include
essentially any two pieces of Microsoft software on a PC. See
States’ Remedy, at 227-28; see also Gates ¶ 296, 8 J.A. (II) at
4772-73; Madnick ¶¶ 148-49, 151, 5 J.A. (II) at 2870, 2872. As
a result, the district court found the broad scope of the APIs
required to be disclosed under the States’ proposal would give
rivals the ability to clone Microsoft’s software products;10 and
cloning would allow them to ‘‘mimic’’ the functionality of
Microsoft’s products rather than to ‘‘create something new.’’
States’ Remedy, at 229. They could also ‘‘develop products
that implement Microsoft’s Windows technology at a far
lower cost [than Microsoft itself] since they would have access
to all of Microsoft’s research and development investment.’’
Id. The effect upon Microsoft’s incentive to innovate would
be substantial; not even the broad remedial discretion en-
joyed by the district court extends to the adoption of provi-
sions so likely to harm consumers.
The amici claim the district court’s ‘‘concern about ‘cloning’
TTT rested in part on a misunderstanding of what an API is.’’
This assertion is simply at odds with the testimony upon
which the district court relied in concluding competitors could
clone Microsoft’s software and mimic its functionality.11
Moreover, the amici fail entirely to address the district
court’s conclusion, based upon findings of fact, that cloning
10 See, e.g., States’ Remedy, at 227 (citing 5/10/02 pm Tr. at
7111-12 (Bennett trial testimony), 6 J.A. (II) at 3596 (‘‘Well, if you
read [the definition of Interoperate], it says: Effectively, access,
utilize and/or support the full features and functionality of one
another. That, to me, taken in its entirety TTT means the ability to
clone.’’)).
11 See, e.g., States’ Remedy, at 229 (citing Gates ¶¶ 289-90, 8
J.A. (II) at 4770-71 (‘‘Once provided with the equivalent of the
blueprints for Windows, competitors TTT would have little trouble
writing their own implementation of everything valuable that Win-
dows provides today, including the capabilities it provides to devel-
opers via APIs’’)).
31

would deny ‘‘Microsoft the returns from its investment in
innovation.’’12 Id. at 176.
Microsoft also points to the adverse technological effects
that would have ensued from broader disclosure of its internal
interfaces. The district court found overly broad disclosure
of APIs would limit Microsoft’s ability to modify interfaces, a
limitation that ‘‘threatens to stifle innovation and product
flexibility.’’ Id. at 177. The court also found that disclosure
of internal interfaces, which the States’ proposal would re-
quire, would force Microsoft to publish APIs where the
interfaces are unstable. Id. at 230-31. That ‘‘could pose a
substantial threat to the security and stability of Microsoft’s
software,’’ id. at 231; reliance upon such interfaces may
‘‘cause third-party software not to work or Windows to
crash,’’ id. at 230. Massachusetts does not challenge any of
these findings, although they clearly support the district
court’s refusal to require the broad disclosure of APIs pro-
posed by the States.
Massachusetts also insists the depth of Microsoft’s required
disclosure under § III.D is ‘‘inadequate.’’ The Common-
wealth first argues the depth of Microsoft’s disclosure obli-
gation is unclear because the definition of ‘‘API’’ is circular
and non-specific. The term is defined in § VI.A as an
‘‘application programming interface, including any interface
that Microsoft is obligated to disclose pursuant to III.D.’’ Id.
§ VI.A, at 274. Massachusetts points to the testimony of the
12 In a footnote to its argument concerning the disclosure of
communications protocols, Massachusetts asserts the district court
clearly erred in suggesting the States’ proposed definition could
lead to cloning, for which assertion it cites the opinion of Dr. Appel
that ‘‘the States’ Remedy does not allow such copying,’’ ¶ 99, 2 J.A.
(II) at 1284; see also ¶¶ 100-07, id. at 1284-88. This testimony,
although contrary to the district court’s finding that the States’
broad definition of interoperation could lead to cloning, is hardly
sufficient for us to conclude the district court’s finding is clearly
erroneous. See Microsoft III, at 66 (‘‘In view of the contradictory
testimony in the record, some of which supports the District Court’s
finding TTT, we cannot conclude that the finding was clearly errone-
ous’’).
32

States’ computer science expert, who said ‘‘Microsoft’s defini-
tion of ‘API’ is almost entirely a circular reference to Section
III.D, and it therefore does not adequately define what
information must be provided as part of the API disclosure.’’
Appel ¶ 60, 2 J.A. (II) at 1269. We note that most of this
expert’s testimony regarding the definition of API is a legal
analysis rather than the opinion of a computer scientist and is
therefore beyond the ‘‘knowledge, skill, experience, training,
or education’’ for which he was qualified as an expert. FED.
R. EVID. 702. In any event, his legal analysis is wrong; the
definition of API is not circular. API is defined in two places
in the decree. The definition quoted above and cited by the
States’ computer expert is the one found in the ‘‘Definitions’’
section of the decree for the use of the term in every section
of the decree other than § III.D. See States’ Remedy
§ VI.A, at 274. The term is defined separately in § III.D,
for the purpose of Microsoft’s disclosure obligation under that
section, as ‘‘the interfaces, including any associated callback
interfaces,’’ that permit Microsoft Middleware to obtain ‘‘ser-
vices’’ from Windows. Microsoft clearly understood, as the
States’ computer expert apparently did not, the latter defini-
tion is the one applicable to Microsoft’s disclosure of APIs
under the decree.13
Second, Massachusetts claims there is unrebutted testimo-
ny in the record indicating the depth of disclosure mandated
by § III.D is not ‘‘adequate for those whose innovative soft-
ware constitutes a potential threat to Windows.’’ The cited
testimony, however, does not cast doubt upon the district
court’s decision. The witnesses expressed concern that the
extent of Microsoft’s obligation to disclose file formats, regis-
try settings, and similar information is unclear and explained
the type of enhanced disclosure software developers would
13 See States’ Remedy, at 235; see also 5/2/02 pm Tr. at 6128
(Poole trial testimony) (stating in response to question whether he
knew ‘‘exactly’’ which APIs Microsoft is obliged to disclose under
§ III.D: ‘‘Yes. We know how to look for the list of points they [sic]
make their interfaces, associated call back interfaces, et cetera, and
ensure that we are in compliance relative to the code that we
separately distribute.’’).
33

like, but the testimony amounts to no more than conclusory
statements.14 That software developers prefer more, rather
than less, expansive and detailed disclosure of APIs and
technical information is hardly surprising, but the testimony
is not sufficient to support Massachusetts’ implication that the
disclosures required by § III.D will not materially assist
developers of potential middleware threats to Windows. Re-
call the district court did not undertake to assure the viability
of Microsoft’s rivals. Rather, the court settled upon a level of
disclosure that would ‘‘bolster’’ the ability of rival middleware
to serve as a platform threat to Microsoft; ‘‘help’’ rival
middleware interoperate with Windows; and ‘‘have the poten-
tial to increase the ability of competing middleware to threat-
en [Windows].’’ Id. at 172.
Finally, Massachusetts argues the disclosure mandated by
§ III.D need not be timely made. In the case of a ‘‘new
major version of Microsoft Middleware,’’ § III.D requires
disclosure ‘‘no later than the last major beta test release of
that Microsoft Middleware.’’ For a new version of Windows,
disclosure must occur in a ‘‘Timely Manner,’’ defined as the
time of the first release of a beta test version of Windows
through the Microsoft Developer Network or upon the distri-
bution of 150,000 or more copies of the beta version. Id.
§ VI.R, at 276.
Massachusetts nonetheless insists ‘‘[t]he remedy is at odds
with the record on timeliness.’’ Microsoft responds by point-
ing to evidence that requiring disclosure ‘‘before the software
code underlying those APIs has been fully developed and
14 For instance, one developer requested disclosure of certain
‘‘complicated interfaces’’ that Microsoft ‘‘had not anticipated’’ soft-
ware developers needing. 3/26/02 pm Tr. at 1452-53 (trial testimo-
ny of Steven McGeady), 6 J.A. (II) at 3375-76; see also 3/20/02 pm
at Tr. at 732-35 (trial testimony of David Richards of RealNet-
works), id. at 3404-05 (requesting further disclosure of technical
information and APIs); Direct Testimony of David Richards ¶ 65 &
n.11, 2 J.A. (II) at 1081-83 (same); Direct Testimony of Richard
Green ¶ 161, id. at 982 (same). Massachusetts also cites testimony
concluding the depth of Microsoft’s disclosure obligation is ‘‘not
clear.’’ E.g., Richards ¶ 90, id. at 1099-1100.
34

tested, as the TTT States requested, would create serious
logistical problems for both Microsoft and third-party soft-
ware developers.’’ See, e.g., Direct Testimony of Microsoft’s
Linda Wolfe Averett ¶ 18, 6 J.A. (II) at 3261 (‘‘Until Microsoft
is confident that it has figured out how to provide a particular
functionality, it does not want third-party developers building
products that rely on our functionality’’). Although clearly
favoring the definitions of timeliness adopted by the district
court, Microsoft’s evidence is not required in this instance
because the testimony Massachusetts cites itself underscores
Microsoft’s ‘‘strong incentive’’ to disclose its APIs in a timely
fashion so that software developers will write applications
based upon them. See, e.g., Borduin ¶ 35, 2 J.A. (II) at 1318-
19. Without timely disclosure, ‘‘there would be far fewer and
lower quality programs written for Microsoft’s operating sys-
tems.’’ Id. Microsoft’s incentive to make timely disclosure of
APIs is obvious: the ability of software developers to write
applications that rely upon Microsoft’s APIs depends upon
the developers having access to them. As the district court
found in the liability phase, ‘‘Microsoft must convince ISVs to
write applications that take advantage of the new APIs, so
that existing Windows users will have [an] incentive to buy an
upgrade.’’ Findings of Fact ¶ 44, at 21-22. The court also
found Microsoft offered inducements to software developers
to ensure they ‘‘promptly develop new versions of their
applications adapted to the newest version of Windows.’’ Id.
Massachusetts points to no evidence, and offers no reason to
think, this incentive is insufficient to induce timely disclosure
under § III.D of the decree. To the contrary, the evidence
Massachusetts offers merely confirms the economic incentives
Microsoft faces in releasing its APIs to ISVs in a timely
manner.
In sum, the district court’s findings are fully adequate to
support its decision with respect to disclosure. They are
comprehensive and sufficiently detailed to provide a clear
understanding of the factual basis for the court’s decision.
See Folger Coffee Co. v. M/V Olivebank, 201 F.3d 632, 635
(5th Cir. 2000); see also 9A CHARLES ALAN WRIGHT & ARTHUR
R. MILLER, FEDERAL PRACTICE AND PROCEDURE § 2571 (2d ed.
35

1995). We do not find persuasive Massachusetts’ arguments
that the district court overstated or misapprehended the
significance of the disclosure required by the decree. In light
of the forward-looking nature of the API disclosure provision,
the court reasonably balanced its goal of enhanced interoper-
ability with the need to avoid requiring overly broad disclo-
sure, which it determined could have adverse economic and
technological effects, including the cloning of Microsoft’s soft-
ware. Moreover, we cannot overlook the threat — as docu-
mented in the district court’s findings of fact in the liability
phase — posed by Netscape and Java, which relied upon
Microsoft’s then more limited disclosure of APIs. Microsoft
managed to squelch those threats, at least for a time, but that
does not diminish the competitive significance of the disclo-
sure of Microsoft’s APIs, a disclosure enhanced by the de-
cree.
We therefore hold the district court did not abuse its
discretion in fashioning the remedial provision concerning
Microsoft’s disclosure of APIs.
b. Disclosure of communications protocols
The district court also included in the decree a provision
requiring Microsoft to disclose certain communications proto-
cols. See States’ Remedy § III.E, at 269. As with APIs, we
did not hold Microsoft’s disclosure practices with respect to
communications protocols violated § 2 of the Sherman Act.
Communications protocols involve technologies — servers and
server operating systems — that are not ‘‘middleware’’ as we
used that term in our prior decision. See Microsoft III, at
53-54. It is therefore not surprising the district court de-
scribed the provision requiring the disclosure of communica-
tions protocols as the ‘‘most forward-looking’’ in the decree.
States’ Remedy, at 173 (emphasis in original).
Communications protocols provide a common ‘‘language’’
for ‘‘clients’’ and ‘‘servers’’ in a computing network. A net-
work typically involves interoperation between one or more
large, central computers (the servers) and a number of PCs
(the clients). By interoperating with the server, the clients
may communicate with each other and store data or run
36

applications directly on the server. The district court found
that servers may use any of several different operating
systems, id. at 121 (citing Direct Testimony of Robert Short
¶ 22, 6 J.A. (II) at 3528-29; Madnick ¶ 44, 5 J.A. (II) at 2814-
15), but most clients run a version of Windows, id. (citing
Madnick ¶ 44, 5 J.A. (II) at 1814-15). In a ‘‘heterogeneous
network,’’ that is, one comprising different types of hardware
and of operating systems, interoperation can be difficult.
One method of addressing the difficulty is to specify use of a
‘‘common language’’ understood by all the computing ele-
ments of the network. The district court specified one such
language, known as ‘‘native communication,’’ in § III.E of the
decree.15 That section requires Microsoft to make available
to third parties ‘‘on reasonable and non-discriminatory terms
TTT any Communications Protocol that is TTT (i) implemented
in a Windows Operating System Product installed on a client
computer, and (ii) used to interoperate, or communicate,
natively (i.e., without the addition of software code to the
client operating system product) with a Microsoft server
operating system product.’’
Native communication differs from other forms of commu-
nication because it does not require that additional software
be installed on the client. Other approaches may require
adding ‘‘software to the server to make the client computer
‘think’ it is communicating in a homogeneous network,’’ id. at
122 (citing Madnick ¶¶ 68-75, 5 J.A. (II) at 2826-29), or adding
‘‘software code to the client which enables the client to
communicate more effectively with the server,’’ id. (citing
Madnick ¶¶ 68, 76-82, 5 J.A. (II) at 2826-27, 2829-35). As the
district court stated, ‘‘Interoperation made possible by soft-
ware added onto Microsoft’s PC operating system products is
less clearly related to the facts of this case because it expands
beyond the relevant market of Intel-compatible PC operating
15 Examples of native communication include ‘‘basic Internet
protocols like Transmission Control Protocol/Internet Protocol
(‘TCP/IP’), HyperText Transfer Protocol (‘HTTP’) and File Trans-
fer Protocol (‘FTP’), all of which are supported natively in both
Windows clients and non-Microsoft servers.’’ See Short ¶ 36, 6 J.A.
(II) at 3535-36.
37

systems to address the ability of an application to interoper-
ate with a server.’’ Id. at 173 (emphasis in original). The
court therefore held Microsoft need not disclose communica-
tions protocols used to interoperate non-natively.
In determining the scope of the remedy, the district court
acknowledged that network and server-based applications are
not middleware in the sense that ‘‘the software physically
resides on the PC and functions as a platform for other
applications.’’ Id. at 129. Still, the court reasoned that such
applications are capable of functioning in a manner similar to
that of middleware ‘‘by providing a layer between the operat-
ing system and top-level applications.’’ Id. The court’s
reasoning is supported by its finding that ‘‘[s]oftware develop-
ers are increasingly writing programs that rely, or ‘call,’ on
APIs exposed by server operating systems such that the
server operating system provides the ‘platform’ for applica-
tions.’’ Id. at 123 (citing Direct Testimony of Novell, Inc.’s
Dr. Carl Ledbetter ¶¶ 47-48, 2 J.A. (II) at 1163-64; Direct
Testimony of Richard Green ¶ 76, 2 J.A. (II) at 956; 5/27/02
am Tr. at 1508-09 (Ledbetter trial testimony)). For these
reasons the district court, in extending Microsoft’s disclosure
to communications protocols, concluded ‘‘server operating sys-
tems can perform a function akin to that performed by
traditional middleware.’’ Id. at 172.
Massachusetts argues § III.E will not enhance interopera-
bility and there is no evidence, and the district court made no
finding, that it will. Microsoft responds that ‘‘a substantial
degree of interoperability already exists between Windows
desktop operating systems and non-Microsoft server operat-
ing systems’’ and the ability of third parties to license those
protocols from Microsoft pursuant to § III.E will enhance
interoperability. The parties’ divergent predictions point up
the difficulties inherent in crafting a forward-looking provi-
sion concerning a type of business conduct as to which there
has not been a violation of the law.
To be sure, as the Supreme Court observed in Internation-
al Salt Co. v. United States, 332 U.S. 392, 400 (1947), ‘‘When
the purpose to restrain trade appears from a clear violation of
law, it is not necessary that all of the untraveled roads to that
38

end be left open and that only the worn one be closed.’’ True
enough, but when the district court undertakes to block the
untraveled roads by adopting a forward-looking provision, its
discretion is necessarily less broad because, without liability
findings to mark the way, it is in danger of imposing restric-
tions that prevent the defendant from forging new routes to
serve consumers.
Massachusetts objects that the district court should not
have limited the disclosure requirement of § III.E to proto-
cols for native communications, which the district court found
is only ‘‘one of at least five basic approaches to achieving
interoperability between Windows client operating systems
and non-Microsoft server operating systems.’’ States’ Reme-
dy, at 234 (citing Short ¶ 35, 6 J.A. (II) at 3535). We think
the district court prudently sought not to achieve complete
interoperability but only to ‘‘advance’’ the ability of non-
Microsoft server operating systems to interoperate with Win-
dows and thereby serve as platforms for applications. It was
not an abuse of discretion for the court not to go further;
indeed, to have done so in the absence of related liability
findings would have been risky.
Massachusetts points to the testimony underlying the
States’ proposed findings for its claim that the disclosure
required by § III.E ‘‘would not provide a level of interopera-
bility sufficient to give competing software the opportunity to
gain marketplace acceptability.’’ Those proposed findings,
however, called for ‘‘full’’ and ‘‘seamless’’ interoperability, e.g.,
States’ Proposed Findings ¶¶ 700, 708, 3 J.A. (II) at 1613,
1615, and, more specifically, for disclosure of the ‘‘proprietary
protocols’’ for certain of Microsoft’s software products, includ-
ing the protocols that allow Microsoft’s server-based email
software (Microsoft Exchange) to interoperate with its PC-
based email software (Microsoft Outlook), ¶ 704, id at 1614.
Microsoft responds that, though Massachusetts may want to
extend the remedy to these products, the district court did
not abuse its discretion by ‘‘refusing to extend the remedy so
far beyond the liability determinations affirmed on appeal.’’
We agree. It was not inappropriate for the district court to
require only the disclosures necessary to provide a basic link
39

between non-Microsoft operating systems and PCs running
Windows. That there are other methods for achieving the
same or an even greater degree of interoperability — perhaps
even methods allowing the ‘‘full’’ and ‘‘seamless’’ interopera-
bility claimed by Massachusetts — does not render insuffi-
cient what is already the ‘‘most forward-looking’’ provision in
the decree.
Finally, Massachusetts argues the district court erred by
failing to define the term ‘‘interoperate’’ in the decree. The
district court found ‘‘the term ‘interoperate’ captures a contin-
uum[ ] rather than an absolute standardTTTT [T]he Court’s
remedial decree utilizes a very simple definition of the term
which is intended to capture the reasonable spectrum of the
continuum.’’ States’ Remedy, at 172 n.75. Evidence in the
record supports the district court’s finding.16 The court
rejected the States’ proposed definition, which, as we have
seen, the court found equates ‘‘interoperate’’ with ‘‘interchan-
geab[le]’’ and would give others the ability to clone many of
Microsoft’s products. Id. at 227 (citing 5/10/02 pm Tr. at
7111-12 (Bennett trial testimony), 6 J.A. (II) at 3596). In
light of the conflicting testimony in the record, some of which
clearly supports the district court’s finding that ‘‘interopera-
tion’’ is reasonably understood not as a binary concept, mean-
ing two network elements either do or do not interoperate,
but rather as a ‘‘continuum,’’ meaning their communication is
a matter of degree, we cannot hold the district court’s finding
to be clearly erroneous. Microsoft III, at 66.
In sum, the district court did not abuse its discretion or
otherwise err in adopting a provision limiting to native com-
munication Microsoft’s obligation to disclose communications
protocols.
4. Web Services
Massachusetts next argues the district court erred by
failing to adopt a remedy addressed to Web services. In
16 See, e.g., 5/10/02 pm Tr. at 7110 (Bennett trial testimony), 6
J.A. (II) at 3596 (explaining required disclosure as portion of
continuum or spectrum of interoperability that allows ‘‘two pro-
grams [to] exchange and make effective use of each other’s data’’).
40

particular, Massachusetts claims the court should have ex-
tended Microsoft’s disclosure obligation beyond interopera-
tion of server operating systems and PCs running Windows
to reach interoperation among ‘‘other nodes of the network
encompassed by network-based computing and the Web ser-
vices paradigm, such as multiple servers or handheld de-
vices.’’17 Microsoft responds by pointing out there was no
mention of Web services in the liability phase of this case, and
by claiming it has no monopoly power in the market for Web
services, ‘‘if such a [market] exists.’’ Also, the district court
found ‘‘Web-browsing software of the type addressed during
the liability phase will play no role in the creation, delivery, or
use of many Web services.’’ States’ Remedy, at 127.
Although the district court encountered ‘‘substantial dis-
agreement’’ about what constitutes a Web service, id. at 126,
it found the middleware at issue in Microsoft III, namely,
Web-browsing software, ‘‘is not integral to the functioning of
Web services because many Web services will involve direct
communications between devices or programs and will not be
accessed by an end user at all.’’ Id. at 126-27 (citing Direct
Testimony of Dr. James Allchin ¶¶ 43-45, 2 J.A. (II) at 1218-
19). Far from ignoring this area of rapid innovation, as
Massachusetts claims, the district court concluded Web ser-
vices are simply too far removed from the source of Micro-
soft’s liability in this case — as to which the relevant market
is operating systems for Intel-compatible PCs — to be impli-
cated in the remedy. Id. at 133 (‘‘mere importance of Web
services to Microsoft and the industry as a whole is not
sufficient to justify extending the remedy in this case to
regulate Microsoft’s conduct in relation to Web services’’).
Nor did the court think the States had sufficiently ‘‘explained
how the increase in the use of non-PC devices in conjunction
17 Although Massachusetts does not mention it, the States’
proposal would have done just that, see SPR § C, 6 J.A. (II) at
3172; see also SPR § 4, id. at 3172-73, extending Microsoft’s
disclosure obligation to interoperability with respect to, among
others, ‘‘Handheld Computing Devices’’ — a term defined in the
SPR to include ‘‘cellular telephone[s], personal digital assistant[s],
and Pocket PC[s],’’ SPR § 22.k, id. at 3194.
41

with Web services will reduce Microsoft’s monopoly in the
market for PC operating systems.’’ Id. at 134.
Massachusetts claims the district court excluded Web ser-
vices based upon the clearly erroneous premise ‘‘that this new
paradigm is a threat to the PC, and not to Windows.’’ For a
correct understanding Massachusetts points us to the testi-
mony of Jonathon Schwartz, Chief Strategy Officer at Sun
Microsystems: ‘‘[S]o long as consumers can access Web
services using competing devices and operating systems, they
are free to switch away from Windows if competing alterna-
tives are more attractive.’’ Direct Testimony ¶ 37, 2 J.A. (II)
at 882; see also Direct Testimony of John Borthwick ¶ 74, 7
J.A. (II) at 4117 (if ‘‘developers of web services adopt indus-
try standard protocols,’’ then applications will not rely upon
Windows and users will therefore be less reliant upon Win-
dows). According to Massachusetts, the district court ac-
knowledged as much when it stated:
The Chief Strategy Officer for Sun Microsystems, Inc.,
Jonathon Schwartz, testifying on behalf of Plaintiffs TTT
theorized that ‘‘[i]f the most popular applications are
delivered as Web services, instead of [as] stand-alone PC
applications, the applications barrier protecting Windows
could be substantially eroded.’’
States’ Remedy, at 127 (brackets in original). Clearly, howev-
er, the district court expressed its view that Schwartz was
‘‘theoriz[ing],’’ not stating a conclusion based upon fact. In
any event, the district court was primarily — and correctly —
focused upon whether a provision addressing Web services
could be linked to Microsoft’s liability in Microsoft III; it
could not.
Moreover, it does not follow that, because a proposed
requirement could reduce the applications barrier to entry, it
must be adopted. Recall the applications barrier to entry
arose only in part because of Microsoft’s unlawful practices;
it was also the product of ‘‘positive network effects.’’ 84 F.
Supp. 2d at 20. If the court is not to risk harming consum-
ers, then the remedy must address the applications barrier to
entry in a manner traceable to our decision in Microsoft III.
42

This the decree does by opening the channels of distribution
for non-Microsoft middleware. The district court reasonably
determined, based upon evidence in the record, a provision
addressing Web services might not be so benign. States’
Remedy, at 134.
Massachusetts also complains (albeit only in a footnote)
that, because the district court included a remedy affecting
servers, there is ‘‘no basis for distinguishing Web services,’’
which are part of the same, new platform threat. We dis-
agree. Disclosure of communications protocols is a ‘‘most
forward-looking remedy,’’ id. at 173 (emphasis in original);
the district court, which was not compelled to venture even
that far from its moorings in Microsoft III, was well within its
discretion, therefore, not to go further.
5. Market Development Programs
Massachusetts argues the remedy should be modified to
prevent Microsoft from offering to OEMs discounts, known as
Market Development Programs (MDPs). The Common-
wealth’s claim is based in part upon its concern that Microsoft
will use MDPs ‘‘to ensure that OEMs will not exercise
whatever flexibility the remedy provides’’ them. On its face,
Massachusetts’ concern appears to be that the new freedoms
provided to OEMs under the decree will be ineffectual be-
cause Microsoft has retained the ability to offer OEMs favor-
able discounts. Be that as it may, the district court rejected
the States’ proposal to prevent Microsoft from offering dis-
counts, see SPR § 2.a, 6 J.A. (II) at 3168, noting this court
‘‘did not condemn Microsoft’s use of MDPs and, in fact,
steadfastly refused to condemn practices which, at their core,
‘offered a customer an attractive deal.’ ’’ States’ Remedy, at
166 (quoting Microsoft III, at 68). The district court also
cited evidence in the record — testimony both of Microsoft’s
and of the States’ economic experts — that MDPs may be
employed procompetitively. Id. at 211. Upon weighing the
evidence, the district court concluded ‘‘the weight of the
economic testimony favors preservation of Microsoft’s ability
to offer MDPs, provided that Microsoft cannot impose the
MDPs in a discriminatory or retaliatory manner.’’ Id.; see
43

also id. at 166 (MDPs must be ‘‘based upon reasonable,
objective criteria, which are enforced uniformly and without
discrimination’’).
Massachusetts argues the district court ‘‘committed an
error of law’’ by failing to prohibit all MDPs, referring us to
United States v. Loew’s, Inc., 371 U.S. 38 (1962), for the
proposition that ‘‘[t]o ensure TTT that relief is effectual,
otherwise permissible practices connected with the acts found
to be illegal must sometimes be enjoined,’’ id. at 53. In
Loew’s, several major film distributors had violated § 1 of the
Sherman Act by ‘‘block-booking,’’ or tying popular films with
less popular films in licensing agreements with television
stations. Id. at 40-41. The district court enjoined the prac-
tice but did not accept the Government’s proposal to enjoin
certain ‘‘otherwise permissible practices’’ that could be used
to ‘‘subject[ ] prospective purchasers to a ‘run-around’ on the
purchase of individual films.’’ Id. at 55. Although the Su-
preme Court ultimately adopted the Government’s proposed
modifications because they would help ‘‘to prevent the recur-
rence of the illegality,’’ id. at 56, the Court pointed out that
‘‘[t]he trial judge’s ability to formulate a decree tailored to
deal with the violations existent in each case is normally
superior to that of any reviewing court,’’ id. at 52. Here the
district court did impose restraints upon Microsoft’s ‘‘other-
wise permissible practices’’ by requiring that any MDPs be
both uniform and nondiscriminatory. States’ Remedy, at 166.
Massachusetts has not shown that any additional restraint is
necessary.
Massachusetts also argues the district court clearly erred
in determining MDPs are procompetitive because ‘‘this direct-
ly contradicts its own findings regarding Microsoft’s ability to
frustrate the remedy.’’ The Commonwealth here relies upon
testimony that Microsoft conditioned MDPs upon an OEM’s
compliance with certain technical requirements, including a
specified configuration of hardware and software, restrictions
on the boot-up sequence, and a specified allocation of comput-
er memory. See, e.g., Ashkin ¶¶ 119-22, 5 J.A. (II) at 3114-16.
That testimony, however, reflects the competitive landscape
as it was prior to the adoption of the remedy now in place.
44

Whereas an OEM licensing Windows from Microsoft previ-
ously had little flexibility to include rival middleware, now it
may choose either to distribute non-Microsoft middleware or
to get a discount from Microsoft, as it sees fit. True, this
choice may be skewed if Microsoft offers deep discounts, but
the district court required Microsoft to offer MDPs to all
comers on the same uniform and non-discriminatory terms; it
cannot target a discount solely at an OEM that dallies with
rival middleware. Massachusetts gives us no reason to think
Microsoft is likely to pursue a deep discount strategy seem-
ingly made bootless by those conditions.
Without a clear indication that Microsoft can or will use its
discounts in a fashion that, as Massachusetts claims, ‘‘sub-
verts’’ the other provisions of the remedy, we again refuse to
condemn a practice that ‘‘offer[s the] customer an attractive
deal.’’ Microsoft III, at 68. Accordingly, we hold the district
court did not abuse its discretion by refusing to prohibit,
rather than placing protective conditions upon, Microsoft’s
offer of discounts.
6. Open Source Internet Explorer
Massachusetts argues the district court abused its discre-
tion in rejecting the States’ ‘‘open-source IE’’ provision, which
would require that
Microsoft TTT disclose and license all source code for all
Browser software [and that the license] grant a royalty-
free, non-exclusive perpetual right on a non-
discriminatory basis to make, use, modify and distribute
without limitation products implementing or derived
from Microsoft’s source codeTTTT
SPR § 12, 6 J.A. (II) at 3178. Microsoft responds that this
type of remedy is unnecessary because the decree already
proscribes the anticompetitive conduct by which Microsoft
had unlawfully raised the applications barrier to entry and
thereby diminished the threat posed by platforms rivaling
Microsoft’s operating system.
The district court rejected the States’ proposal for three
reasons. First, the open-source IE proposal ‘‘ignores the
45

theory of liability in this case,’’ which was directed at Micro-
soft’s unlawful ‘‘response to cross-platform applications, not
operating systems,’’ States’ Remedy, at 185; the proposed
remedy would directly benefit makers of non-Microsoft oper-
ating systems, even though the harm, if any, to them was
indirect. Second, the proposal would ‘‘provide [a] significant
benefit to competitors but [has] not been shown to benefit
competition.’’ Id. Finally, the proposal would work a ‘‘de
facto divestiture’’ and therefore should be analyzed as a
structural remedy pursuant to this court’s opinion on liability.
Id. at 186; see also Microsoft III, at 106 (‘‘In devising an
appropriate remedy, the District Court also should consider
whether plaintiffs have established a sufficient causal connec-
tion between Microsoft’s anticompetitive conduct and its dom-
inant position in the OS market’’). Here the court carefully
considered the ‘‘causal connection’’ between Microsoft’s anti-
competitive conduct and its dominance of the market for
operating systems, and held the causal link insufficient to
warrant a structural remedy. States’ Remedy, at 186.
Massachusetts argues the district court ‘‘improperly ig-
nored evidence that IE’s dominance is competitively impor-
tant for Microsoft’’ and complains that Microsoft ‘‘advan-
tage[s] its own middleware by using the browser to limit the
functionality of competing products.’’ These are not objec-
tions, however, to the district court’s reasons for rejecting the
States’ proposal. Rather, they are criticisms of what Massa-
chusetts terms the district court’s ‘‘implicit determination that
[certain] facts were not relevant’’ to its analysis of the open-
source IE provision. For instance, Massachusetts points to
the testimony of David Richards of RealNetworks stating
there would be ‘‘substantial end user benefit’’ if Microsoft
disclosed enough APIs to allow competitors such as RealNet-
works to create their own versions of the ‘‘Media Bar,’’ one of
Microsoft’s recent additions to the IE interface. See Direct
Testimony ¶¶ 79-84, 2 J.A. (II) at 1094-99. According to
Richards, the Media Bar is a version of Microsoft’s Windows
Media Player ‘‘embedded as the default media player’’ in IE.
¶ 79, id. at 1094-95. If Microsoft were to disclose the internal
architecture of the Media Bar, including the APIs upon which
46

it relies, he says, then end users could ‘‘play back more digital
formats within the [IE] browser than [Microsoft’s] Windows
Media Player, including our own RealAudio and RealVideo
formats.’’ ¶¶ 81, 82, id. at 1098.
Massachusetts argues the district court’s disregard of this
testimony ‘‘was wrong as a matter of law,’’ for which proposi-
tion it cites FTC v. Texaco, Inc., 555 F.2d 862 (D.C. Cir.
1977). As an initial matter, Massachusetts’ reliance upon
Texaco is misplaced. In Texaco we said ‘‘the appellate court
has the authority — and the duty — to determine the proper
legal premise and to correct the legal error of the trial judge,
without limitation by the doctrines of ‘clearly erroneous’ and
‘abuse of discretion’ that are applicable to review of factual
determinations.’’ Id. at 876 n.29. Here the district court did
not, as Massachusetts claims, commit an error of law ‘‘in
assessing the link between Microsoft’s unlawful acts and its
control of the dominant browser.’’ To be sure, Richards’
testimony makes clear Microsoft’s competitors would benefit
from Microsoft’s disclosure of the APIs necessary for them to
replicate Microsoft’s Media Bar. Neither that nor any other
testimony Massachusetts cites, however, indicates the district
court relied upon an improper ‘‘legal premise’’ in its ‘‘implicit
determination’’ of relevance.
The district court’s premise, as discussed more fully below,
was that the fruit of Microsoft’s unlawful conduct was not the
harm particular competitors may have suffered but rather
Microsoft’s freedom from platform threats posed by makers
of rival middleware. See Part II.B.1. The district court
properly focused, therefore, upon opening the channels of
distribution to such rivals; facts tending to show harm to
specific competitors are not relevant to that task. Also recall
the district court was properly concerned with avoiding a
disclosure requirement so broad it could lead to the cloning of
Microsoft’s products. That, in essence, appears to be what
the cited testimony would require with respect to Microsoft’s
Media Bar.
Massachusetts next argues the district court ‘‘misunder-
stood’’ that the States’ open-source IE proposal could ‘‘rees-
47

tablish a cross-platform browser,’’ thereby allowing applica-
tions to be written to APIs exposed by IE and, as a result,
lower the applications barrier to entry. As discussed in
preceding sections of this opinion, the decree the district
court approved includes several provisions addressed directly
to Microsoft’s efforts to extinguish nascent threats to its
operating system. Specifically, the decree restores the condi-
tions necessary for rival middleware to serve as a platform
threat to Windows and thereby speaks directly to our holding
with respect to liability. See Microsoft III. Moreover, the
district court found the States’ open-source IE proposal ig-
nores the theory of liability in this case not because the court
‘‘misunderstood’’ the implications of the proposal but because
the proposal would most likely benefit makers of competing
operating systems, namely, Apple and Linux, rather than
restore competitive conditions for potential developers of rival
middleware. States’ Remedy, at 242-43.18 That is why the
court concluded the open-source IE proposal would help
specific competitors but not the process of competition. See
id. at 185, 244; see also Elzinga ¶ 85, 5 J.A. (II) at 2732
(open-source IE provision is a ‘‘transparent ‘IP grab’ ’’ that
would ‘‘help competitors but harm competition’’). Massachu-
setts would refute the court’s conclusion with the testimony of
the States’ economic expert, who said open-source IE would
‘‘lower the applications barrier.’’ Shapiro ¶ 101, 2 J.A. (II) at
829. But that conclusory statement, even if an accurate
prediction, does not point up any error on the part of the
district court in refusing to adopt the open-source proposal.
There is more than one way to redress Microsoft’s having
18 As an economic matter, of course, the source of the threat to
Microsoft’s monopoly of the market for Intel-compatible PC operat-
ing systems, whether it be rival middleware or rival operating
systems, is not important. In remedying Microsoft’s violations of
the antitrust laws, however, it was reasonable for the district court
to focus upon the restoration of competitive conditions facing mak-
ers of rival middleware rather than lending a hand to makers of
rival operating systems; it was middleware with the potential to
create a platform threat, not rival operating systems, against which
Microsoft acted unlawfully. Findings of Fact, at 28-30.
48

unlawfully raised the applications barrier. And it was cer-
tainly within the district court’s discretion to address the
applications barrier to entry as it did, namely, by restoring
the conditions in which rival makers of middleware may
freely compete with Windows. Indeed, to have addressed
itself narrowly to aiding specific competitors, let alone com-
petitors that were not the target of Microsoft’s unlawful
efforts to maintain its monopoly, could well have put the
remedy in opposition to the purpose of the antitrust laws.
See Brooke Group, 509 U.S. at 224 (antitrust laws designed to
protect ‘‘competition, not competitors’’).
Massachusetts also complains the district court, in rejecting
the open-source IE provision, erred by probing the causal
connection between Microsoft’s unlawful acts and harm to
consumers. In response Microsoft points out that the district
court viewed the States’ proposed relief as structural and
therefore applied a test of causation along the lines we set out
in Microsoft III. See 253 F.3d at 106-07. Our instruction to
the district court was to consider on remand whether divesti-
ture was an appropriate remedy in light of the ‘‘causal
connection between Microsoft’s anticompetitive conduct and
its dominant position in the TTT market [for operating sys-
tems].’’ Id. at 106. Structural relief, we cautioned, ‘‘is
designed to eliminate the monopoly altogether TTT [and]
requires a clearer indication of a significant causal connec-
tion between the conduct and creation or maintenance of
market power.’’ Id. (emphasis in original) (citing 3 PHILLIP
E. AREEDA & HERBERT HOVENKAMP, ANTITRUST LAW ¶ 653b, at
91-92 (1996)).
As Massachusetts correctly notes, we were there address-
ing the district court’s order to split Microsoft into two
separate companies, whereas on remand, the district court
was addressing the States’ open-source IE proposal. But the
district court reasonably analogized that proposal to a divesti-
ture of Microsoft’s assets. States’ Remedy, at 185, 244. The
court pointed to testimony both of Microsoft’s and of the
States’ economic experts characterizing the open-source IE
remedy as ‘‘structural’’ in nature. Id. at 244 (citing Elzinga
¶ 104, 5 J.A. (II) at 2740-41; 4/11/02 am Tr. at 3324 (Shapiro
49

trial testimony), 8 J.A. (II) at 4502). Although Microsoft
could continue to use its intellectual property under the open-
source IE proposal, the ‘‘royalty-free, non-exclusive perpetual
right’’ of others to use it as well would confiscate much of the
value of Microsoft’s investment, which Gates put at more than
$750 million, ¶ 128, 8 J.A. (II) at 4714, and the court clearly
found to be of considerable value. See States’ Remedy, at
241, 244.
Massachusetts claims United States v. National Lead Co.,
332 U.S. 319 (1947), upheld compulsory licensing as a remedy
while at the same time rejecting the need for divestiture.
The licenses in National Lead, however, were not to be free;
on the contrary, the Supreme Court specifically pointed out
that reducing ‘‘all royalties automatically to a total of zero TTT
appears, on its face, to be inequitable without special proof to
support such a conclusion.’’ Id. at 349. (The Court left open
the possibility that royalties might be set at zero or at a
nominal rate, but only where the patent was found to be of
nominal value.) Here the States proposed Microsoft be re-
quired to license IE ‘‘royalty-free,’’ SPR § 12, 6 J.A. (II) at
3178. Therefore, National Lead is worse than no support for
the States’ proposal; it tells us that proposal is ‘‘on its face
TTT inequitable.’’ 332 U.S. at 349.
Finally, Massachusetts claims the district court erred in
rejecting the open-source IE proposal on the ground it ‘‘is
predicated not upon the causal connection between Micro-
soft’s illegal acts and its position in the PC operating system
market, but rather the connection between the illegal acts
and the harm visited upon Navigator.’’ This plainly misstates
the issue as we remanded it. We were concerned a drastic
remedy, such as divestiture, would be inappropriate if Micro-
soft’s dominant position in the operating system market could
not be attributed to its unlawful conduct. Microsoft III, at
106-07. The district court did not abuse its discretion by
insisting that an analogous form of structural relief — name-
ly, divesting Microsoft of much of the value of its intellectual
property — likewise meets the test of causation. Massachu-
setts’ statement that the open-source IE provision ‘‘is predi-
cated TTT [upon] the connection between the illegal acts and
50

the harm visited upon Navigator’’ highlights precisely why
the district court was right to reject that provision: The
remedy in this case must be addressed to the harm to
competition, not the harm visited upon a competitor.
The district court’s remedy is appropriately addressed to
the channels of distribution for non-Microsoft middleware,
including rival browsers such as Netscape Navigator. The
court did not abuse its discretion by refusing to adopt the
States’ proposed open-source IE provision for the benefit of
Microsoft’s competitors.
7. Java must-carry
Massachusetts argues the district court erred in refusing to
require Microsoft to distribute with Windows or IE a Sun-
compliant Java runtime environment, as the States had pro-
posed. Consider:
For a period of 10 years from the date of entry of the
Final Judgment, Microsoft shall distribute free of charge,
in binary form, with all copies of its Windows Operating
System Product and Browser TTT a competitively per-
forming Windows-compatible version of the Java runtime
environment TTT compliant with the latest Sun Microsys-
tems Technology Compatibility Kit.
SPR § 13, 6 J.A. (II) at 3179-80. The district court rejected
this proposal because it did not think appropriate a remedy
that ‘‘singles out particular competitors and anoints them with
special treatment not accorded to other competitors in the
industry.’’ States’ Remedy, at 189. Microsoft adds that the
proposal would give ‘‘Sun’s Java technology a free-ride on
Microsoft’s OEM distribution channel.’’
Massachusetts argues the district court was wrong as a
matter of law in thinking that mandated distribution of Java
would benefit a competitor and not competition: ‘‘If the
district court were correct that broad distribution of Java
did not benefit competition, then this Court could not have
held that Microsoft’s undermining of Java’s distribution was
anticompetitive.’’ Not surprisingly, this non sequitur misre-
presents the reasoning of the district court. That court
51

focused upon remedying Microsoft’s unlawful foreclosure of
distribution channels for rival middleware, not upon prop-
ping up a particular competitor. Massachusetts also com-
plains that if any measure that helps a ‘‘would-be competitor
of a monopolist’’ is rejected out of hand, then ‘‘competition
can never be restored to a monopolized market.’’ There is a
real difference, however, between redressing the harm done
to competition by providing aid to a particular competitor
and redressing that harm by restoring conditions in which
the competitive process is revived and any number of com-
petitors may flourish (or not) based upon the merits of their
offerings. Even in the latter instance, of course, a competi-
tor identifiable ex ante may benefit but not because it was
singled out for favorable treatment.
Massachusetts also complains the district court ignored
evidence ‘‘that the widespread availability of the cross-
platform Java runtime environment on PCs would reduce the
applications barrier to entry.’’ According to Massachusetts,
only if Java is available on PCs at ‘‘a percentage that ap-
proaches the percentage of PCs running Windows’’ will devel-
opers write to it. Testimony cited by Massachusetts extolling
the benefits of Java ubiquity, e.g., Green ¶ 53, 2 J.A. (II) at
949; Shapiro ¶ 131, id. at 840, does not, however, call into
question the district court’s rejection of the States’ proposal
as ‘‘market engineering,’’ States’ Remedy, at 262 (quoting
Murphy ¶ 239, 5 J.A. (II) at 2678), aimed at benefitting a
specific competitor.
B. Cross-cutting Objections
Massachusetts also raises arguments that pertain to multi-
ple provisions of the remedial decree. One such objection
goes to the district court’s overall approach to fashioning a
remedy.
1. ‘‘Fruits’’
Massachusetts also objects that, because the district court
did not require open-source IE licensing and mandatory
distribution of Sun’s Java technology, the decree fails to
‘‘deny Microsoft the fruits of its exclusionary conduct.’’ As
52

recounted in Part I above, we rejected the remedy at issue in
Microsoft III in part because the district court had ‘‘failed to
provide an adequate explanation for the relief it ordered.’’
253 F.3d at 103. We had expected the district court to
discuss the ‘‘objectives the Supreme Court deems relevant’’ to
fashioning relief in an antitrust case. Id. One of those
objectives, as Massachusetts notes, is to ‘‘deny to the defen-
dant the fruits of its statutory violation.’’ Id. (citing United
States v. United Shoe Mach. Corp., 391 U.S. 244, 250 (1968)).
The district court’s omission of any discussion addressed to
this objective was particularly troublesome because that court
had ordered the break-up of a company that was not the
product of mergers or acquisitions, see, e.g., id. at 99, 106,
much less unlawful mergers or acquisitions. In any event,
the fruits of a violation must be identified before they may be
denied. This would be a difficult, not to say imprudent, task
for a reviewing court to undertake in the first instance when
the remedy requires a divestiture but there are no clear lines
of perforation. We could not, for instance, ‘‘go[ ] into the
record far enough to be confident’’ what had been identified
as fruits were actually ‘‘the products of the unlawful practices
which the defendants have inflicted on the industry,’’ as the
Supreme Court could in identifying ‘‘at least some’’ of the
defendant’s acquisitions as ‘‘the fruits of [the] monopolistic
practices or restraints of trade’’ being remedied in United
States v. Paramount Pictures, Inc., 334 U.S. 131, 152 (1948).
The present decree, however, does not require that Micro-
soft be broken up. Nor did the district court adopt any other
of the States’ proposals it deemed structural in nature —
open-source IE, as discussed above, and the ‘‘porting’’ of
Microsoft Office. The district court also specifically rejected
the idea that IE was the fruit of Microsoft’s anticompetitive
conduct, finding, ‘‘[n]either the evidentiary record from the
liability phase, nor the record in this portion of the proceed-
ing, establishes that the present success of IE is attributable
entirely, or even in predominant part, to Microsoft’s illegal
conduct.’’ States’ Remedy, at 185-86 n.81; see also id. at 244
n.121. Rather, the fruit of its violation was Microsoft’s
freedom from the possibility rival middleware vendors would
53

pose a threat to its monopoly of the market for Intel-
compatible PC operating systems. The district court there-
fore reasonably identified opening the channels of distribution
for rival middleware as an appropriate goal for its remedy.
By ‘‘pry[ing] open’’ these channels, International Salt, 332
U.S. at 401, the district court denied Microsoft the ability
again to limit a nascent threat to its operating system monop-
oly. The district court certainly did not abuse its discretion
by adopting a remedy that denies Microsoft the ability to take
the same or similar actions to limit competition in the future
rather than a remedy aimed narrowly at redressing the harm
suffered by specific competitors in the past. This distinction
underlies the difference between a case brought in equity by
the Government and a damage action brought by a private
plaintiff.
Massachusetts also complains the district court erred in
applying a ‘‘stringent but-for test’’ of causation in determining
whether ‘‘advantages gained by Microsoft could be considered
a fruit of Microsoft’s illegality.’’ Here it points to a footnote
in which the district court, in the course of rejecting the
States’ open-source IE proposal, questioned the extent to
which the success of IE could be traced to Microsoft’s unlaw-
ful conduct. See States’ Remedy, at 242 & n.119. We have
already determined the district court properly refused to
impose that structural remedy without finding a significant
causal connection ‘‘between Microsoft’s anticompetitive con-
duct and its dominant position in the TTT market [for operat-
ing systems].’’ Microsoft III, at 106; see also Part II.A.6.
More important, the fruit of Microsoft’s unlawful conduct, as
mentioned, was its ability to deflect nascent threats to its
operating system by limiting substantially the channels avail-
able for the distribution of non-Microsoft middleware.
Therefore, to quote a leading treatise, regardless whether the
‘‘maximum feasible relief’’ in this case could have included
either open-source IE or Java must-carry or both, the district
court clearly did not abuse its discretion by adopting a more
‘‘tailored remed[y]’’ that directly addressed the fruit of Micro-
soft’s unlawful conduct. 3 PHILLIP E. AREEDA & HERBERT
HOVENKAMP, ANTITRUST LAW ¶ 650, at 67-68 (2d ed. 2002).
54

Finally, even if stunting Navigator and Java specifically were
deemed the fruits of Microsoft’s violations, the decree would
still be adequate because it opens the way to their distribu-
tion, both directly through the end-user access provision in
§ III.H and generally through the other conduct prohibitions
found in § III of the decree.
2. Presumption
Finally, Massachusetts charges the district court improper-
ly indulged but did not acknowledge an ‘‘apparent presump-
tion’’ in favor of Microsoft’s proposed remedy, ‘‘while holding
the States to a quantum of proof it did not demand of
Microsoft.’’ The district court’s obligation in fashioning a
remedial decree was, as we said in reviewing the original
decree in the Government’s case, ‘‘to enter that relief it
calculates will best remedy the conduct it has found to be
unlawful,’’ Microsoft III, at 105. The district court brings
broad discretion to its discharge of this obligation, again as
we have explained before.
In this case, the district court was presented with two
remedial proposals: The States made their proposal and
Microsoft proposed the decree it had negotiated with the
Government in the Track I proceedings. The district court
considered both proposals and rejected most of the provisions
the States proposed on the ground they went far beyond this
court’s rationale in holding Microsoft had violated the anti-
trust laws. If that ground holds, then no ‘‘unspoken pre-
sumption’’ need be conjured up to explain the district court’s
decision.
Our review both of Microsoft’s and of the States’ proposals
confirms the district court was on solid ground: Its reasoning
was based upon evidence in the record, was sound, and
involved no abuse of discretion. Some of the States’ propos-
als exceeded, under any reasonable interpretation, our liabili-
ty holding in Microsoft III. For instance, the open-source IE
provision approached the type of structural relief we singled
out when cautioning the district court against relief that
exceeds evidence of a causal connection between Microsoft’s
55

anticompetitive conduct and its dominance in the operating
systems market.
Massachusetts also claims the district court expressed con-
cern about the ‘‘supposed lack of economic analysis’’ support-
ing the States’ remedy without remarking the lack of econom-
ic analysis supporting the remedy it adopted. Massachusetts’
claims are demonstrably incorrect.
As our review has shown, there is ample evidence in the
record to support the district court’s findings. Likewise,
there was substantial economic testimony to support the
district court’s conclusions. We need not revisit each of the
issues we have already addressed in order to reject the
Commonwealth’s broad, unsubstantiated claims to the con-
trary.

III. CCIA and SIIA v. United States
& Microsoft, No. 03-5030
CCIA and SIIA seek to intervene for the purpose of
appealing the district court’s determination that the consent
decree between the Government and Microsoft is in the
‘‘public interest,’’ as required by the Tunney Act. They raise
several of the issues we addressed in Part II and they raise a
number of issues unique to the settlement proceedings, in-
cluding the Government’s and Microsoft’s compliance with the
procedural requirements of the Act.
A. Intervention
The district court denied the joint motion of CCIA and
SIIA to intervene for purposes of appealing the court’s
public-interest determination in U.S. Consent Decree. They
argue the district court erred in denying intervention because
their ‘‘claim or defense and the main action have a question of
law or fact in common,’’ as required for permissive interven-
tion pursuant to Federal Rule of Civil Procedure 24(b)(2).
See also Massachusetts School of Law at Andover, Inc.
(MSL) v. United States, 118 F.3d 776, 779 (D.C. Cir. 1997)
(Rule 24 governs intervention for purpose of filing appeal
under Tunney Act). The district court had also to ‘‘consider
56

whether the intervention will unduly delay or prejudice the
adjudication of the rights of the original parties.’’ FED. R.
CIV. P. 24(b)(2). In denying CCIA’s and SIIA’s motion, the
district court was concerned only with this latter require-
ment, to which we shall return in a moment. First, we
examine whether the would-be intervenors’ claim does have a
question of law or fact in common with the underlying action.
CCIA and SIIA say they have a ‘‘claim or defense’’ in
common with the main action in this case because their
members Netscape and Sun Microsystems — ‘‘the very firms
this Cou

[Text truncated at 120,000 characters. The full text is on the page linked above.]

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/cases/186212. Public record. Not legal advice.