massachusetts v. microsoft corp. 1199 · 2018. 1. 12. · massachusetts v. microsoft corp.1201 cite...

1199MASSACHUSETTS v. MICROSOFT CORP.Cite as 373 F.3d 1199 (D.C. Cir. 2004)

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 In-dustry Association and The Softwareand Information Industry Association,Appellants.

Nos. 02-7155 and 03-5030.

United States Court of Appeals,District of Columbia Circuit.

Argued Nov. 4, 2003.

Decided June 30, 2004.

Background: United States and individu-al states brought antitrust action againstsoftware manufacturer. On remand, 253F.3d 34, the United States District Courtfor the District of Columbia, Colleen Kol-lar-Kotelly, J., conditionally approved con-sent decree, 231 F.Supp.2d 144, and en-tered comparable remedial decree coveringclaims of those states that had refused tosettle. Appeals were taken by one litigat-ing state and industry associations whoseintervention motions had been denied.

Holdings: The Court of Appeals, Gins-burg, Chief Judge, held that:

(1) remedial decree adequately addressedmanufacturer’s violations;

(2) associations should have been allowedto intervene;

(3) consent decree was in public interest;and

(4) government and manufacturer satisfiedTunney Act’s procedural requirements.

Affirmed in part and reversed in part.

1. Federal Courts O776, 850.1

Appellate court reviews districtcourt’s findings of fact for clear error, butresolves issues of law de novo.

2. Federal Courts O813

District court’s decision whether togrant equitable relief is reviewed only forabuse of discretion.

3. Monopolies O24(7.1)

Determination in government’s anti-trust action that software manufacturer’scommingling of its browsing and operatingsystem code in same file violated ShermanAct’s anti-monopolization provision did notnecessitate remedy that required manufac-turer to ‘‘uncommingle’’ its code; rather,given potentially adverse effects of coderemoval, remedy which instead alleviatedanticompetitive effect of manufacturer’sconduct by allowing original equipmentmanufacturers (OEMs) and end users toreplace manufacturer’s browser with com-peting browser was not abuse of discre-tion. Sherman Act, § 2, as amended, 15U.S.C.A. § 2.


Failure to include provision, in reme-dial decree entered in antitrust actionagainst software manufacturer, prohibitingmanufacturer from engaging in unlawfulconduct which it had ceased in accordancewith consent decree entered in anothercase, was not abuse of discretion absentshowing of significant threat that conductwould be resumed. Sherman Act, § 2, asamended, 15 U.S.C.A. § 2.


Although district court is empoweredto fashion appropriate restraints on anti-trust defendant’s future activities both toavoid recurrence of violation and to elimi-nate its consequences, resulting relief must

1200 373 FEDERAL REPORTER, 3d SERIES

represent reasonable method of eliminat-ing consequences of illegal conduct.

6. Monopolies O24(7.1)Application program interface (API)

disclosures, required in remedial decreeentered against software manufacturerfound to have engaged in monopolisticpractices, were sufficiently broad; neitherlimitation of requirement to certain ofmanufacturer’s middleware products norlimitation as to amount of information dis-closed constituted abuse of discretion.Sherman Act, § 2, as amended, 15U.S.C.A. § 2.

7. Monopolies O24(7.1)Communications protocol disclosures,

required in remedial decree enteredagainst software manufacturer found tohave engaged in monopolistic practices,were sufficiently broad; limitation of re-quirement to protocols for native commu-nications was not abuse of discretion.Sherman Act, § 2, as amended, 15U.S.C.A. § 2.

8. Monopolies O24(7.1)Failure of remedial decree, entered

against software manufacturer found tohave engaged in monopolistic practices bytying its web-browsing software to its op-erating system, to regulate manufacturer’sconduct in relation to web services was notabuse of discretion. Sherman Act, § 2, asamended, 15 U.S.C.A. § 2.


against software manufacturer found tohave engaged in monopolistic practices bytying its web-browsing software to its op-erating system, to preclude manufacturerfrom offering financial incentives to origi-nal equipment manufacturers (OEMs) wasnot abuse of discretion; there was evi-dence such incentives had pro-competitiveeffect, and decree did preclude manufac-

turer from offering incentives in discrimi-natory manner. Sherman Act, § 2, asamended, 15 U.S.C.A. § 2.


against software manufacturer found tohave engaged in monopolistic practices bytying its web-browsing software to its op-erating system, to require manufacturer todisclose and license all source code for itsbrowser was not abuse of discretion.Sherman Act, § 2, as amended, 15U.S.C.A. § 2.


against software manufacturer found tohave engaged in monopolistic practices bytying its web-browsing software to its op-erating system, to require manufacturer todistribute copies of competitor’s ‘‘Java’’software was not abuse of discretion.Sherman Act, § 2, as amended, 15U.S.C.A. § 2.

12. Monopolies O24(7.1)Focus of remedial decree, entered

against software manufacturer found tohave engaged in monopolistic practices bytying its web-browsing software to its op-erating system, on denying manufacturer’sability to take same or similar actions tolimit competition in future, rather than onredressing harm suffered by specific com-petitors in past, was not abuse of discre-tion. Sherman Act, § 2, as amended, 15U.S.C.A. § 2.

13. Federal Courts O546Software industry associations’ claim

had question of law or fact in common withunderlying action, for purpose of determin-ing whether they were entitled to inter-vene for purpose of appealing districtcourt’s determination that consent decreeresolving government’s antitrust claimsagainst software manufacturer satisfied


statutory requirement of being in ‘‘publicinterest’’; private antitrust claims of asso-ciations’ members overlapped substantiallywith government’s claims. Clayton Act,§ 5(e), 15 U.S.C.A. § 16(e); Fed.RulesCiv.Proc.Rule 24, 28 U.S.C.A.

14. Federal Courts O546

Denial of software industry associa-tions’ motions to intervene, for purpose ofappealing district court’s approval of con-sent decree resolving government’s anti-trust claims against software manufactur-er, on ground of undue prejudice and delaywas abuse of discretion; consent decreewas already in place, and associations hadalready extensively participated in pro-ceedings. Clayton Act, § 5(e), 15 U.S.C.A.§ 16(e); Fed.Rules Civ.Proc.Rule 24(b), 28U.S.C.A.

15. Federal Civil Procedure O321

Procedural defects in connection withintervention motions should generally beexcused by court. Fed.Rules Civ.Proc.Rule 24, 28 U.S.C.A.

16. Federal Civil Procedure O2397.2

District court should withhold its ap-proval of consent decree in antitrust ac-tion, for failure to satisfy Tunney Act’s‘‘public interest’’ requirement, only if anydecree terms appear ambiguous, if en-forcement mechanism is inadequate, ifthird parties will be positively injured, or ifdecree otherwise makes mockery of judi-cial power. Clayton Act, § 5(e), 15U.S.C.A. § 16(e).

17. Federal Civil Procedure O2397.2

Tunney Act’s requirement, that con-sent decrees in antitrust cases be in publicinterest, does not distinguish between pre-and post-trial consent decrees. ClaytonAct, § 5(e), 15 U.S.C.A. § 16(e).

18. Federal Civil Procedure O2397.2Failure of consent decree, resolving

government’s antitrust claims against soft-ware manufacturer that had commingledits browsing and operating system code insame file, to require separation of codesdid not preclude approval of decree asbeing in public interest; decree adequatelyaddressed anticompetitive effect of com-mingling by requiring manufacturer to al-low original equipment manufacturers(OEMs) and end users to replace manufac-turer’s browser with competing browser.Sherman Act, § 2, as amended, 15U.S.C.A. § 2; Clayton Act, § 5(e), 15U.S.C.A. § 16(e).

19. Federal Civil Procedure O2397.2Failure of consent decree, resolving

government’s antitrust claims against soft-ware manufacturer, to require manufactur-er to distribute copies of competitor’s‘‘Java’’ software did not preclude approvalof decree as being in public interest; de-cree adequately addressed anticompetitiveeffect of manufacturer’s prior exclusionaryactivity by prohibiting future exclusionaryconduct. Sherman Act, § 2, as amended,15 U.S.C.A. § 2; Clayton Act, § 5(e), 15U.S.C.A. § 16(e).

20. Federal Civil Procedure O2397.2Limitations on application program in-

terface (API) disclosure requirements,contained in consent decree resolving gov-ernment’s antitrust claims against soft-ware manufacturer, did not preclude ap-proval of decree as being in public interest;disclosures were tailored to remedy assert-ed antitrust violations. Sherman Act, § 2,as amended, 15 U.S.C.A. § 2; Clayton Act,§ 5(e), 15 U.S.C.A. § 16(e).

21. Federal Civil Procedure O2397.2Consent decree resolving govern-

ment’s antitrust claims against softwaremanufacturer sufficiently defined its termsto avoid court rejection on ground it was


not in public interest; economic consider-ations precluded manufacturer from takingadvantage of some ambiguities, and othersimposed greater restrictions on manufac-turer than would have been imposed bymore specifically defined terms. ShermanAct, § 2, as amended, 15 U.S.C.A. § 2;Clayton Act, § 5(e), 15 U.S.C.A. § 16(e).

22. Federal Civil Procedure O2397.2Enforcement provisions in consent de-

cree resolving government’s antitrustclaims against software manufacturer weresufficient to avoid court rejection onground decree was not in public interest;proposed ‘‘technical committee’’ was ade-quate to assist government in its enforce-ment efforts, and proposed mechanism forhandling third-party complaints was ade-quate. Sherman Act, § 2, as amended, 15U.S.C.A. § 2; Clayton Act, § 5(e), 15U.S.C.A. § 16(e).

23. Federal Civil Procedure O2397.2Anti-retaliation provisions in consent

decree resolving government’s antitrustclaims against software manufacturerwere sufficient to avoid court rejection onground decree was not in public interest;possibility that manufacturer could stillretaliate against original equipment manu-facturers (OEMs) while technically com-plying with terms of decree was specula-tive. Sherman Act, § 2, as amended, 15U.S.C.A. § 2; Clayton Act, § 5(e), 15U.S.C.A. § 16(e).

24. Federal Civil Procedure O2397.3Government’s and antitrust defen-

dant’s disclosures, prior to seeking courtapproval of consent decree, were sufficientto satisfy Tunney Act’s procedural require-ments; government fully explained cir-cumstances from which proposed decreearose and discussed alternative provisionsit had considered, and defendant’s obli-gation to disclose its government commu-nications did not extend to its legislative

lobbying efforts. Clayton Act, § 5(b, g),15 U.S.C.A. § 16(b, g).

Appeal from the United States DistrictCourt for the District of Columbia (Nos.98cv01233, 98cv01232).

Steven R. Kuney argued the cause forappellant Commonwealth of Massachu-setts, ex rel., in No. 02-7155. With him onthe briefs were Brendan V. Sullivan, Jr.,Thomas F. Reilly, Attorney General, At-torney General’s Office of the Common-wealth of Massachusetts, and Glenn S.Kaplan, Assistant Attorney General. JohnE. Schmidtlein and Nicholas J. Boyle en-tered appearances.

Robert H. Bork argued the cause forappellants The Computer and Communica-tions Industry Association, et al., in No.03-5030. With him on the briefs wereKenneth W. Starr, Glenn B. Manishin, Ste-phanie A. Joyce, Mark L. Kovner, andElizabeth S. Petrela.

Kenneth W. Starr, Robert H. Bork,David M. Gossett, Elizabeth S. Petrela,Donald M. Falk, and Mitchell S. Pettitwere on the brief of amici curiae TheComputer and Communications IndustryAssociation, et al., in support of appellantin No. 02-7155. Glenn B. Manishin en-tered an appearance.

Deborah P. Majoras, Deputy AssistantAttorney General, U.S. Department ofJustice, argued the cause for appelleeUnited States of America in No. 03-5030.With her on the brief were R. Hewitt Pate,Assistant Attorney General, and CatherineG. O’Sullivan and David Seidman, Attor-neys.

Michael Lacovara and Steven L. Holleyargued the causes for appellees. With


them on the briefs were John L. Warden,Richard J. Urowsky, Richard C. Pepper-man II, Bradley P. Smith, Thomas W.Burt, David A. Heiner, Jr., Charles F.Rule, and Dan K. Webb.

Before: GINSBURG, Chief Judge, andEDWARDS, SENTELLE, RANDOLPH,ROGERS, and TATEL, Circuit Judges.

Opinion for the Court filed by ChiefJudge GINSBURG.

GINSBURG, Chief Judge:I. Background TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1204

II. Commonwealth of Massachusetts v. Microsoft, No. 02-7155 TTTTTTTTTTTTTTTTTTTTT1207A. Remedial Proposals TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1207

1. Commingling TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12072. Java deception TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12133. Forward-looking provisions TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1215

a. Disclosure of APIsTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1216b. Disclosure of communications protocolsTTTTTTTTTTTTTTTTTTTTTTTTTTT1222

4. Web Services TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12255. Market Development Programs TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12266. Open Source Internet Explorer TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12277. Java must-carry TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1231

B. Cross-cutting Objections TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12321. ‘‘Fruits’’ TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12322. Presumption TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1233

III. CCIA and SIIA v. United States & Microsoft, No. 03-5030 TTTTTTTTTTTTTTTTTTTTT1234

A. InterventionTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1234B. The Public Interest Finding TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1236

1. Issues overlapping Massachusetts’ caseTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1237a. Commingling TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1238b. Java TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1239c. Disclosure of APIsTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1240d. Adequacy of definitionsTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1241e. ‘‘Fruits’’ TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1242

2. Non-overlapping issuesTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1243a. EnforcementTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1243b. User interface TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1245c. Anti-retaliationTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1245

C. Procedural Claims TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12461. Government’s disclosureTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT12472. Microsoft’s disclosure TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1249

IV. Conclusion TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT1250

* * *

In United States v. Microsoft Corp., 253F.3d 34 (D.C.Cir.2001) (Microsoft III), weaffirmed in part and reversed in part thejudgment of the district court holding Mi-crosoft had violated §§ 1 and 2 of theSherman Antitrust Act, vacated the associ-ated remedial order, and directed the dis-trict court, on the basis of further proceed-ings, to devise a remedy ‘‘tailored to fit the

wrong creating the occasion’’ therefor, id.at 107, 118-19. On remand, the UnitedStates and certain of the plaintiff statesentered into a settlement agreement withMicrosoft. Pursuant to the Antitrust Pro-cedures and Penalties (Tunney) Act, 15U.S.C. §§ 16(b)-(h), the district court heldthe parties’ proposed consent decree, asamended to allow the court to act suasponte to enforce the decree, was in ‘‘the


public interest.’’ Meanwhile, the Com-monwealth of Massachusetts and severalother plaintiff states refused to settle withMicrosoft and instead litigated to judg-ment a separate remedial decree. Thejudgment entered by the district court intheir case closely parallels the consent de-cree negotiated by the United States.

Massachusetts alone appeals the districtcourt’s entry of that decree. It argues thedistrict court abused its discretion inadopting several provisions Microsoft pro-posed while rejecting several others Mas-sachusetts and the other litigating statesproposed. Massachusetts also challengesa number of the district court’s findings offact. Based upon the record before us inMicrosoft III and the record of the reme-dial proceedings following remand, we af-firm the district court’s remedial decree inits entirety.

The Computer and Communications In-dustry Association (CCIA) and the Soft-ware and Information Industry Associa-tion (SIIA) separately appeal the districtcourt’s denial of their motion, following thedistrict court’s approval of the consent de-cree between the United States and Mi-crosoft, to intervene in the case for thepurpose of appealing the district court’spublic-interest determination. They arguethe factors the district court was to con-sider in determining whether to allowthem to intervene weighed in their favor.We agree and reverse the district court’sdenial of their motion to intervene for thepurpose of appealing that court’s public-interest determination.

CCIA and SIIA make various argu-ments — some overlapping those raised byMassachusetts — that the consent decreebetween the United States and Microsoftis not in the public interest. They alsoargue the parties did not satisfy the proce-dural requirements of the Tunney Act.For these reasons, they seek vacatur of

the district court’s order approving theconsent decree and a remand for entry of‘‘a proper remedy.’’ We find no merit inany of CCIA’s and SIIA’s objections, sub-stantive or procedural. We therefore up-hold the district court’s approval of theconsent decree as being in the public inter-est.

I. Background

The facts underlying the present appealshave been recounted several times. SeeNew York v. Microsoft Corp., 224F.Supp.2d 76 (D.D.C.2002) (States’ Reme-dy); United States v. Microsoft Corp., 231F.Supp.2d 144 (D.D.C.2002) (U.S. ConsentDecree); see also Microsoft III. Wetherefore limit our discussion of the factsand of the proceedings to a brief review ofevents prior to our remand in 2001 and amore detailed account of what has tran-spired since then.

In May 1998 the United States filed acomplaint against Microsoft alleging viola-tions of federal antitrust laws. At thesame time, a number of states and theDistrict of Columbia filed a complaintagainst Microsoft alleging violations ofboth federal and state antitrust laws. Thetwo complaints, which the district courtconsolidated, sought various forms of re-lief, including an injunction against certainof Microsoft’s business practices.

After a lengthy bench trial the districtcourt entered findings of fact, UnitedStates v. Microsoft Corp., 84 F.Supp.2d 9(D.D.C.1999) (Findings of Fact), and heldMicrosoft had violated §§ 1 and 2 of theSherman Act by illegally maintaining itsmonopoly in the market for ‘‘Intel-compati-ble PC operating systems,’’ by attemptingto monopolize the browser market, and bytying its Windows operating system to itsInternet Explorer (IE) browser. UnitedStates v. Microsoft Corp., 87 F.Supp.2d 30(D.D.C.2000) (Conclusions of Law). The


district court also held Microsoft violatedthe antitrust laws of the several states.Id. at 56. Based upon its findings of factand conclusions of law, the district courtdecreed that Microsoft would be split intotwo separate companies, one selling oper-ating systems and one selling program ap-plications. See United States v. MicrosoftCorp., 97 F.Supp.2d 59 (D.D.C.2000) (Rem-edy I). Microsoft appealed the decisionsof the district court, alleging several legaland factual errors.

We upheld the district court’s rulingthat Microsoft violated § 2 of the Sher-man Act by the ways in which it main-tained its monopoly, but we reversed thedistrict court’s finding of liability for at-tempted monopolization, and we remandedthe tying claim to the district court toapply the rule of reason rather than therule of per se illegality. See Microsoft III.We also vacated the district court’s reme-dial decree, for three reasons: ‘‘First, [thedistrict court had] failed to hold an eviden-tiary hearing despite the presence of rem-edies-specific factual disputes’’; ‘‘[s]econd,the court did not provide adequate rea-sons for its decreed remedies’’; and third,we had ‘‘drastically altered the scope ofMicrosoft’s liability, and it [was] for theDistrict Court in the first instance to de-termine the propriety of a specific remedyfor the limited ground of liability which weha[d] upheld.’’ Id. at 107.

On remand the district court orderedthe parties to file a Joint Status Report.This they did in September 2001, whereup-on the district court ordered them to un-dertake settlement discussions. See Unit-ed States v. Microsoft Corp., 168F.Supp.2d 541 (D.D.C.2001). As a result,the United States and the States of Illi-nois, Louisiana, Maryland, Michigan, NewYork, North Carolina, Ohio, and Wiscon-sin, and the Commonwealth of Kentucky,agreed to enter into a consent decree with

Microsoft. On November 6, 2001 the set-tling parties filed a Revised Proposed Fi-nal Judgment, 1 Joint Appendix in No. 03-5030 (hereinafter J.A. (I)) at 113-30, forthe district court’s review. The States ofCalifornia, Connecticut, Florida, Iowa,Kansas, Minnesota, Utah, and West Virgi-nia, the Commonwealth of Massachusetts,and the District of Columbia refused toenter into the consent decree. The districtcourt therefore bifurcated the remainingproceedings: On ‘‘Track I’’ was the districtcourt’s ‘‘public interest’’ review of the pro-posed consent decree, as required by theTunney Act whenever the Governmentproposes to settle a civil antitrust case, see15 U.S.C. § 16(e); on ‘‘Track II’’ was thecontinuing litigation between the non-set-tling states (hereinafter ‘‘the States’’) andMicrosoft concerning the remedy.

Track I

On November 15, 2001 the Governmentfiled its Competitive Impact Statement(CIS), 1 J.A. (I) at 136-202, as required bythe Act, 15 U.S.C. § 16(b), and on Novem-ber 28, 2001 it published in the FederalRegister both the Revised Proposed FinalJudgment and the CIS for public com-ment. 66 Fed.Reg. 59,452 (Nov. 28, 2001).In February 2002 the Government filedwith the district court its response to themore than 32,000 public comments it hadreceived, along with a Second Revised Pro-posed Final Judgment, 6 Joint Appendix inNo. 02-7155 (hereinafter J.A. (II)) at 3664-81, reflecting modifications agreed to bythe settling parties in the light of thepublic comments. The public comments,which the Government made available atits website in March 2002, were subse-quently published in the Federal Registeras well. 67 Fed.Reg. 23,654 (May 3, 2002).The Tunney Act also requires the defen-dant to file with the district court ‘‘any andall written or oral communications TTTwith any officer or employee of the United


States’’ relating to the proposed consentjudgment. 15 U.S.C. § 16(g). Microsoftmade such a filing in December 2001 andagain in March 2002. See Part III.C.2.

The Tunney Act provides the districtcourt with several procedural options toaid it in making its determination whetherthe proposed consent decree is in the pub-lic interest. The court may ‘‘take testimo-ny of Government officials or experts’’ as itdeems appropriate, 15 U.S.C. § 16(f)(1);authorize participation by interested per-sons, including appearances by amici curi-ae, id. § 16(f)(3); review comments andobjections filed with the Government con-cerning the proposed judgment, as well asthe Government’s response thereto, id.§ 16(f)(4); and ‘‘take such other action inthe public interest as the court may deemappropriate,’’ id. § 16(f)(5). The districtcourt exercised several of these options.It held a hearing with the purpose ofhaving the parties provide to the courtinformation it needed to decide whether toapprove the Second Revised Proposed Fi-nal Judgment. The district court deniedCCIA’s request to intervene in the case,see id. § 16(f)(3), but it did allow CCIAand SIAA to participate in the hearing asamici curiae. In July 2002 the districtcourt concluded both the Government andMicrosoft had complied with the require-ments of the Tunney Act and held that thematter was ripe for the court to determinewhether the decree was in the ‘‘publicinterest.’’ United States v. MicrosoftCorp., 215 F.Supp.2d 1, 23 (D.D.C.2002)(Tunney Act Proceedings).

On November 1, 2002 the district courtruled the Second Revised Proposed Final

Judgment would be in the public interest ifmodified in one respect: The parties wouldhave to provide for the district court to‘‘retain jurisdiction to take action suasponte in conjunction with the enforcementof the decree.’’ U.S. Consent Decree, at202. This they did in a Third RevisedProposed Final Judgment, which the dis-trict court duly entered. United States v.Microsoft Corp., 2002 WL 31654530(D.D.C. Nov.12, 2002) (Final Consent De-cree).1

On December 20, 2002 CCIA and SIIAfiled a joint motion for leave to intervene,as of right or alternatively by permission,see FED.R.CIV.P. 24, for the purpose ofappealing the district court’s judgmentthat the consent decree was in the ‘‘publicinterest.’’ The district court denied theirmotion, United States v. Microsoft Corp.,2003 WL 262324 (D.D.C. Jan.11, 2003) (Or-der Denying Intervention), and the mov-ants now appeal both the district court’sdenial of their motion for leave to inter-vene and, if allowed, the district court’spublic-interest determination under theTunney Act.

Track II

Pursuant to the district court’s schedul-ing order of September 28, 2001, Microsoftand the States submitted competing reme-dial proposals in December of that year.This time the States did not propose todivide Microsoft but, as discussed in PartII.A.6, they did include proposals the dis-trict court considered structural in nature,including requirements that Microsoft of-fer ‘‘open source licensing for Internet Ex-plorer’’ and ‘‘auction to a third party the

1. The district court also held the ‘‘public in-terest’’ standard made applicable to the Gov-ernment’s case by the Tunney Act should beapplied to the settlement between the settlingstates and Microsoft in order to meet thegenerally applicable requirement of circuitlaw that any consent decree ‘‘fairly and rea-sonably resolve[ ] the controversy in a manner

consistent with the public interest.’’ NewYork v. Microsoft Corp., 231 F.Supp.2d 203,205 (D.D.C.2002) (citing Citizens for a BetterEnv’t v. Gorsuch, 718 F.2d 1117, 1126(D.C.Cir.1983)). The district court’s public-interest determination in the settling states’case is not at issue in the current appeals.


right to port Microsoft Office to competingoperating systems.’’ Microsoft objected tothe States’ proposed remedy and offeredas an alternative the Revised ProposedFinal Judgment to which it had agreed inthe Track I proceedings. Both sides latersubmitted revised proposals. In February2002 Microsoft submitted the Second Re-vised Proposed Final Judgment, and inMarch the States submitted a Second Pro-posed Remedy (SPR), 6 J.A. (II) at 3160-3201. The Second Revised Proposed FinalJudgment and the SPR are the two pro-posals the district court ultimately re-viewed.

After an expedited discovery schedule,the hearing on remedies began in March2002 and ran for 32 trial days spanningthree months, over which time the courtreviewed written direct testimony andheard live testimony from dozens of wit-nesses.2 States’ Remedy, at 87. The dis-trict court issued its findings of fact and itslegal conclusions in a combined opinion.The final judgment in the proceedings onTrack II — that is, the remedy adopted bythe district court — is attached as anappendix to the district court’s opinion.See States’ Remedy, at 266-77.

Massachusetts alone among the Statesappeals. We address the Commonwealth’sappeal in Part II below and CCIA’s andSIIA’s appeal in Part III.

II. Commonwealth of Massachusettsv. Microsoft, No. 02-7155

[1, 2] We review the district court’sfindings of fact for clear error, United

States ex rel. Modern Elec., Inc. v. IdealElec. Sec. Co., 81 F.3d 240, 244 (D.C.Cir.1996); see also FED.R.CIV.P. 52(a) (‘‘[f]ind-ings of fact TTT shall not be set asideunless clearly erroneous’’), but resolve is-sues of law de novo, Modern Elec., Inc., 81F.3d at 244. We review the district court’sdecision whether to grant equitable reliefonly for abuse of discretion. See MicrosoftIII, at 105; see also Ford Motor Co. v.United States, 405 U.S. 562, 573, 92 S.Ct.1142, 1149, 31 L.Ed.2d 492 (district court‘‘clothed with ‘large discretion’ to fit thedecree to the special needs of the individu-al case’’).

A. Remedial Proposals

Massachusetts objects to several provi-sions the district court included in theremedial decree. The Commonwealth alsoappeals the district court’s refusal to adoptcertain other provisions proposed by theStates.

1. Commingling

In Microsoft III we upheld the districtcourt’s finding that Microsoft’s integrationof IE and the Windows operating systemgenerally ‘‘prevented OEMs from pre-in-stalling other browsers and deterred con-sumers from using them.’’ 253 F.3d at 63-64. Because they could not remove IE,installing another browser meant the OEMwould incur the costs of supporting twobrowsers. Id. at 64. Accordingly, OEMs

2. The States presented the testimony of thir-teen fact witnesses: Peter Ashkin, JamesBarksdale, John Borthwick, Anthony Fama,Richard Green, Mitchell Kertzman, Dr. CarlLedbetter, Michael Mace, Steven McGeady,Larry Pearson, David Richards, JonathanSchwartz, and Michael Tiemann; and of twoexpert witnesses: Dr. Andrew Appel and Dr.Carl Shapiro. Microsoft presented the testi-mony 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, Christopher Jones, WillPoole, W.J. Sanders III, Robert Short, GreggSutherland, and Richard Ulmer; and of fourexperts: Dr. John Bennett, Dr. Kenneth El-zinga, Dr. Stuart Madnick, and Dr. KevinMurphy.


had little incentive to install a rival brow-ser, such as Netscape Navigator. Relyingupon the district court’s findings of fact,we determined that Microsoft took threeactions to bind IE to Windows: (1) itexcluded IE from the ‘‘Add/Remove Pro-grams’’ utility; (2) it commingled in thesame file code related to browsing andcode used by the operating system so thatremoval of IE files would cripple Windows;and (3) it designed Windows in such amanner that, in certain circumstances, auser’s choice of an internet browser otherthan IE would be overridden. Id. at 64-65. Although all three acts had anticom-petitive effects, only the first two had nooffsetting justification and, therefore, ‘‘con-stitute[d] exclusionary conduct[ ] in viola-tion of § 2.’’ Id. at 67. As for overridingthe user’s choice of an internet browser,we held the plaintiffs had neither rebuttedMicrosoft’s proffered technical justificationnor demonstrated that its justification wasoutweighed by the anticompetitive effect.We therefore concluded Microsoft was not‘‘liable for this aspect of its product de-sign.’’ Id.

On remand, turning to the comminglingof IE and Windows code, the district courtstated that an appropriate remedy ‘‘mustplace paramount significance upon ad-dressing the exclusionary effect of thecommingling, rather than the mere con-duct which gives rise to the effect.’’States’ Remedy, at 156. The court wasconcerned about adopting any remedy thatwould require Microsoft to remove Win-dows software code — as the States’ pro-

posed remedy would do — based uponwhat it perceived to be a very difficult,even if not ‘‘technologically impossible,’’task. Id. at 157. For instance, the courtfound the States did not offer a reasonablemethod of distinguishing ‘‘operating sys-tem’’ code from ‘‘non-operating system’’code, such as code that provides middle-ware functionality.3 Id. Moreover, basedupon ‘‘testimony of various [independentsoftware vendors (ISVs) ] that the qualityof their products would decline if Microsoftwere required to remove code from Win-dows,’’ the court concluded both ISVs andconsumers would be harmed if Microsoftwere forced to redesign Windows by re-moving software code. Id. at 158. Final-ly, the district court was alert to ‘‘theadmonition [in the case law] that it is not aproper task for the Court to undertake toredesign products.’’ Id.; see also UnitedStates v. Microsoft Corp., 147 F.3d 935,948 (D.C.Cir.1998) (Microsoft II) (‘‘Anti-trust scholars have long recognized theundesirability of having courts overseeproduct design’’). Accordingly, the districtcourt instead approved the proposed re-quirement that Microsoft ‘‘permit OEMsto remove end-user access to aspects ofthe Windows operating system which per-form middleware functionality.’’ States’Remedy, at 159. Specifically, § III.H ofthe decree requires Microsoft to ‘‘[a]llowend users TTT and OEMs TTT to enable orremove access to each Microsoft Middle-ware Product or Non-Microsoft Middle-ware Product TTTT’’ Id. at 270.

3. As we explained in Microsoft III, the term‘‘middleware’’ refers to software productsthat expose their ‘‘Applications ProgrammingInterfaces,’’ upon which software developersrely in writing applications. 253 F.3d at 53;see also Findings of Fact ¶ 28, at 17. Themiddleware at issue in Microsoft III was pri-marily web-browsing software. The districtcourt’s remedy in this case, however, covers a

far broader array of middleware. According-ly, the district court was at pains to defineMicrosoft’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 thedistrict court’s extensive treatment of thosedefinitions, see States’ Remedy, at 112-21, butthe definitions are discussed as needed below.


[3] Massachusetts maintains the dis-trict court erred by addressing the remedyto the exclusionary effect of comminglingand not to the commingling itself. In re-sponse, Microsoft points out that in theliability proceedings the plaintiffs wereconcerned primarily with end-user accessand that the decree originally entered bythe district court likewise addressed Mi-crosoft’s binding its middleware to its op-erating system; the remedy was to allowboth OEMs and end users to remove ac-cess to Microsoft middleware. Remedy I,at 68. That is why on remand the districtcourt observed that ‘‘[n]othing in the ratio-nale underlying the commingling liabilityfinding requires removal of software codeto remedy the violation.’’ States’ Remedy,at 158. We agree; the district court’sremedy is entirely consistent with its earli-er finding that ‘‘from the user’s perspec-tive, uninstalling Internet Explorer [withthe Add/Remove Programs utility is]equivalent to removing the Internet Ex-plorer program from Windows.’’ Findingsof Fact ¶ 165, at 51.

The district court’s decision to fashion aremedy directed at the effect of Micro-soft’s commingling, rather than to prohibitcommingling, was within its discretion.The end-user access provision does this,and it avoids the drawbacks of the States’proposal requiring Microsoft to redesignits software. Allowing an OEM to blockend-user access to IE gives the OEM con-trol over the costs associated with support-ing more than one internet browser. In-deed, had Microsoft not removed IE fromthe Add/Remove Programs utility in thefirst place, OEMs would have retained asimple and direct method of avoiding suchcosts. See, e.g., Direct Testimony of Dr.Stuart Madnick ¶ 177, 5 J.A. (II) at 2887.

Massachusetts says there is unrebuttedtestimony in the record indicating the re-moval of end-user access is insufficient ‘‘to

reduce OEMs’ disincentives to install rivalmiddleware.’’ Not so. The cited testimo-ny is that end-users ‘‘may accidentallytrigger one program when they mean totrigger another. This is especially sowhen, under Microsoft’s Proposed Reme-dy, Windows is allowed to launch Microsoftmiddleware on a system on which a con-sumer has not chosen Microsoft’s programto 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 testimonyindicates only that removal of end-useraccess to IE may not eliminate every last‘‘accidental’’ invocation of IE, not that theincidence will not be reduced, as it nodoubt will be. Second, under § III.H.2end users and OEMs may ‘‘designate aNon–Microsoft Middleware Product to beinvoked in place of [a] Microsoft Middle-ware Product TTT in any case where theWindows Operating System Product wouldotherwise launch the Microsoft Middle-ware Product TTT,’’ States’ Remedy§ III.H.2, at 270-71, which apparently pro-vides OEMs a method to address the con-duct about which Massachusetts is con-cerned.

Finally, the accidental invocationsclaimed in the cited testimony do not re-flect the nature of the concerns OEMs hadat the time the district court made itsFindings of Fact. The district court foundMicrosoft had combined commingling ofcode and removal of IE from the Add/Re-move Programs utility in a manner thatensured the presence of IE on the Win-dows desktop. See Findings of Fact ¶ 241,at 69. The lack of any way to remove end-user access to IE — now squarely ad-dressed in § III.H of the decree — madethe IE icon an ‘‘unavoidable presence’’ onthe Windows desktop; that was what led‘‘to confusion among novice users.’’ Id.¶ 217, at 63. More, that is, was involvedthan the occasional invocation of IE by


accident; IE was always present becauseMicrosoft prevented OEMs from removingboth the code and the end-user’s access toit. The accidental invocations of Microsoftmiddleware claimed in the Ashkin testimo-ny — to the extent not already resolved by§ III.H.2 — are hardly likely to generatethe level of support costs OEMs facedwhen the IE icon was on every desktop.Certainly the cited testimony is no evi-dence of such significant costs.

The district court fashioned a remedyaimed at reducing the costs an OEM mightface in having to support multiple internetbrowsers. The court thereby addresseditself to Microsoft’s efforts to reduce soft-ware developers’ interest in writing to theApplication Program Interfaces (APIs) ex-posed by any operating system other thanWindows. Far from abusing its discretion,therefore, the district court, by remedyingthe anticompetitive effect of commingling,went to the heart of the problem Microsofthad created, and it did so without intrud-ing itself into the design and engineeringof the Windows operating system. Wesay, Well done!

But soft! Massachusetts and the amiciclaim the district court nonetheless erredin rejecting a ‘‘code removal’’ remedy forMicrosoft’s commingling, principally inso-far as the court was concerned with ‘‘Mi-crosoft’s ability to provide a consistentAPI set,’’ which Microsoft referred to asthe problem of Windows’ ‘‘fragmentation.’’4

They argue that any effort to keep soft-ware developers writing to Microsoft’sAPIs — and thereby avoiding ‘‘fragmenta-tion’’ — is not procompetitive but rather‘‘an argument against competition.’’

The district court raised its concernabout fragmentation in connection with theStates’ proposal that Microsoft be requiredto remove its middleware code from thecode of its Windows operating system, asfollows:

Microsoft shall not, in any Windows Op-erating System Product TTT it distrib-utes TTT Bind any Microsoft MiddlewareProduct to the Windows Operating Sys-tem unless Microsoft also has availableto license, upon the request of any Cov-ered OEM licensee or Third-Party Li-censee, and supports both directly andindirectly, an otherwise identical but‘‘unbound’’ Windows Operating SystemProduct TTTT

SPR § 1, 6 J.A. (II) at 3166. In otherwords, Microsoft would be required tomake it possible for OEMs and end usersto ‘‘readily remove or uninstall [from Win-dows] the binary code’’ of any MicrosoftMiddleware Product (as that term is de-fined in the States’ proposal). Id. §§ 22.d& 22.e, 6 J.A. (II) at 3193. The districtcourt found evidence the States’ proposal‘‘would hinder, or even destroy Microsoft’sability to provide a consistent API set.’’States’ Remedy, at 252. This evidenceincluded testimony that it would be

impossible for Microsoft to maintain thesame high level of operating-system bal-ance and stability on which software de-velopers and customers rely. Develop-ers will be less likely to write softwareprograms to an unstable or unpredict-able operating system based on the riskthat their programs will not function asdesigned, thereby reducing customersatisfaction.

4. Massachusetts also argues the district courterred insofar as it rejected the States’ propos-al because the proposal did not provide ade-quate guidance for determining which codeconstitutes Microsoft middleware and wasotherwise too difficult technically. The dis-

trict court’s findings, however, discussed inpart at the outset of this section, fully supportits reasons for rejecting the States’ unbindingremedy. See States’ Remedy, 245-52; see alsoid. at 255.


Direct Testimony of Scott Borduin ¶ 61, 2J.A. (II) at 1327.5 The district court con-cluded, ‘‘The weight of the evidence indi-cates the fragmentation of the Windowsplatform would be significantly harmful toMicrosoft, ISVs, and consumers.’’ States’Remedy, at 253.

Massachusetts argues the districtcourt’s finding ‘‘ignores and is at odds withthis Court’s holding that Microsoft’s desireto keep developers focused on its APIswas merely another way of saying it ‘wantsto preserve its power in the operatingsystem market,’ ’’ citing Microsoft III, at71. Indeed, as we stated in Microsoft III,‘‘Microsoft’s only explanation for its exclu-sive dealing [contracts with Internet Ac-cess Providers (IAPs) ] is that it wants tokeep developers focused upon its APIs —which is to say, it wants to preserve itspower in the operating system market.’’Id. We went on to state, however, thatthis ‘‘is not an unlawful end, but neither isit a procompetitive justification for thespecific means here in question, namely,exclusive dealing contracts with IAPs.’’Id.

Massachusetts would turn our observa-tion about Microsoft’s rationale for its ex-clusive contracts with IAPs into a critiqueof the district court’s concern with theextreme fragmentation of Windows thecourt found was likely to occur if itadopted the States’ code removal proposal.But the two points cannot be equated.The States made a proposal the districtcourt found might have resulted in therebeing ‘‘more than 1000’’ versions of Win-dows. See States’ Remedy, at 253 (citingDirect Testimony of Dr. John Bennett¶¶ 47, 55, 5 J.A. (II) at 2997-98, 3001).Letting a thousand flowers bloom is usual-

ly a good idea, but here the court foundevidence, as discussed above, that suchdrastic fragmentation would likely harmconsumers. See also Direct Testimony ofDr. Kenneth Elzinga ¶ 102, 5 J.A. (II) at2739-40 (‘‘Lowering barriers to entry bydestroying TTT real benefits TTT harmsconsumers and is not pro-competitive’’).Although it is almost certainly true, asboth Massachusetts and the amici claim,that such fragmentation would also pose athreat to Microsoft’s ability to keep soft-ware developers focused upon its APIs,addressing the applications barrier to en-try in a manner likely to harm consumersis not self-evidently an appropriate way toremedy an antitrust violation. See BrookeGroup Ltd. v. Brown & Williamson To-bacco Corp., 509 U.S. 209, 224, 113 S.Ct.2578, 2588, 125 L.Ed.2d 168 (1993) (‘‘It isaxiomatic that the antitrust laws werepassed for ‘the protection of competition,not competitors,’ ’’ quoting Brown Shoe Co.v. United States, 370 U.S. 294, 320, 82S.Ct. 1502, 1521, 8 L.Ed.2d 510 (1962)(emphases in original)).

The district court’s end-user access pro-vision fosters competition by opening thechannels of distribution to non-Microsoftmiddleware. It was Microsoft’s foreclo-sure of those channels that squelched nas-cent middleware threats and furthered thedominance of the API set exposed by itsoperating system. The exclusive contractsinto which Microsoft entered with IAPswere likewise aimed at foreclosing chan-nels through which rival middleware mightotherwise have been distributed. Prohibit-ing Microsoft from continuing those exclu-sive arrangements, see States’ Remedy§ III.G, at 269-70, would not have the

5. See also Madnick ¶ 197, 5 J.A. (II) at 2899(‘‘To the extent that licensees used the non-settling States’ remedies to create multipleversions of Windows with differing combina-tions of APIs, applications developers and

consumers would lose one of the greatestbenefits of Windows — a platform for applica-tions that supports new functionality whileproviding backward compatibility for mostexisting applications’’).


same deleterious effect upon consumers aswould the fragmentation of Windows.

Amici CCIA and SIIA seem to viewfragmentation as merely competition byanother name. Accordingly, they see frag-mentation as a natural, if only temporary,consequence of economic forces: ‘‘Compe-tition of any kind will lead to a multiplicityof standards, at least temporarily.’’ Theredesign of Windows required by theStates’ proposal, however, would not bethe result of competition on the merits, asCCIA and SIIA seem to suggest. Cer-tainly they point to no economic force thatwould prompt (or, if such a redesign weremandated, sustain) the degree of fragmen-tation the States’ proposal is predicted toproduce. Nor do they explain how suchfragmentation would, as they claim, ‘‘sparkinnovation that benefits consumers.’’They instead quote National Society ofProfessional Engineers (NSPE) v. UnitedStates, 435 U.S. 679, 689, 98 S.Ct. 1355,1364, 55 L.Ed.2d 637 (1978), for the propo-sition that the Supreme Court has ‘‘fore-close[d] the argument that because of thespecial characteristics of a particular in-dustry, monopolistic arrangements willbetter promote trade and commerce thancompetition.’’ But that case provides nosupport for CCIA’s and SIIA’s argumenthere. Like the two cases the SupremeCourt cited in making the statement justquoted, see United States v. Trans-Mis-souri Freight Ass’n, 166 U.S. 290, 17 S.Ct.540, 41 L.Ed. 1007 (1897); and UnitedStates v. Joint Traffic Ass’n, 171 U.S. 505,19 S.Ct. 25, 43 L.Ed. 259 (1898), NSPEinvolved an agreement among competitors

limiting the output of their services.Those arrangements, which were analyzedunder § 1 of the Sherman Act, are notanalogous to Microsoft’s monopoly of themarket for operating systems, which is duenot only to the exclusionary practices wefound unlawful in Microsoft III but also to‘‘positive network effects,’’ see Findings ofFact, at 20. Moreover, in NSPE the dis-trict court made no findings there wereany potential benefits from the profes-sion’s ‘‘ethical prohibition against competi-tive bidding.’’ 435 U.S. at 686, 98 S.Ct. at1362. In sharp contrast, here the districtcourt made extensive findings both aboutthe potential harm to consumers fromfragmentation and about the dubious bene-fits of the States’ proposal.6 From thesefindings the court concluded, ‘‘There is noindication that there is any competitive oreconomic advantage to [the degree of frag-mentation entailed in the States’ proposal]and, quite to the contrary, such a resultwould likely be detrimental to the consum-er.’’ States’ Remedy, at 252-54. Althoughwe understand that competition on themerits itself would likely elicit multiplestandards — recall the competition be-tween the VHS and Beta videotape stan-dards — or even that some as yet unimag-ined technology might reduce the harm toconsumers from fragmentation, CCIA andSIIA fail to demonstrate the district courtwas unduly concerned about the extent offragmentation likely to arise from theStates’ proposal.

Finally, Massachusetts argues the dis-trict court’s findings relating to fragmenta-tion ‘‘fail to respect’’ the findings of fact

6. For example, the court found that ISVswould ‘‘fare worst’’ under the proposal be-cause they ‘‘would not have any assurancethat a particular functionality was present inany given configuration of the new unboundWindows [which,] at least in the short termTTT would likely cause existing applications tofail. [In the longer run there is the risk that]

software code distributed with one ISV’s ap-plication would conflict with that distributedwith another ISV’s application, leading to theso-called ‘DLL Hell’ problem that resultswhen multiple versions of the same basiccomponents try to coexist on a single PC.’’States’ Remedy, at 253-54.


made in the liability proceedings. Specifi-cally, the Commonwealth points to Find-ings of Fact ¶ 193, at 56-57: ‘‘Microsoft’scontention that offering OEMs the choiceof whether or not to install certain brow-ser-related APIs would fragment the Win-dows platform is unpersuasive.’’ Thatstatement was addressed to the unbindingof IE and Windows, not to the States’proposal, from which the court anticipatedfar more extensive fragmentation. Thedistrict court’s rejection of the States’ pro-posal, therefore, is not inconsistent withany of the findings of fact in the liabilityproceedings.

Relatedly, the amici point to ‘‘Micro-soft’s own fragmentation’’ of Windowsthrough the publication of successive ver-sions, such as Windows 98, Windows 2000,and Windows XP. The district court ad-dressed this concern and found such frag-mentation to be of ‘‘relatively small de-gree’’ because ‘‘Microsoft is able to worktowards maintaining backward compatibili-ty with previous versions.’’ States’ Reme-dy, at 253.

To be sure, the remedy the district courtadopted does not prevent all fragmentationof the Windows operating system; indeed,it adopted the end-user access provision,which allows OEMs to install rival brow-sers and other non-Microsoft middleware,with their associated APIs, and to removethe end user’s access to IE. Accordingly,fragmentation may yet occur, but if so itwill be caused by OEMs competing tosatisfy the preferences of end users, notforced artificially upon the market as itwould be under the States’ proposal.

2. Java deception

[4] Massachusetts argues the districtcourt erred in not including a remedyaddressed specifically to Microsoft’s de-ception of Java software developers.Unbeknownst to Java software develop-

ers, Microsoft’s Java developer tools in-cluded certain words and directives thatcould be executed only in Windows’ Javaruntime environment. We held this de-ception ‘‘served to protect [Microsoft’s]monopoly of the operating system in amanner not attributable either to the su-periority of the operating system or tothe acumen of its makers, and thereforewas anticompetitive.’’ Microsoft III, at77. Because Microsoft failed to providea procompetitive explanation for its de-ception of software developers — indeed,there appears to be no purpose at all forthe practice that would not itself be anti-competitive — we held its conduct wasexclusionary, in violation of § 2 of theSherman Act. Id.

On remand the district court found alack of ‘‘any evidence’’ Microsoft’s previousJava deception was a continuing threat tocompetition. States’ Remedy, at 265. TheJava deception ‘‘concern[ed] a single, veryspecific incident of anticompetitive conductby Microsoft,’’ which conduct Microsofthad ceased in accordance with a consentdecree into which it had entered in anothercase in another court. Id. For thesereasons, the district court did not include aprovision in the remedial decree addressedto this unlawful but now terminated con-duct.

Massachusetts, quoting United States v.W.T. Grant Co., 345 U.S. 629, 632, 73 S.Ct.894, 897, 97 L.Ed. 1303 (1953), claims thatwithout specific relief prohibiting such de-ception, Microsoft is ‘‘free to return to [its]old ways.’’ Microsoft responds that Mas-sachusetts does not make a showing of thetype of abuse contemplated by the Su-preme Court in W.T. Grant. We agree.That case involved an interlocking di-rectorate allegedly unlawful under § 8 ofthe Clayton Act. Soon after the Govern-ment filed suit, the common director volun-tarily resigned from the relevant boards,


after which the district court refused theGovernment’s request for an injunctionprohibiting him and the corporations fromviolating § 8 in the future. The SupremeCourt held the defendants’ sworn profes-sion of an intention not to revive the inter-lock was insufficient to moot the case.However, the Court also held — and thisis key — the district court was in the bestposition to determine whether there was a‘‘significant threat of [a] future violation,’’and it had not abused its discretion inrefusing to award injunctive relief. Id. at635-36, 73 S.Ct. at 899. Far from support-ing Massachusetts’ argument, therefore,W.T. Grant confirms the district court’sbroad discretionary power to withhold eq-uitable relief as it reasonably sees fit.

Massachusetts maintains the districtcourt abused its discretion insofar as itfound ‘‘no evidence that this deception, orany similar deception, has persisted.’’States’ Remedy, at 190. Massachusettshere claims Microsoft’s Chairman andChief Software Architect, William GatesIII, in testimony ‘‘admitted that Microsoftroutinely makes knowingly inaccurateclaims regarding its compliance with in-dustry standards,’’ into which the districtcourt should have inquired further. Thecited testimony in fact concerns Micro-soft’s efforts to comply with frequentlychanging standards.7 Not surprisingly,nothing Gates said suggests anything inthe least nefarious.

Despite its failure to demonstrate anycontinuing competitive threat from Micro-soft’s previous deception of Java softwaredevelopers, Massachusetts presses theStates’ proposed ‘‘truth in standards’’ pro-vision, which would regulate certain busi-ness practices that were not at issue in

Microsoft III. Specifically, the States’proposal would require Microsoft to (1)continue supporting any industry standardit has publicly claimed to support ‘‘until itpublicly disclaims such support or thestandard itself expires or is rescinded bythe standard-setting body,’’ and (2) ‘‘con-tinue to support an industry standard anytime it makes a proprietary alteration tothe standard.’’ Id. at 190; see also SPR§ 16, 6 J.A. (II) at 3183. As an initialmatter, our holding the district court didnot abuse its discretion in refusing to en-join a recurrence of Microsoft’s Java de-ception casts grave doubt upon the needfor a broad provision applicable not only toJava but to all industry standards. Bethat as it may, we address Massachusetts’arguments in favor of such a provision.

First Massachusetts claims the districtcourt erred as a matter of law insofar as itregarded the proposed truth-in-standardsprovision as being ‘‘unrelated to the viola-tion found by th[is] court.’’ That is not,however, how the district court saw thematter. Addressing only the first require-ment quoted in the previous paragraph,the district court specifically referred toMicrosoft’s deception of Java developers inholding there was no showing a ‘‘broadorder’’ prohibiting any similar deceptionwas ‘‘either appropriate or necessary.’’See States’ Remedy, at 190. It never saidthat requirement was ‘‘unrelated’’ to theviolations found by this court in MicrosoftIII. That much we think is unarguable.

As Microsoft correctly points out, it wasthe second aspect of the truth-in-standardsprovision the district court deemed ‘‘unre-lated to any finding of liability,’’ id. at 190,263-64, and correctly so. Indeed, thiscourt held that Microsoft’s development of

7. See 4/24/02 pm Tr. at 4988-89 (Gates trialtestimony), 6 J.A. (II) at 3141-42; see alsoDirect Testimony of Dr. Andrew Appel ¶ 145,2 J.A. (II) at 1303-04 (stating Microsoft has

ability to mislead third parties with respect tostandards, but giving neither instances norany indication of likelihood of such conduct).


the Windows Java Virtual Machine (JVM),which was incompatible with Sun’s JVM,did not violate the antitrust laws. Micro-soft III, at 75. It was only Microsoft’shaving misled software developers intothinking the two were compatible that hadan anticompetitive effect. Id. at 76-77.We therefore hold the district court per-missibly refused to require that Microsoftcontinue to support a standard after mak-ing a proprietary modification to it, even ifthe modification makes the standard in-compatible with the original.

Massachusetts also complains the recorddoes not support the district court’s otherreasons for rejecting the proposed truth-in-standards provision. We disagree. Thedistrict court found no evidence the ‘‘indus-try standard’’ provision would ‘‘enhancecompetition in the monopolized market’’for Intel-compatible PC operating systems.States’ Remedy, at 264 & n. 134. Compli-ance with industry standards is ‘‘largely asubjective undertaking,’’ id. at 190, suchthat ‘‘full compliance with a standard isoften a difficult and ambiguous process,’’id. at 264 (quoting Madnick ¶ 208, 5 J.A.(II) at 2905). Massachusetts points to nospecific instance in which competitionwould have been or would be enhanced bycompelling Microsoft to support an indus-try standard after it made a proprietaryalteration thereto. Instead Massachusettsinvokes expert testimony that Microsoft’sproprietary control over ‘‘important inter-faces’’ would make it ‘‘harder’’ for rivaloperating systems to compete with Win-dows. Direct Testimony of Dr. Carl Sha-piro ¶ 185, 2 J.A. (II) at 860. This is fartoo general a statement from which toinfer the proposed truth-in-standards pro-vision would enhance competition ratherthan merely assist competitors — and per-haps retard innovation. The district courtfound that industry standards can ‘‘varywidely in complexity and specificity, suchthat various implementations of a particu-

lar standard are often incompatible.’’States’ Remedy, at 264 (quoting Madnick¶ 207, 5 J.A. (II) at 2904). Microsoft,therefore, may not be able to comply withsome of the industry standards contem-plated by the States’ proposal. And theStates’ own economic expert testified that‘‘slow-moving standards bodies’’ are com-monly unable to keep up with rapidlychanging technology markets. 4/14/02 pmTr. at 3677 (Shapiro trial testimony), 8 J.A.(II) at 4572; see also CARL SHAPIRO & HALR. VARIAN, INFORMATION Rules 240 (1999)(advocating business strategy that doesnot ‘‘freeze TTT activities during the slowstandard-setting process’’).

The district court aptly described theproblems with the States’ truth-in-stan-dards proposal and correctly concluded theproposed remedy went beyond the liabilitycontemplated by this court. The court didnot abuse its discretion, therefore, in re-fusing to adopt the proposal.

3. Forward-looking provisions

[5] The district court exercised its dis-cretion to fashion appropriate relief byadopting what it called ‘‘forward-looking’’provisions, which require Microsoft to dis-close certain of its APIs and communica-tions protocols. Although non-disclosureof this proprietary information had playedno role in our holding Microsoft violatedthe antitrust laws, ‘‘both proposed reme-dies recommend[ed] the mandatory disclo-sure of certain Microsoft APIs, technicalinformation, and communications protocolsfor the purposes of fostering interopera-tion.’’ States’ Remedy, at 171. In approv-ing a form of such disclosure — while, asdiscussed below, rejecting the States’ pro-posal for vastly more — the district courtexplained ‘‘the remedy [must] not [be] soexpansive as to be unduly regulatory orprovide a blanket prohibition on all futureanticompetitive conduct.’’ Id. (citing Ze-


nith Radio Corp. v. Hazeltine Research,Inc., 395 U.S. 100, 133, 89 S.Ct. 1562, 1581,23 L.Ed.2d 129 (1969)). We are also mind-ful that, although the district court is ‘‘em-powered to fashion appropriate restraintson [Microsoft’s] future activities both toavoid a recurrence of the violation and toeliminate its consequences,’’ NSPE, 435U.S. at 697, 98 S.Ct. at 1368, the resultingrelief must ‘‘represent[ ] a reasonablemethod of eliminating the consequences ofthe illegal conduct,’’ id. at 698, 98 S.Ct. at1368.

a. Disclosure of APIs

[6] The district court recognized the‘‘hallmark of the platform threat’’ to theWindows monopoly posed by rival mid-dleware is the ability to run on multipleoperating systems: The ‘‘ready ability tointeroperate with the already dominantoperating system will bolster the abilityof such middleware to support a widerange of applications so as to serve as aplatform.’’ States’ Remedy, at 172. Inorder to facilitate such interoperation thedistrict court required Microsoft to dis-close APIs ‘‘used by Microsoft Middle-ware to interoperate with a Windows Op-erating System Product.’’ Id. § III.D, at268.

Massachusetts objects to this provisionon several grounds. First, the Common-wealth argues ‘‘the middleware covered by§ III.D lacks the platform potential of themiddleware threat that Microsoft thwart-ed’’ and, therefore, ‘‘will necessarily be in-adequate to restore competition.’’ The va-lidity of Massachusetts’ objection dependsupon the meaning of ‘‘Microsoft Middle-ware.’’

Microsoft Middleware is defined as‘‘software code’’ that:

1. Microsoft distributes separatelyfrom a Windows Operating SystemProduct to update that Windows Op-erating System Product;

2. is Trademarked or is marketed byMicrosoft as a major version of anyMicrosoft Middleware Product TTT;and

3. provides the same or substantiallysimilar functionality as a MicrosoftMiddleware Product.

Id. § VI.J, at 275. A ‘‘Microsoft Middle-ware Product’’ includes, among otherthings, ‘‘the functionality provided by In-ternet Explorer, Microsoft’s Java VirtualMachine, Windows Media Player, WindowsMessenger, Outlook Express and theirsuccessors in a Windows Operating Sys-tem Product.’’ Id. § VI.K, at 275.

In support of its argument, Massachu-setts notes that Microsoft’s own experts‘‘doubted the platform potential of severalforms of middleware included in what be-came the remedy’s definition.’’8 In re-sponse, Microsoft points out that the defi-nition of ‘‘Microsoft Middleware’’ adoptedby the district court is not faulty simplybecause Microsoft’s experts discounted asplatform threats some of the middlewareproducts it covers. The logic of that re-sponse is obvious, which makes it unsur-prising that Massachusetts makes no re-ply.

Amici CCIA and SIIA take a differenttack, claiming the definition is defectivebecause Microsoft itself determines whichsoftware code to distribute separately.Microsoft responds that the amici ‘‘ig-nore[ ] the thousands of Windows APIs

8. E.g., Direct Testimony of Dr. Kevin Murphy¶ 176, 5 J.A. (II) at 2648 (‘‘the definition of‘Middleware’ includes some products thatpose no apparent (even nascent) threat to theoperating system’’); Elzinga ¶ 135, id. at 2754

(‘‘particularly implausible that an email client(such as Outlook Express) or instant messag-ing software (such as Windows Messenger)will become a platform threat’’).


that Microsoft publicly discloses in the or-dinary course of business,’’ and cites testi-mony, most of it conclusory, extolling theadequacy of those APIs for software devel-opers. See, e.g., Direct Testimony ofBrent Frei of Onyx Software ¶¶ 18-22, 6J.A. (II) at 3413-15; Direct Testimony ofChris Hofstader of Freedom Scientific¶¶ 57-59, 9 J.A. (II) at 5453-55. Be that asit may, the district court considered argu-ments by the States similar to the one nowadvanced by the amici, and it rejected therelated testimony of the States’ witnesses.States’ Remedy, at 116-17. The court in-stead found ‘‘Microsoft often distributesseparately certain technologies which areincluded in new releases of Windows be-cause such distribution enables users ofprevious Windows versions to take advan-tage of the latest improvements to thesetechnologies.’’ Id. at 117 (citing DirectTestimony of Microsoft’s ChristopherJones ¶ 61, 5 J.A. (II) at 2532, and WillPoole ¶ 76, 5 J.A. (II) at 2493). The courtexplained:

Such distribution benefits Microsoft, asit permits Microsoft to continually im-prove the quality of its products, evenafter they are sold, and to expand theuser base of new technology withoutwaiting for consumers to purchase anentirely new operating system.

Id. These benefits would be lost to Micro-soft if it were to ‘‘manipulate its productsto exclude specific code from the defini-tion’’ of middleware. Id.

The amici do not deny Microsoft hasroutinely distributed its middleware sepa-rately from Windows. Instead, they spec-ulate Microsoft may henceforth avoid sep-arate distribution in order to avoid thedisclosure contemplated by § III.D. Theyclaim an expanded definition of middle-ware, such as that proposed by the States,is necessary to ‘‘prevent[ ] Microsoft from

defining its obligations into meaninglesssuperficiality.’’

Microsoft points to the district court’sfinding, supported by evidence in the rec-ord, that it is not necessary or even de-sirable, in order to remove the artificialimpediments erected by Microsoft to theestablishment of a platform threat toWindows, to expand the definition of Mi-crosoft middleware to cover all softwarethat ‘‘expose[s] even a single API.’’ Id.at 118-19. The district court rejected theStates’ broader definition of middlewarein part because it wanted ‘‘bright lines bywhich Microsoft can determine what por-tions of Windows code are affected by theremedy.’’ Id. at 117. The amici do notrespond to the district court’s concernsabout the expansive scope of the States’definition of middleware. Nor do theyexplain how the States’ proposal would‘‘identify the specific pieces of Windows,’’id., constituting middleware for the pur-pose of Microsoft’s disclosure obligation.Instead, they merely claim the States’proposal ‘‘add[s] sufficient precision toidentify and enforce a concrete obli-gation.’’ This unreasoned assertion ishardly a ground upon which to overturnthe district court’s reasoned explanationfor adopting a ‘‘bright line[ ]’’ approach toMicrosoft’s disclosure obligation. Fur-ther, the amici fail to refute the districtcourt’s reasoning that ‘‘economic forcesTTT countervail the likelihood’’ that Micro-soft would stop separately distributing itssoftware code in order to avoid having todisclose APIs pursuant to § III.D. Id.

We hold the district court did not abuseits discretion in delineating the middlewarecovered for the purposes of disclosure. Asdiscussed, the term ‘‘Microsoft Middle-ware’’ both includes and extends beyondthe functionality of the middleware at issuein this case. Id. §§ VI.J & VI.K, at 275-76; see also id. at 115. The amici merely


speculate that the middleware covered by§ III.D will not provide a serious platformthreat. Moreover, the district court’s rea-sons for believing economic self-interestdeters Microsoft from avoiding separatedistribution of its software code are per-suasive. And we should be particularlydisinclined to require more disclosurewhere, as here, the district court is adopt-ing a forward-looking provision addressingconduct not previously held to be anticom-petitive. See generally, Frank H. Easter-brook, The Limits of Antitrust, 63 TEX.L.REV. 1, 14-15 (1984) (supporting use ofpresumptions in antitrust law to avoid con-demning procompetitive practices). None-theless, out of an abundance of caution thedistrict court provided that, in the eventMicrosoft were to ‘‘make a practice’’ ofsacrificing the advantages of separate dis-tribution in order to frustrate the purposeof the remedy, Massachusetts ‘‘could peti-tion the Court for relief on this point.’’9

States’ Remedy, at 117 n.34.

Massachusetts further argues the dis-trict court made no finding the requireddisclosure of APIs under the decreewould ‘‘meaningfully assist’’ developers ofmiddleware. Massachusetts objects bothto the breadth of disclosure — that is,

the number of APIs to be disclosed under§ III.D — and to the ‘‘depth’’ or detail ofthe disclosure, with respect to whichMassachusetts claims ‘‘the remedy fails torequire the disclosure of sufficient infor-mation to ensure that the mandated dis-closure may be effectively utilized.’’

As to breadth, § III.D by its terms ex-pands the scope of required disclosure be-yond the functionality of the middleware atissue in our decision on liability, as dis-cussed above. Such expanded but not un-limited disclosure ‘‘represents a reasonablemethod’’ of facilitating the entry of com-petitors into a market from which Micro-soft’s unlawful conduct previously excludedthem, NSPE, 435 U.S. at 698, 98 S.Ct. at1368, particularly in view of the inherentlyuncertain nature of this forward-lookingprovision.

Moreover, in laying claim to still broad-er disclosure of APIs, Massachusetts sim-ply ignores the district court’s findingswith respect to the economic and techno-logical effects of disclosure. As Microsoftpoints out, however, these findings reflectthe district court’s concern that a forward-looking provision requiring overly broaddisclosure could undermine Microsoft’s in-

9. Massachusetts also argues the district courtabused its discretion by refusing to defineMicrosoft’s Common Language Runtime(CLR) as a Microsoft Middleware Product andhence subject to the API-disclosure require-ment of § III.D. The district court describedthe CLR as middleware similar to Java but apart of Microsoft’s new ‘‘.NET framework,’’ aWeb-services initiative comprising ‘‘server-based applications that can be accessed di-rectly by other software programs, as well asby the consumer through a variety of devices,including the PC, cellular phone, and han-dheld device.’’ States’ Remedy, at 126; seealso Borduin ¶ 80, 2 J.A. (II) at 1333 (explain-ing importance of CLR in .NET initiative). Asdiscussed in Part II.A.4 below, the districtcourt refused to address Web services in theremedial decree, stating that ‘‘this case can-not be used as a vehicle by which to fight

every potential future violation of the antitrustlaws by Microsoft envisioned by Microsoft’scompetitors.’’ States’ Remedy, at 133. Justso, and the district court therefore did notabuse its discretion by refusing to list the CLRalong with the other functionalities specifiedin the definition of Microsoft MiddlewareProduct. See id. at 275. Because Microsoft’sWeb-services initiative and Microsoft Middle-ware are not mutually exclusive categories,however, the CLR may yet become subject tothe disclosure requirement of § III.D if itsatisfies the definition of Microsoft Middle-ware in the decree, see States’ Remedy § VI.J,at 275. That definition requires, among otherthings, the middleware to be ‘‘distribute[d]separately’’ from Windows; according to Mi-crosoft’s counsel at oral argument, there isrecord evidence that has already occurred.


centive to innovate and, more particularly,that the States’ proposed disclosure provi-sion could enable competitors to ‘‘clone’’Windows. The extremely broad scope ofthe States’ proposal bears out the districtcourt’s concern. First, ‘‘interoperate’’ isdefined in a way that makes it essentiallysynonymous with ‘‘interchange.’’ SeeStates’ Remedy, at 227 (citing Madnick¶ 86, 5 J.A. (II) at 2836-37). Meanwhile,§ 4 of the SPR would require Microsoft todisclose ‘‘all APIs’’ that enable any ‘‘Micro-soft Middleware Product,’’ Microsoft appli-cation, or Microsoft software program tointeroperate with ‘‘Microsoft PlatformSoftware.’’ 6 J.A. (II) at 3172-73. Final-ly, ‘‘Microsoft Middleware Product’’ and‘‘Microsoft Platform Software’’ are definedso broadly that, when required to ‘‘inter-operate’’ with one another, they includeessentially any two pieces of Microsoftsoftware on a PC. See States’ Remedy, at227-28; see also Gates ¶ 296, 8 J.A. (II) at4772-73; Madnick ¶¶ 148-49, 151, 5 J.A.(II) at 2870, 2872. As a result, the districtcourt found the broad scope of the APIsrequired to be disclosed under the States’proposal would give rivals the ability toclone Microsoft’s software products; 10 andcloning would allow them to ‘‘mimic’’ thefunctionality of Microsoft’s products rather

than to ‘‘create something new.’’ States’Remedy, at 229. They could also ‘‘developproducts that implement Microsoft’s Win-dows technology at a far lower cost [thanMicrosoft itself] since they would have ac-cess to all of Microsoft’s research and de-velopment investment.’’ Id. The effectupon Microsoft’s incentive to innovatewould be substantial; not even the broadremedial discretion enjoyed by the districtcourt extends to the adoption of provisionsso likely to harm consumers.

The amici claim the district court’s‘‘concern about ‘cloning’ TTT rested in parton a misunderstanding of what an API is.’’This assertion is simply at odds with thetestimony upon which the district courtrelied in concluding competitors couldclone Microsoft’s software and mimic itsfunctionality.11 Moreover, the amici failentirely to address the district court’s con-clusion, based upon findings of fact, thatcloning would deny ‘‘Microsoft the returnsfrom its investment in innovation.’’12 Id.at 176.

Microsoft also points to the adversetechnological effects that would have en-sued from broader disclosure of its inter-nal interfaces. The district court foundoverly broad disclosure of APIs would lim-

10. See, e.g., States’ Remedy, at 227 (citing5/10/02 pm Tr. at 7111-12 (Bennett trial testi-mony), 6 J.A. (II) at 3596 (‘‘Well, if you read[the definition of Interoperate], it says: Effec-tively, access, utilize and/or support the fullfeatures and functionality of one another.That, to me, taken in its entirety TTT meansthe ability to clone.’’)).

11. See, e.g., States’ Remedy, at 229 (citingGates ¶¶ 289-90, 8 J.A. (II) at 4770-71 (‘‘Onceprovided with the equivalent of the blueprintsfor Windows, competitors TTT would have lit-tle trouble writing their own implementationof everything valuable that Windows providestoday, including the capabilities it provides todevelopers via APIs’’)).

12. In a footnote to its argument concerningthe disclosure of communications protocols,

Massachusetts asserts the district court clear-ly erred in suggesting the States’ proposeddefinition could lead to cloning, for whichassertion it cites the opinion of Dr. Appel that‘‘the States’ Remedy does not allow suchcopying,’’ ¶ 99, 2 J.A. (II) at 1284; see also¶¶ 100-07, id. at 1284-88. This testimony,although contrary to the district court’s find-ing that the States’ broad definition of inter-operation could lead to cloning, is hardlysufficient for us to conclude the districtcourt’s finding is clearly erroneous. See Mi-crosoft III, at 66 (‘‘In view of the contradicto-ry testimony in the record, some of whichsupports the District Court’s finding TTT, wecannot conclude that the finding was clearlyerroneous’’).


it Microsoft’s ability to modify interfaces, alimitation that ‘‘threatens to stifle innova-tion and product flexibility.’’ Id. at 177.The court also found that disclosure ofinternal interfaces, which the States’ pro-posal would require, would force Microsoftto publish APIs where the interfaces areunstable. Id. at 230-31. That ‘‘could posea substantial threat to the security andstability of Microsoft’s software,’’ id. at231; reliance upon such interfaces may‘‘cause third-party software not to work orWindows to crash,’’ id. at 230. Massachu-setts does not challenge any of these find-ings, although they clearly support thedistrict court’s refusal to require the broaddisclosure of APIs proposed by the States.

Massachusetts also insists the depth ofMicrosoft’s required disclosure under§ III.D is ‘‘inadequate.’’ The Common-wealth first argues the depth of Micro-soft’s disclosure obligation is unclear be-cause the definition of ‘‘API’’ is circularand non-specific. The term is defined in§ VI.A as an ‘‘application programminginterface, including any interface that Mi-crosoft is obligated to disclose pursuant toIII.D.’’ Id. § VI.A, at 274. Massachu-setts points to the testimony of the States’computer science expert, who said ‘‘Micro-soft’s definition of ‘API’ is almost entirelya circular reference to Section III.D, and ittherefore does not adequately define whatinformation must be provided as part ofthe API disclosure.’’ Appel ¶ 60, 2 J.A.(II) at 1269. We note that most of thisexpert’s testimony regarding the definitionof API is a legal analysis rather than theopinion of a computer scientist and is

therefore beyond the ‘‘knowledge, skill, ex-perience, training, or education’’ for whichhe was qualified as an expert. FED. R.EVID. 702. In any event, his legal analysisis wrong; the definition of API is notcircular. API is defined in two places inthe decree. The definition quoted aboveand cited by the States’ computer expert isthe one found in the ‘‘Definitions’’ sectionof the decree for the use of the term inevery section of the decree other than§ III.D. See States’ Remedy § VI.A, at274. The term is defined separately in§ III.D, for the purpose of Microsoft’s dis-closure obligation under that section, as‘‘the interfaces, including any associatedcallback interfaces,’’ that permit MicrosoftMiddleware to obtain ‘‘services’’ from Win-dows. Microsoft clearly understood, asthe States’ computer expert apparently didnot, the latter definition is the one applica-ble to Microsoft’s disclosure of APIs underthe decree.13

Second, Massachusetts claims there isunrebutted testimony in the record indicat-ing the depth of disclosure mandated by§ III.D is not ‘‘adequate for those whoseinnovative software constitutes a potentialthreat to Windows.’’ The cited testimony,however, does not cast doubt upon thedistrict court’s decision. The witnesses ex-pressed concern that the extent of Micro-soft’s obligation to disclose file formats,registry settings, and similar informationis unclear and explained the type of en-hanced disclosure software developerswould like, but the testimony amounts tono more than conclusory statements.14

13. See States’ Remedy, at 235; see also 5/2/02pm Tr. at 6128 (Poole trial testimony) (statingin response to question whether he knew ‘‘ex-actly’’ which APIs Microsoft is obliged to dis-close under § III.D: ‘‘Yes. We know how tolook for the list of points they [sic] make theirinterfaces, associated call back interfaces, etcetera, and ensure that we are in compliance

relative to the code that we separately distrib-ute.’’).

14. For instance, one developer requested dis-closure of certain ‘‘complicated interfaces’’that Microsoft ‘‘had not anticipated’’ softwaredevelopers needing. 3/26/02 pm Tr. at 1452-53 (trial testimony of Steven McGeady), 6 J.A.(II) at 3375-76; see also 3/20/02 pm at Tr. at


That software developers prefer more,rather than less, expansive and detaileddisclosure of APIs and technical informa-tion is hardly surprising, but the testimonyis not sufficient to support Massachusetts’implication that the disclosures requiredby § III.D will not materially assist devel-opers of potential middleware threats toWindows. Recall the district court did notundertake to assure the viability of Micro-soft’s rivals. Rather, the court settledupon a level of disclosure that would ‘‘bol-ster’’ the ability of rival middleware toserve as a platform threat to Microsoft;‘‘help’’ rival middleware interoperate withWindows; and ‘‘have the potential to in-crease the ability of competing middlewareto threaten [Windows].’’ Id. at 172.

Finally, Massachusetts argues the dis-closure mandated by § III.D need not betimely made. In the case of a ‘‘new majorversion of Microsoft Middleware,’’ § III.Drequires disclosure ‘‘no later than the lastmajor beta test release of that MicrosoftMiddleware.’’ For a new version of Win-dows, disclosure must occur in a ‘‘TimelyManner,’’ defined as the time of the firstrelease of a beta test version of Windowsthrough the Microsoft Developer Networkor upon the distribution of 150,000 or morecopies of the beta version. Id. § VI.R, at276.

Massachusetts nonetheless insists ‘‘[t]heremedy is at odds with the record ontimeliness.’’ Microsoft responds by point-ing to evidence that requiring disclosure‘‘before the software code underlying thoseAPIs has been fully developed and tested,as the TTT States requested, would createserious logistical problems for both Micro-soft and third-party software developers.’’

See, e.g., Direct Testimony of Microsoft’sLinda Wolfe Averett ¶ 18, 6 J.A. (II) at3261 (‘‘Until Microsoft is confident that ithas figured out how to provide a particularfunctionality, it does not want third-partydevelopers building products that rely onour functionality’’). Although clearly fa-voring the definitions of timeliness adoptedby the district court, Microsoft’s evidenceis not required in this instance because thetestimony Massachusetts cites itself under-scores Microsoft’s ‘‘strong incentive’’ todisclose its APIs in a timely fashion so thatsoftware developers will write applicationsbased upon them. See, e.g., Borduin ¶ 35,2 J.A. (II) at 1318-19. Without timelydisclosure, ‘‘there would be far fewer andlower quality programs written for Micro-soft’s operating systems.’’ Id. Microsoft’sincentive to make timely disclosure ofAPIs is obvious: the ability of softwaredevelopers to write applications that relyupon Microsoft’s APIs depends upon thedevelopers having access to them. As thedistrict court found in the liability phase,‘‘Microsoft must convince ISVs to writeapplications that take advantage of thenew APIs, so that existing Windows userswill have [an] incentive to buy an up-grade.’’ Findings of Fact ¶ 44, at 21-22.The court also found Microsoft offered in-ducements to software developers to en-sure they ‘‘promptly develop new versionsof their applications adapted to the newestversion of Windows.’’ Id. Massachusettspoints to no evidence, and offers no reasonto think, this incentive is insufficient toinduce timely disclosure under § III.D ofthe decree. To the contrary, the evidenceMassachusetts offers merely confirms theeconomic incentives Microsoft faces in re-

732-35 (trial testimony of David Richards ofRealNetworks), id. at 3404-05 (requesting fur-ther disclosure of technical information andAPIs); 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 testi-mony concluding the depth of Microsoft’s dis-closure obligation is ‘‘not clear.’’ E.g., Rich-ards ¶ 90, id. at 1099-1100.


leasing its APIs to ISVs in a timely man-ner.

In sum, the district court’s findings arefully adequate to support its decision withrespect to disclosure. They are compre-hensive and sufficiently detailed to providea clear understanding of the factual basisfor the court’s decision. See Folger CoffeeCo. v. M/V Olivebank, 201 F.3d 632, 635(5th Cir.2000); see also 9A CHARLES ALANWRIGHT & ARTHUR R. MILLER, FEDERALPRACTICE AND PROCEDURE § 2571 (2ded.1995). We do not find persuasive Mas-sachusetts’ arguments that the districtcourt overstated or misapprehended thesignificance of the disclosure required bythe decree. In light of the forward-look-ing nature of the API disclosure provision,the court reasonably balanced its goal ofenhanced interoperability with the need toavoid requiring overly broad disclosure,which it determined could have adverseeconomic and technological effects, includ-ing the cloning of Microsoft’s software.Moreover, we cannot overlook thethreat — as documented in the districtcourt’s findings of fact in the liabilityphase — posed by Netscape and Java,which relied upon Microsoft’s then morelimited disclosure of APIs. Microsoftmanaged to squelch those threats, at leastfor a time, but that does not diminish thecompetitive significance of the disclosureof Microsoft’s APIs, a disclosure enhancedby the decree.

We therefore hold the district court didnot abuse its discretion in fashioning theremedial provision concerning Microsoft’sdisclosure of APIs.

b. Disclosure of communications pro-tocols

[7] The district court also included inthe decree a provision requiring Microsoftto disclose

massachusetts v. microsoft corp. 1199 · 2018. 1. 12. · massachusetts v. microsoft corp.1201 cite...

Documents