02-5354. United States

In United States v. Microsoft Corp., Civil Action No. 98-1232, pending in the United States District Court for the District of Columbia, the United States hereby publishes: (1) Memorandum of the United States in Support of Entry of Proposed Final Judgment; (2) Response of the United States to Public Comments on the Revised Proposed Final Judgment; (3) Stipulation and Second Revised Proposed Final Judgment; and (4) United States' Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment.

The United States is concurrently publishing in the Federal Register a complete list of the names of all individuals or entities submitting public comments; the number of pages of each comment; a unique tracking number assigned to each comment so that each comment may be located on the Department of Justice's website; and an index to the comments organized by six categories based primarily on the level of detail of the comment.

In addition to the publication in the Federal Register of the materials published herein, electronic copies of all comments are available on the Department of Justice's website at www.usdoj.gov/​atr/​cases/​ms-comments.htm. Interested persons may also request a copy of the one or more CD-ROMs containing the full text of the comments by contacting the Department of Justice in Washington, DC at Antitrust Documents Group, 325 7th Street NW., Ste. 215 North, Washington, DC 20530, Telephone: [phone], Fax: [phone]. The United States will provide free of charge one copy of this CD-ROM or set of CD-ROMs to each individual person and five copies to each library or other institution that requests it. The United States will provide, at cost, additional copies above these limits to individuals or institutions upon request. The United States has filed the comments on CD-ROM with the Clerk of the United States District Court for the District of Columbia.

Memorandum in Support of Entry of Proposed Final Judgment

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant; Memorandum of the United States in Support of Entry of the Proposed Final Judgment.

Next Court Deadline: March 6, 2002; Tunney Act Hearing.

Charles A. James,

Assistant Attorney General.

Deborah P. Majoras,

Deputy Assistant Attorney General.

Phillip R. Malone,

Renata B. Hesse,

David Blake-Thomas,

Paula L. Blizzard,

Kenneth W. Gaul,

Adam D. Hirsh,

Jacqueline S. Kelley,

Steven J. Mintz,

Barbara Nelson,

David Seidman,

David P. Wales,

Attorneys.

U.S. Department of Justice, Antitrust Division, 601 D Street NW., Suite 1200, Washington, DC 20530, [phone].

Philip S. Beck,

Special Trial Counsel.

February 27, 2002.

Table of Contents

Table of Contents

Table of Authorities

Background

Discussion

I. The Tunney Act Governs the Court's Disposition of the Revised Proposed Final Judgment

II. The United States Has Complied With All Tunney Act Procedural Prerequisites to the Court's Public Interest Determination

A. Summary Of Compliance

B. The United States Fully Complied With All Tunney Act Requirements Regarding The CIS

1. “The Nature And Purpose Of The Proceeding”

2. “A Description Of The Practices Or Events Giving Rise To The Alleged Violation Of The Antitrust Laws”

3. “An Explanation Of The Proposal For A Consent Judgment, Including An Explanation Of Any Unusual Circumstances Giving Rise To Such Proposal Or Any Provision Contained Therein, Relief To Be Obtained Thereby, And The Anticipated Effects On Competition Of Such Relief”

4. “The Remedies Available To Potential Private Plaintiffs Damaged By The Alleged Violation In The Event That Such Proposal For The Consent Judgment Is Entered In Such Proceeding”

5. “A Description Of The Procedures Available For Modification Of Such Proposal”

6. “A Description And Evaluation Of Alternatives To Such Proposal Actually Considered By The United States”

7. Including Information Not Required By The Tunney Act Cannot Result In A Noncompliant CIS

C. The United States Fully Complied With All Tunney Act Requirements Regarding Determinative Documents

D. The United States Fully Complied With All Tunney Act Requirements Regarding Publication of Summaries In Newspapers

E. The United States Has Fully Complied With The Tunney Act Requirement That It Respond To Public Comments

F. The United States Will Fully Comply With the Tunney Act Requirement That It Publish the Comments and Response

G. The Second Revised Proposed Final Judgment Needs No Separate Round Of Public Comment And Response

III. The Court Must Enter the Proposed Decree if It Is Within the Reaches of the Public Interest

A. Whether The Proposed Decree Is Within The Reaches Of The Public Interest Is Determined By The Test Of Microsoft I

B. The Court's Task In Entering A Consent Decree Differs From Adjudicating A Remedy

IV. Entry of the Revised Proposed Final Judgment is in the Public Interest

A. The Revised Proposed Final Judgment Satisfies The Goals Of An Antitrust Remedy And Properly Addresses All Bases Of Liability Affirmed By The Court Of Appeals

a. Stops The Unlawful Conduct

b. Prevents Recurrence Of Unlawful Conduct

c. Restores Competitive Conditions To The Market

B. The Revised Proposed Final Judgment Compares Favorably To The Initial Final Judgment

1. The Revised Proposed Final Judgment Relies On Conduct Restrictions, Rather Than Structural Relief

2. Remedying Tying Is No Longer An Objective

3. The New Conduct Restrictions Compare Favorably To Those In The Initial Final Judgment

a. Substantive Provisions Included In Both The Initial Final Judgment And The Revised Proposed Final Judgment

b. The RPFJ Contains Provisions Not Included In The Initial Final Judgment

C. The Revised Proposed Final Judgment Creates Competitive Conditions

V. The Court Should Make its Public Interest Determination and Enter the Decree as Expeditiously as Possible

A. The Court Should Not Hold An Evidentiary Hearing

B. The Court Should Not Delay Entry Of The Decree Pending The Remedies Hearing In New York v. Microsoft

1. Linking This Case To The Remedies Hearing In New York Would Be Bad Law And Bad Policy

2. The Claimed Benefits Of Linkage Are Illusory

Conclusion

Appendix A: Comparison of Court of Appeals' Findings on Liability to Provisions of the Revised Proposed Final Judgment

Appendix B: United States v. Microsoft Corp.—Newspaper Notice

Appendix C: Declaration of David S. Sibley

Table of Authorities

Prior Decisions in This Case

Microsoft Corp. v. United States, 122 S. Ct. 350 (2001) (Denying Certiorari)

Microsoft Corp. v. United States, 530 U.S. 1301 (2000) (Declining to Accept Appeal)

United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001) (en banc) (per curiam) (Appellate Decision)

United States v. Microsoft Corp., 2001 WL 931170 (D.C. Cir. Aug. 17, 2001) (en banc) (per curiam) (Denying Stay of Mandate)

United States v. Microsoft Corp., 97 F. Supp. 2d 59 (D.D.C. 2000) (Initial Final Judgment)

United States v. Microsoft Corp., 87 F. Supp. 2d 30 (D.D.C. 2000) (Conclusions of Law)

United States v. Microsoft Corp., 84 F. Supp. 2d 9 (D.D.C. 1999) (Findings of Fact)

Cases

Adams v. Bell, 711 F.2d 161 (D.C. Cir. 1983)

American Can Co. v. Mansukhani, 814 F.2d 421 (7th Cir. 1987)

American Water Works Ass'n v. EPA, 40 F.3d 1266, 1274 (D.C. Cir. 1974)

Andrx Pharms., Inc. v. Biovail Corp. Int'l, 256 F.3d 799 (D.C. Cir. 2001), petition for certiorari filed, 70 U.S.L.W. 3465 (Jan. 11, 2002), (No. 01-1050)

Brunswick Corp. v. Pueblo Bowl-O-Mat, Inc., 429 U.S. 477 (1977)

Cascade Natural Gas Corp. v. El Paso Natural Gas Co., 386 U.S. 129 (1967)

Commissioner v. Lundy, 516 U.S. 235 (1996)

Fifth Walnut, Inc. v. Loew's Inc., 176 F.2d 587 (2d Cir. 1949)

Ford Motor Co. v. United States, 405 U.S. 562 (1972)

Gustafson v. Alloyd Co., 513 U.S. 561 (1995)

Hartford-Empire Co. v. United States, 323 U.S. 386 (1945)

Hyperlaw, Inc. v. United States, 1998 WL 388807, 159 F.3d 636 (D.C. Cir. 1998) (unpublished table decision)

In re IBM Corp., 687 F.2d 591 (2d Cir. 1982)

International Salt Co. v. United States, 332 U.S. 392 (1947)

Janus Films, Inc. v. Miller, 801 F.2d 578 (2d Cir. 1986)

Local No. 93, International Association of Firefighters v. City of Cleveland, 478 U.S. 501 (1986)

Maryland v. United States, 460 U.S. 1001 (1983)

Massachusetts School of Law at Andover, Inc. v. United States, 118 F.3d 776 (D.C. Cir. 1997)

Parklane Hosiery Co. v. Shore, 439 U.S. 322 (1979)

Pennsylvania Department of Corrections v. Yeskey, 524 U.S. 206 (1998)

Rufo v. Inmates of Suffolk County Jail, 502 U.S. 367 (1992)

Sorenson v. Secretary of Treasury, 475 U.S. 851, 860 (1986)

South Dakota v. Yankton Sioux Tribe, 522 U.S. 329 (1998)

Sullivan v. Stroop, 496 U.S. 478 (1990)

United States v. ATT, 552 F. Supp. 131 (D.D.C. 1982), aff'd mem. sub. nom. Maryland v. United States, 460 U.S. 1001 (1983)

United States v. Alex. Brown Sons, 963 F. Supp. 235 (S.D.N.Y. 1997), aff'd sub nom. United States v. Bleznak, 153 F.3d 16 (2d Cir. 1998)

United States v. Alex. Brown Sons, 169 F.R.D. 532 (S.D.N.Y. 1996), aff'd sub nom. United States v. Bleznak, 153 F.3d 16 (2d Cir. 1998)

United States v. Armour Co., 402 U.S. 673 (1971)

United States v. Automatic Data Processing, Inc., 1996-1 Trade Cas. (CCH) ¶ 71,361 (D.D.C. 1996)

United States v. Bechtel Corp., 648 F.2d 660 (9th Cir. 1981)

United States v. Blackstone Capital Partners II Merchant Banking Fund, 1999-1 Trade Cas. (CCH) ¶ 72,484 (D.D.C. 1999)

United States v. Borden Corp., 347 U.S. 514 (1954)

United States v. Central Contracting Co., 537 F. Supp. 571 (E.D. Va. 1982)

United States v. City of Miami, 614 F.2d 1322 (5th Cir. 1980)

United States v. E.I. du Pont de Nemours Co., 366 U.S. 316 (1961)

United States v. Enova Corp., 107 F. Supp. 2d 10 (D.D.C. 2000)

United States v. Figgie International Inc., 1997-1 Trade Cas. (CCH) ¶ 71,766 (D.D.C. 1997)

United States v. Foodmaker, Inc., 1996-2 Trade Cas. (CCH) ¶ 71,555 (D.D.C. 1996)

United States v. Gillette Co., 406 F. Supp. 713, 716 (D. Mass. 1975)

United States v. Grinnell Corp., 384 U.S. 563

United States v. Input/Output, Inc., 1999-1 Trade Cas. (CCH) ¶ 72,528 (D.D.C. 1999)

United States v. Mahle GmbH, 1997-2 Trade Cas. (CCH) ¶ 71,868 (D.D.C. 1997)

United States v. Microsoft Corp., 56 F.3d 1448 (D.C. Cir. 1995)

United States v. National Lead Co., 332 U.S. 319 (1947)

United States v. Oregon State Medical Society, 343 U.S. 326 (1952)

United States v. Paramount Pictures, Inc., 334 U.S. 131 (1948)

United States v. RCA, 46 F. Supp. 654 (D. Del. 1942), appeal dismissed, 318 U.S. 796 (1943)

United States v. Swift Co., 286 U.S. 106 (1932)

United States v. Loewen Group Inc., 1998-1 Trade Cas. (CCH) ¶ 72,151 (D.D.C. 1998)

United States v. Titan Wheel International, Inc., 1996-1 Trade Cas. (CCH) ¶ 71,406 (D.D.C. 1996)

United States v. Trump, 1988-1 Trade Cas. (CCH) ¶ 67,968 (D.D.C. 1988)

United States v. United Artists Theatre Circuit, Inc., 1971 Trade Cas. (CCH) ¶ 73,751 (E.D.N.Y. 1971)

United States v. United Shoe Machinery Corp., 391 U.S. 244

United States v. Western Elec. Co., 900 F.2d 283 (D.C. Cir. 1990)

United States v. Western Elec. Co., 993 F.2d 1572 (D.C. Cir. 1993)

Utah Public Service Commission v. El Paso Natural Gas Co., 395 U.S. 464 (1969)

Statutes and Rules

Sherman Act, 15 U.S.C. § 1

Sherman Act, 15 U.S.C. § 2

Clayton Act, § 5(a), 15 U.S.C. § 16(a)

Clayton Act, ch. 323, § 5, 38 Stat. 730, 731 (1914)

Tunney Act (Antitrust Procedures and Penalties Act, § 2), 15 U.S.C. § 16(b)-(h)

15 U.S.C. § 16(b)

15 U.S.C. § 16(c)

15 U.S.C. § 16(d)

15 U.S.C. § 16(e)

15 U.S.C. § 16(f)

15 U.S.C. § 12(a)

15 U.S.C. § 18a(g)

15 U.S.C. § 21(l)

Expediting Act, 15 U.S.C. § 29(b)

28 U.S.C. § 455(a)

Fed. R. Civ. P. 41(a)(1)(ii)

Legislative Materials

119 Cong. Rec. 3452 (1973)

119 Cong. Rec. 24,600 (1973)

119 Cong. Rec. 24,604 (1973)

The Antitrust Procedures Penalties Act: Hearings on S. 782 S. 1088 Before the Subcomm. on Antitrust Monopoly of the Senate Committee on the Judiciary, 93d Cong. (1973)

Consent Decree Bills: Hearings on H.R. 9203, H.R. 9947, and S. 782 Before the Subcomm. on Monopolies Commercial Law of the House Comm. on the Judiciary, 93rd Cong. (1973)

H.R. Rep. No. 93-1463 (1974), reprinted in 1974 U.S.C.C.A.N. 6535

S. Rep. No. 93-298 (1973)

Miscellaneous

47 FR 21,214 (1982)

59 FR 59,426 (1994)

66 FR 59,452 (2001)

3 Phillip E. Areeda Herbert Hovenkamp, Antitrust Law (rev. ed. 1996)

Maimon Schwarzschild, Public Law by Private Bargain: Title VII Consent Decrees and the Fairness of Negotiated Institutional Reform, 1984 Duke L.J. 887, 903 (1984)

Note, The Scope of Judicial Review of Consent Decrees under the Antitrust Procedures and Penalties Act of 1974, 82 Mich. L. Rev. 153 (1974)

Webster's Third International Dictionary (1981)

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant; Memorandum of the United States in Support of Entry of the Proposed Final Judgment.

Next Court Deadline: March 6, 2002, Tunney Act Hearing.

The proposed final judgment, as revised and modified, represents the culmination of six years of investigation, litigation, appeals, and negotiation. It is a comprehensive remedy that puts into place meaningful, effective, and enforceable restrictions on Microsoft and, critically, comports withboth the legal standards for relief in an antitrust case and the decision by the Court of Appeals in this case. Just as important, it provides relief effective now. Failure to enter the proposed final judgment would mean that Microsoft's anticompetitive practices likely would continue unabated for several more years, an eternity in this ever-changing market. Accordingly, in the United States' best judgment, entry of the proposed final judgment is in the public interest.

Background

1. On May 18, 1998, the United States filed a civil complaint alleging that Microsoft had engaged in anticompetitive conduct in violation of Sections 1 and 2 of the Sherman Act, 15 U.S.C. 1, 2. At Microsoft's request, the case was consolidated with a similar action brought by twenty^[1] states and the District of Columbia.^[2] The United States and the States jointly presented the case in a 78-day bench trial that began on October 19, 1998, and ended on June 24, 1999. The court heard testimony from 26 witnesses and admitted depositions of 79 other witnesses and 2733 exhibits. On November 5, 1999, the court entered 412 findings of fact. United States v. Microsoft Corp., 84 F. Supp. 2d 9 (D.D.C. 1999) (“Findings of Fact”). On April 3, 2000, after the parties attempted unsuccessfully to settle the suit through months-long mediation before Judge Richard Posner,^[3] the district court entered its conclusions of law. 87 F. Supp. 2d 30 (D.D.C. 2000) (“Conclusions of Law”). On June 7, 2000, after further proceedings on remedy, the district court entered its final judgment. 97 F. Supp. 2d 59 (D.D.C. 2000) (“Initial Final Judgment” (IFJ)).

Plaintiffs never contended that Microsoft unlawfully obtained its monopoly in Intel-compatible personal computer (PC) operating systems. Plaintiffs alleged, and the district court ruled, that Microsoft successfully had engaged in anticompetitive acts to protect and maintain that monopoly, in violation of Section 2 of the Sherman Act. Conclusions of Law at 37-44. The district court also ruled that Microsoft had attempted to monopolize the Internet Web browser market, in violation of Section 2, and had tied its Web browser, Internet Explorer (IE), to its Windows operating system, in violation of Section 1. Id. at 45-51. The district court rejected plaintiffs' claim that Microsoft's exclusive dealing contracts violated Section 1 of the Sherman Act. Id. at 51-54. To remedy the violations, the court ordered Microsoft to break up into separate operating system and applications businesses. Initial Final Judgment, 97 F. Supp. 2d at 64-65. The Initial Final Judgment also ordered transitional conduct restrictions until the structural relief became effective. Id. at 66-69.

Microsoft filed notices of appeal,^[4] and the Court of Appeals, sua sponte, ordered that any proceedings before it be heard en banc. Order, No. 00-5212 (D.C. Cir., June 13, 2000). The district court certified the case for direct appeal to the Supreme Court pursuant to the Expediting Act of 1903, as amended, 15 U.S.C. 29(b), and stayed its judgment pending completion of the appellate process. Order (June 20, 2000). The Supreme Court declined to accept the appeal and remanded the case to the Court of Appeals. Microsoft Corp. v. United States, 530 U.S. 1301 (2000).

2. After extensive briefing and two days of oral argument, the en banc Court of Appeals issued a unanimous and comprehensive decision affirming in part, reversing in part, and remanding in part for proceedings before a different district judge. United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001) (en banc) (per curiam) (“Microsoft”).

a. The Court of Appeals affirmed the district court's ruling that Microsoft maintained its operating system monopoly, in violation of Section 2 of the Sherman Act, by engaging in specific acts that impeded the emergence of two nascent “middleware” threats to that monopoly. Id. at 50-80.^[5] “Middleware” is platform software that runs on top of an operating system but simultaneously exposes its own application programming interfaces (APIs) so that applications can run on the middleware itself. Id. at 53; Findings of Fact,¶ 28. An application written to rely exclusively on a middleware program's APIs could run on all operating systems on which that middleware runs (i.e., would be “cross-platform”). The Court of Appeals found that middleware posed a potential threat to Microsoft's operating system monopoly because if enough applications developers (known as independent software vendors (ISVs)) wrote enough applications for widely used middleware, computer users no longer would be reluctant to choose a non-Windows operating system for fear that it would run an insufficient array of applications. Microsoft, 253 F.3d at 53. Over time, this widely used middleware might have the potential to erode the “applications barrier to entry” that protected Microsoft's Windows monopoly.

Microsoft's anticompetitive acts centered on two particular middleware threats: Netscape's Web browser (Navigator), and Sun Microsystem's Java technologies. Microsoft set out to ensure that its own Web browser, IE, gained dominant usage so that ISVs would continue to focus their efforts on the Windows platform rather than the Navigator platform. Microsoft took steps to constrict Netscape's access to the distribution channels that led most efficiently to browser usage: pre-installation by computer manufacturers (known as original equipment manufacturers (OEMs)), distribution by Internet access providers (IAPs), and the ISVs themselves. Through restrictions placed in its Windows licenses to OEMs, exclusive deals with IAPs and ISVs, and a combination of inducements to—and threats of retaliation against—other third-parties, Microsoft sought to impede the emergence of middleware as a potential threat to its operating system monopoly. Id. at 58-74.

Java technologies posed a middleware threat to Microsoft by enabling developers to write programs that could be ported to different operating systems with relative ease. In May 1995, Netscape announced that it would include a Sun-compliant Windows Java Virtual Machine (JVM), a key component of Java technologies, with every copy of Navigator, thereby creating the possibility that Sun's Java implementation would achieve the necessary ubiquity on Windows to pose a threat to the applications barrier to entry. Id. at 74. Thus, by limiting the usage of Navigator, Microsoft simultaneously would limit the distribution of Java. Microsoft, however, took additional steps directed specifically to interfere with the development, distribution, and use of cross-platform Java. Those steps included: (1) pressuring third parties not to support cross-platform Java (id. at 75); (2) seeking to extinguish the Java threat through technological means that maximized the difficulty with which applications written in Java could be ported from Windows to other platforms, and vice versa (id. at 74-75); and (3) other anticompetitive steps todiscourage developers from creating Java applications compatible with non-Microsoft JVMs (id. at 75-78).

In affirming liability for monopoly maintenance, however, the Court of Appeals upheld 12 of the 20 district court findings that particular acts constituted bases for violations of Section 2. See id. at 59-78. In particular, the court rejected the findings that Microsoft had violated Section 2 by prohibiting OEMs from “automatically launching a substitute user interface upon completion of the boot process” (id. at 63); overriding the user's choice of browser in certain circumstances (id. at 67); giving away its Internet Explorer browser to IAPs and ISVs (id. at 67-68, 71-72); offering IAPs a bounty for each customer the IAP signs up for service using the IE browser (id. at 67-68); developing and giving away the Internet Explorer Access Kit (IEAK) (id. at 68); entering into exclusive agreements with Internet Content Providers (ICPs) (id. at 71); and creating a JVM that runs faster on Windows but lacks the cross-platform attributes that Sun's (hence Navigator's) JVM possesses (id. at 74-75). In addition, and importantly, the Court of Appeals expressly rejected the district court's conclusion that, “apart from Microsoft's specific acts, Microsoft was liable under § 2 based upon its general ‘course of conduct.’ ”Id. at 78. The court found that the district court had failed to “point to any series of acts, each of which harms competition only slightly but the cumulative effect of which is significant enough to form an independent basis for liability.”Id.

b. The Court of Appeals also reversed the district court's determination that Microsoft had attempted to monopolize the Web browser market in violation of Section 2. Id. at 80-84. The court found that plaintiffs had failed to define and prove a market for Web browsers, a necessary element of the claim. Id. at 81-82.

c. The Court of Appeals vacated the district court's judgment on the Section 1 tying claim as well, and remanded that claim to the district court for reconsideration under the rule of reason. Id. at 84-97. In so holding, the Court of Appeals held that the market for platform software presented unique issues under tying law. The “nature of the platform software market affirmatively suggests that per se rules might stunt valuable innovation” (1) because “the separate-products test is a poor proxy for net efficiency from newly integrated products; and (2) “because of the pervasively innovative character of platform software markets, tying in such markets may produce efficiencies that courts have not previously encountered and thus the Supreme Court had not factored into the per se rule as originally conceived.”Id. at 92-93. The court directed that on remand, plaintiffs would be limited to proving that the anticompetitive effects from tying outweigh the benefits in the tied product market, not just that those effects outweigh the benefits overall. Id. at 95. In addition, plaintiffs would be “precluded from arguing any theory of harm that depends on a precise definition of browsers or barriers to entry . . . other than what may be implicit in Microsoft's tying arrangement.”Id.

d. In light of its determination that it had “drastically” (id. at 105, 107) altered the district court's conclusions on liability, and its finding that an evidentiary hearing on remedy was necessary prior to the district court's imposting a remedy (id. at 101-103), the Court of Appeals vacated the final judgment and remanded the case to the district court for further proceedings. Id. at 107. The court also offered guidance “to advance the ultimate resolution of this important controversy.”Id. at 105. Though recognizing that, “[a]s a general matter, a district court is afforded broad discretion to enter that relief it calculates will best remedy the conduct it has found to be unlawful,”id., the Court of Appeals directed this Court to “reconsider whether the use of the structural remedy of divestiture is appropriate with respect to Microsoft, which argues that it is a unitary company.”Id.

Critically, the Court of Appeals admonished the district court on remand to bear in mind the role of causation when fashioning relief, directing this Court to “consider whether plaintiffs have established a sufficient causal connection between Microsoft's anticompetitive conduct and its dominant position in the [operating system] market.”Id. at 106. Absent “clear[]” indication of a “significant causal connection between the conduct and creation or maintenance of the market power,” Microsoft's unlawful behavior “should be remedied by ‘an injunction against continuation of that conduct.’ ”Id. at 106 (quoting 3 Phillip E. Areeda Herbert Hovenkamp, Antitrust Law¶ 650a, at 67 (rev. ed. 1996) (“Antitrust Law”)) (emphasis added by Court of Appeals). The court emphasized that it had “found a causal connection between Microsoft's exclusionary conduct and its continuing position in the operating systems market only through inference,”id. at 106-07, but that even the district court “expressly did not adopt the position that Microsoft would have lost its position in the [operating system] market but for its anticompetitive behavior.”Id. at 107 (quoting Findings of Fact,¶ 411) (emphasis added). The court concluded that the remedy should be “tailored to fit the wrong creating the occasion for the remedy.”Id. at 107.

e. Finally, the Court of Appeals concluded that the district judge's contacts with the press violated the Code of Conduct for United States Judges and warranted disqualification under 28 U.S.C. 455(a). Id. at 107-118. The court vacated the remedy on the additional basis that the district judge's misconduct infected the remedial phase. Id. at 117.

3. After the Court of Appeals rejected Microsoft's petition for rehearing, Microsoft filed a petition for a writ of certiorari based on the Court of Appeals' failure to vacate the Findings of Fact and Conclusions of Law—and not just the remedy—in light of the district judge's misconduct. Petition for a Writ of Certiorari, No. 01-236 (Aug. 7, 2001) (“Cert. Petition”). Although Microsoft's petition was limited to the issue of judicial misconduct, it promised a future petition on several issues relating to liability when the case becomes final—after the remand to the district court and another appeal to the D.C. Circuit. Id. at 15. On October 9, 2001, the Supreme Court denied Microsoft's petition. Microsoft Corp. v. United States, 122 S. Ct. 350 (2001).

Meanwhile, on the same day it filed its petition for certiorari, Microsoft moved the Court of Appeals to stay its mandate pending disposition of the— petition by the Supreme Court. The Court of Appeals denied Microsoft's motion, United States v. Microsoft Corp., 2001 WL 931170 (D.C. Cir. Aug. 17, 2001) (en banc) (per curiam), and issued its mandate on August 24, 2001. That same day, a random selection assigned the case to this Court.

4. On September 6, 2001, plaintiffs advised Microsoft that they did not intend to pursue the Section 1 tying claim on remand, and that they did not intend to pursue on remand the restructuring of Microsoft into two separate companies. As explained to the Court in the Joint Status Report filed on September 20, 2001, Plaintiffs' goal was to achieve the expeditious imposition of relief that would effectively remedy Microsoft's illegal conduct. Joint Status Report at 21 (Sept. 20, 2001).

5. On September 28, 2001, this Court ordered the parties to “concentrate all of their resources” on a new round of intense settlement negotiations and probable mediation. Order at 2-3 (Sept. 28, 2001). The Court emphasized the importance of these efforts in light ofthe passage of time—more than six years since plaintiffs” claims arose and more than four years of litigation, id. at 2. The Court expressly directed plaintiffs to “determine which portions of the former judgment remain appropriate in light of the appellate court's ruling and which portions are unsupported following the appellate court's narrowing of liability.” Tr. 9/28/01 at 8. The Court also adopted a fast-track discovery and evidentiary hearing schedule in case the parties failed to settle.^[6]

On November 2, 2001, following five weeks of intensive negotiation and mediation as ordered by the Court, the United States and Microsoft agreed on terms of a proposed final judgment. Stipulation at 1 (Nov. 2, 2001). Further negotiations with several of the plaintiff States resulted in submission on November 6, 2001, by the United States, the Settling States,^[7] and Microsoft of the Revised Proposed Final Judgment (RPFJ). Pursuant to the requirements of Section 2 of the Antitrust Procedures and Penalties Act (“Tunney Act”), 15 U.S.C. 16(b)-(h), the United States filed its Competitive Impact Statement (CIS) on November 15, 2001, and published the RPFJ, CIS, and description of the procedures for submitting public comments on the proposed decree in the Federal Register on November 28, 2001. 66 FR 59,452 (2001). The public comment period closed on January 28, 2002—with more than 30,000 comments submitted—and the United States” response to those comments is being filed concurrently with this Motion and supporting Memorandum. Under the Tunney Act, this Court must now determine whether the RPFJ is in the “public interest.” 15 U.S.C. 16(e).

6. On January 30, 2002, the Court ordered the parties to address “whether, in response to the comments received by the Department of Justice in accordance with 15 U.S.C. 16(b), the United States and Microsoft are considering any modifications of the Proposed Final Judgment.” Order at 1 (Jan. 30, 2002). Responding in a Joint Status Report filed on February 7, 2002, the parties stated that they were considering making modifications and would submit any proposed modifications to the Court on or before February 27, 2002. Joint Status Report at 7 (Feb. 7, 2002). Simultaneously with this Memorandum, the parties have filed a Second Revised Proposed Final Judgment (SRPFJ), which includes modifications to which the United States, Microsoft, and the Settling States have agreed.^[8] This Memorandum is couched in terms of, and generally refers to, the proposed decree before modification (i.e., the RPFJ), addressing the modifications of the SRPFJ only as required. However, the decree the Court should enter is the modified version of the RPFJ—that is, the SRPFJ.

Discussion

I. The Tunney Act Governs the Court's Disposition of the Revised Proposed Final Judgment

By its express terms, the Tunney Act applies to “[a]ny proposal for a consent judgment submitted by the United States for entry in any civil proceeding brought by or on behalf of the United States under the antitrust laws,” 15 U.S.C. 16(b) (emphasis added), without regard to when the United States submits it. Moreover, the Court is required to make its Tunney Act public interest determination “[b]efore entering any consent judgment proposed by the United States under this section.”Id. § 16(e) (emphasis added). The Revised Proposed Final Judgment on its face is a proposal for a consent judgment submitted by the United States for entry in a civil proceeding brought by the United States under the antitrust laws. By the plain and unambiguous statutory language, the Tunney Act applies and governs the Court's consideration of the RPFJ.

The Tunney Act applies even though the parties proposed the RPFJ after trial and after the Court of Appeals affirmed Microsoft's liability for monopoly maintenance. These circumstances^[9] have led some to suggest, see AAI Tunney Act Comments, at 4-9 (MTC # 0030600); ProComp's Comments to the Proposed Final Judgment, at 1-2 (MTC # 0030608) (“ProComp Comments”); Memorandum of Points and Authorities in Support of the California Plaintiffs' Motion to Intervene at 18-21 (Jan. 23, 2002)) (“Cal. Plaintiffs” Br.”)), that the Tunney Act does not apply to some proposals for consent judgments submitted by the United States for entry in a civil proceeding brought by the United States under the antitrust laws, including the RPFJ, because of the stage at which they are proposed. It has been variously suggested that the Act does not apply to proposals that arise after the taking of testimony begins (id. at 10, 18-19 n.9); after litigation to judgment (id. at 11, 18), apparently whether or not that judgment is vacated on appeal; and after litigation through judgment and appeal (id. at 18), again apparently without regard to the result on appeal.

Because, then and now, most consent judgments in government antitrust cases are entered before trial, Congress undoubtedly focused on pre-trial consent judgments when it enacted the Tunney Act. But Congress knew that consent judgments could be proposed at later stages, see pages 15-16 below, and it did not exempt them from the Tunney Act. Even if Congress had failed to foresee later-arising proposals, in the face of an “unambiguous statutory text [such a failure] is irrelevant,”Pennsylvania Department of Corrections v. Yeskey, 524 U.S. 206, 212 (1998), because application of an unambiguous statute “in situations not expressly anticipated by Congress” merely shows the statute's breadth. Id. (citation and internal quotation marks omitted).

The plain meaning of “[a]ny proposal for a consent judgment” is sufficient to support the conclusion that the Tunney Act applies here. But if one wants more support for reading “any” to mean “any,” that support is readily at hand. First, nothing in the language of the Tunney Act suggests that the Act reaches only proposals for consent judgments in government civil antitrust cases that are submitted at some appropriate time.^[10] And the context of the Tunney Act suggests a broad readingof the statute's coverage—at the very least, a reading not limited to consent judgments before testimony is taken.^[11] The term “Tunney Act” refers to Sections 5(b)-(h) of the Clayton Act. Section 5(a), originally enacted in 1914 as Section 5, gives prima facie evidence effect to certain consent decrees, subject to the proviso that the section does not give that effect to “consent judgments or decrees entered before any testimony has been taken.” 15 U.S.C. § 16(a). If Congress in 1914 had understood the words “consent judgments or decrees” to refer only to ones entered before any testimony had been taken, there would have been no need to draw the distinction, and the proviso would have been surplusage.^[12] See South Dakota v. Yankton Sioux Tribe, 522 U.S. 329, 347 (1998) (“the Court avoids interpreting statutes in a way that “renders some words altogether redundant” ’) (quoting Gustafson v. Alloyd Co., 513 U.S. 561, 574 (1995)). Had Congress used the term “consent judgment” in Section 5(b) of the Clayton Act to mean something different than its meaning in Section 5(a), it surely would have said so. See Commissioner v. Lundy, 516 U.S. 235, 250 (1996) (“the normal rule of statutory construction [is] that identical words used in different parts of the same act are intended to have the same meaning”) (quoting Sullivan v. Stroop, 496 U.S. 478, 484 (1990), and Sorenson v. Secretary of Treasury, 475 U.S. 851, 860 (1986) (internal quotation marks omitted)).

Second, Congress clearly was aware that consent judgments could arise relatively late in the course of an antitrust case. Not only were there examples ready at hand involving well-known antitrust cases, see, e.g., Fifth Walnut, Inc. v. Loew's Inc., 176 F.2d 587, 592-93 (2d Cir. 1949) (consent decrees with some defendants entered on remand, after Supreme Court affirmed liability in part and reversed in part in United States v. Paramount Pictures, Inc., 334 U.S. 131 (1948)),^[13] but the legislative history contained prominent references to the possibility. Representative Hutchinson, then the ranking minority member of the House Judiciary Committee and of its Monopolies and Commercial Law subcommittee, inserted into the hearing record a statement plainly recognizing that circumstances arising during prosecution of a case might make settlement seem appropriate.^[14] And Thomas Kauper, then Assistant Attorney General-Antitrust Division, specifically noted in his testimony that “a consent decree . . . may come after trial.” The Antitrust Procedures Penalties Act: Hearings on S. 782 S. 1088 Before the Subcomm. on Antitrust Monopoly of the Senate Committee on the Judiciary, 93d Cong. 117 (1973) (“Senate Hearings”) (testimony of Thomas E. Kauper).

Finally, a reading of the statutory language that precludes its application at this stage would lead to anomalous results. Nothing plausibly explains why Congress would want a court to enter consent judgments in the later stages of government civil antitrust cases without following Tunney Act procedures—publication of the decree and CIS, a public comment period, and so forth. Nor is it plausible that Congress intended, sub silentio, to prohibit courts from entering consent judgments at certain stages of the litigation. Courts have long entered consent judgments reached after the taking of evidence, after determinations of liability, and even after affirmance of liability by the Supreme Court, as the Paramount Pictures history just cited demonstrates. Moreover, the Supreme Court has expressly acknowledged the authority of the Attorney General to settle cases at any stage. See Cascade Natural Gas Corp. v. El Paso Natural Gas Co., 386 U.S. 129, 136 (1967) (Court does “not question the authority of the Attorney General to settle suits after, as well as before, they reach here”).

We do not, of course, suggest that this Court approach its public interest determination in this proceeding as if the RPFJ had been filed simultaneously with the complaint. The trial record, Findings of Fact, Conclusions of Law, and appellate decisions in this case all exist, and the Tunney Act does not require the Court to ignore them. But as we discuss below, see pages 39-42, the history of this case does not change the nature of the Court's public interest determination; it changes only the circumstances in and to which that standard is applied.

II. The United States Has Complied With All Tunney Act Procedural Prerequisites to the Court's Public Interest Determination

With the filing today of the public comments and the government's responses, the United States has completed all of the steps required of it before the Court enters a proposed consent judgment under the Tunney Act, 15 U.S.C. 16(b)-(d), except for the publication of those comments and responses. We expect to publish as required, in the manner described below in Section II.F, and we will promptlynotify the Court when we have done so. The United States will then have complied completely with the requirements of the Act.^[15]

A. Summary Of Compliance

On November 6, 2001, the United States (together with the Settling States and Microsoft) submitted to the Court the Revised Proposed Final Judgment. The United States filed its Competitive Impact Statement with the Court on November 15, 2001, and published the RPFJ and CIS in the Federal Register on November 28, 2001 (66 FR 59,452), as required by 15 U.S.C. 16(b);^[16] see also Order at 2-3 (Nov. 8, 2001) (“Nov. 8 Order”). The CIS included each of the six required recitals, see 15 U.S.C. 16(b)(1)-(6),^[17] as well as other material. Copies of the RPFJ and CIS were made available to the public at the Court's website.^[18] The United States also made them available at the Department of Justice website. Because there were no “materials and documents which the United States considered determinative in formulating” the proposed judgment (“determinative documents”), 15 U.S.C. 16(b), the United States was not required to make copies of such documents available at the Court.^[19] The United States furnished copies of the CIS to those who requested them.^[20]

As required by 15 U.S.C. 16(c) and the Court's Order of November 8, 2001, the United States published in the Washington Post (November 16-22, 2001), the San Jose Mercury News (November 17-23, 2001), and the New York Times (November 17-23, 2001) a notice complying with the requirements of that statutory provision and the Order.^[21]

On November 28, 2001, the United States published procedures for submitting comments on the RPFJ. 66 FR 59,452 (2001). The 60-day public comment period (see 15 U.S.C. 16(d)), began the same day and ended on January 28, 2002.^[22] During that period, the United States received over 30,000 public comments. See Joint Status Report 3-4 (Feb. 7, 2002). The United States is filing those comments and its response to them, see 15 U.S.C. 16(b), (d),^[23] simultaneously with the filing of this Memorandum. The United States believes that it will have completed all Tunney Act procedural requirements when it publishes the public comments and its response to these comments in the manner described below in Section II.F. The United States will notify the Court when publication occurs.

B. The United States Fully Complied With All Tunney Act Requirements Regarding the CIS

The CIS filed by the United States in this case fully satisfies all Tunney Act requirements. In enacting the Tunney Act, Congress sought, among other things, “to encourage additional comment and response by providing more adequate notice [concerning a proposed consent judgment] to the public,” S. Rep. No. 93-298, at 5 (1973) (“Senate Report”); H.R. Rep. No. 93-1463, at 7 (1974) (“House Report”), reprinted in 1974 U.S.C.C.A.N. 6535, 6538; the CIS is the primary means by which Congress sought to do so. Introducing his bill, Senator Tunney explained that the six items of information required in a CIS would “explain to the public[,] particularly those members of the public with a direct interest in the proceeding, the basic data about the decree to enable such persons to understand what is happening and make informed comments o[r] objections to the proposed decree during the 60-day period.” 119 Cong. Rec. 3452 (1973) (remarks of Sen. Tunney) (“Tunney Remarks”).^[24] The purpose could be achieved, Senator Tunney suggested, without adding greatly to the government's workload because the six prescribed items “do not require considerably more information than the complaint, answer and consent decree themselves would provide and, therefore, would not be burdensome requirements.” Senate Hearings at 3 (statement of Sen. Tunney) (“Tunney Statement”).

The CIS in this case succeeded beyond all expectations in achieving thecongressional goal.^[25] As noted above, over 30,000 public comments were submitted, a number apparently beyond the wildest imaginings of the Tunney Act's sponsor in 1973, see House Hearings at 45 (testimony of Sen. Tunney) (predicting that “in the typical case, you will have [no public comments], but perhaps you will have 10 to 15 in a highly controversial case”). Indeed, the number of comments received on the RPFJ exceed the number received in the ATT case by more than an order of magnitude, see United States v. ATT, 552 F. Supp. 131, 135 (D.D.C. 1982) (“over six hundred comments”), aff'd mem. sub. nom. Maryland v. United States, 460 U.S. 1001 (1983); 47 FR 21,214, 21,214-24 (1982) (listing name and address of each commentor on proposed ATT decree, with length of comment in pages).^[26]

Although many of the comments received are unlikely to contribute new insights concerning the RPFJ,^[27] approximately 2,900—a number nearly five times the total number of comments in ATT—contain “a degree of detailed substance concerning the RPFJ.” Joint Status Report at 4 (Feb. 7, 2002). Although the Court has only just received the full set of comments, the United States provided the Court with an advance installment of 47 of the most extensive comments on February 14, 2002. The Court therefore is aware already of substantial evidence that the public did not lack the raw material for formulating “informed comments o[r] objections to the proposed decree” (Tunney Remarks, 119 Cong. Rec. at 3452).

Having established that the CIS in this case richly fulfilled the statutory purpose, we turn to whether its content met the formal requirements of the statute. In addressing that question, we proceed through the six recitals the statute specifies, and then address additional aspects of CIS content. As the statute requires, the CIS “recite[s]':

1. “The Nature and Purpose of the Proceeding”

Section I of the CIS, CIS at 2, describes the nature and purpose of the proceeding, as the statute requires. 15 U.S.C. 16(b)(1). We are aware of no suggestion that this description is inadequate or otherwise fails to satisfy the statutory requirement.

2. “A Description of The Practices Or Events Giving Rise to the Alleged Violation Of The Antitrust Laws”

Section III of the CIS, CIS at 5-17, describes the practices giving rise to Microsoft's antitrust violation.^[28] We are aware of no suggestion that this recital is inadequate or otherwise fails to satisfy the statutory requirement.

3. “An Explanation of the Proposal for a Consent Judgment, Including An Explanation of Any Unusual Circumstances Giving Rise to Such Proposal or Any Provision Contained Therein, Relief To Be Obtained Thereby, and the Anticipated Effects on Competition of Such Relief”

Section IV of the CIS, CIS 17-60, the bulk of the document, explains the proposed consent judgment, provision by provision, in considerable detail. Subsection B, CIS 24-60, links the underlying theory of violation in the case (“[c]ompetition was injured in this case principally because Microsoft's illegal conduct maintained the applications barrier to entry . . . by thwarting the success of middleware that would have assisted competing operating systems”), id. at 24, to the primary remedial approach adopted (“the key to the proper remedy in this case is to end Microsoft's restrictions on potentially threatening middleware [and] prevent it from hampering similar nascent threats in the future” and thereby “restore the competitive conditions created by similar middleware threats”). Id. The remainder of the subsection explains how particular provisions contribute to this remedial strategy, and therefore to the anticipated competitive effect of the proposed judgment. See, e.g., id. at 33 (explaining role of required interface disclosures in overall remedial strategy and remedial impact).

Although, as commentors point out, e.g., Comments of the Progress Freedom Foundation on the Revised Proposed Final Judgment and the Competitive Impact Statement, 16-17 (MTC # 0030606) (“PFF Comment”), the 40-plus-page analysis offered in the CIS is less elaborated and detailed than might be required by Executive Order for a cost/benefit analysis of a major executive branch regulatory analysis, that is irrelevant because the analysis plainly satisfies the requirements of the Tunney Act. The CIS meets the statutory requirement and provides “the basic data about the decree to enable [members of the public] to understand what is happening and make informed comments o[r] objections to the proposed decree.” Tunney Remarks, 119 Cong. Rec. at 3452.^[29] There has been no sign that any alleged inadequacy handicapped potential commentors. PFF, for example, was able to reach its conclusion—with which we disagree—that the RPFJ is not an adequate remedy despite these alleged inadequacies of the CIS. The Court will have ample information to conclude that entry of the decree is in the public interest.^[30]

4. “The Remedies Available to Potential Private Plaintiffs Damaged by the Alleged Violation in the Event That Such Proposal for the Consent Judgment Is Entered in Such Proceeding”

Section 6 of the CIS, CIS at 63, identifies the remedies available to private plaintiffs, with concise reference to damage actions under the federal antitrust laws, which may provide some private plaintiffs with a remedy.^[31] The proposed judgment does not itself provide any remedy that can be invokedby potential private plaintiffs who may have been damaged by violations alleged in this case, and so the CIS does not refer to any such remedy. The description complies with the terms of the statute, and there is no ground for requiring more.

It has been suggested that the CIS should go into more details with respect to private remedies and, specifically,^[32] that it should address any impact the RPFJ might have on the collateral estoppel effect of the findings of fact and the conclusions of law in this case, and on the prima facie evidence effect of a final judgment under the Clayton Act, see 15 U.S.C. 16(a). But nothing in the language of the Tunney Act requires the United States to offer, in the CIS or elsewhere, its views about legal questions that may arise in subsequent litigation.^[33] The Tunney Act does not direct the United States to discuss the effect of the proposed judgment on private litigation; rather, it requires only a recital of the remedies available to private plaintiffs. The evidentiary or collateral estoppel effect of determinations this Court makes is a question to be addressed by the courts in which future litigants might seek to use those determinations. See ATT, 552 F. Supp. at 211 (declining to “enter any specific decision or finding regarding” applicability of prima facie evidence aspect of 16(a) because “the ultimate decision with respect to this issue must rest with the court in which such litigation may be brought”); Parklane Hosiery Co. v. Shore, 439 U.S. 322, 331 (1979) (granting trial courts broad discretion to determine whether offensive collateral estoppel should be applied in matters before them). It is not a question for this Court or for the United States to determine. The United States does not seek to inject itself into private litigation by making public statements in other forums, and its views with respect to matters contested in such cases carry no determinative legal effect.

5. “A Description of the Procedures Available for Modification of Such Proposal”

Section VII of the CIS, CIS at 63-65, notes that the United States may withdraw its consent to the RPFJ prior to its entry and informs the public of procedures for submitting written comments regarding the RPFJ. That describes the procedure available for modifying the proposal prior to entry of the judgment, as required. The section then describes, briefly, the procedure for modifying the judgment after entry. We are aware of no suggestion that this description is inadequate or otherwise fails to satisfy the statutory requirement.

6. “A Description and Evaluation of Alternatives To Such Proposal Actually Considered by the United States”

Section V of the CIS, CIS at 60-63, describes alternatives the United States considered and rejected,^[34] and indicates the reasons why they were rejected. It explains why we viewed the RPFJ as a superior alternative to continued litigation. See id. at 60-61. It describes why, following remand, the United States decided not to continue to seek a break-up of Microsoft, a remedy that would have required further litigation and delay and would likely not have been achieved. See id. at 61; see also pages 63-65 below. The CIS explains the reasons for differences between the interim conduct provisions of the Initial Final Judgment (vacated by the Court of Appeals) and the provisions of the RPFJ. See id. at 61-62; see also pages 66-70 below. And it lists a number of other remedy proposals, the criteria used to evaluate them, and the results of that evaluation. Id. at 63.

To be sure, the description and the evaluations of alternatives presented are brief.^[35] But they are consistent with Senator Tunney's purpose of providing “basic data about the decree to enable [members of the public with a direct interest] to understand what is happening and make informed comments o[r] objections to the proposed decree,” Tunney Remarks, 119 Cong. Rec. at 3452, and with his understanding that the statutory requirements would not be burdensome. See Tunney Statement, Senate Hearings at 3. Indeed, the sheer volume and comprehensiveness of the comments received suggest that the level of detail was more than adequate to stimulate informed public comment about the proposed remedy and about the relative merits of alternative remedies.

A commentor contends, in separate litigation, that the CIS is inadequate because it “failed to explain adequately how alternative remedies (those not being pursued in the [R]PFJ) would have affected competition in the marketplace.”AAI, Complaint ¶ 19. See also PFF Comment, at 15 (criticizing CIS for failing to evaluate likely impacts on competition of alternative remedies). The Tunney Act, however, does not require any explanation of how alternative remedies would have affected competition in the marketplace. That is no accident. The version of Senator Tunney's bill reported out of the Senate Committee would indeed have required that CIS recitations include “the anticipated effects on competition of such alternatives.” Senate Report at 9 (proposed 15 U.S.C. 16(b)(6)). But on the Senate floor, Senator Hruska offered an amendment to strike that requirement, stating:

There is no reason . . . to require the staff of the Antitrust Division . . . to make a public prediction as to the competitive effects of various alternatives which it has considered. It is sufficient if the various alternatives are disclosed to the court and to the public.

119 Cong. Rec. 24,604 (1973).^[36] Senator Tunney agreed with the amendment's “basic intent,” and the Senate adopted it by voice vote. Id.

7. Including Information Not Required by the Tunney Act Cannot Result in a Noncompliant CIS

Several commentors contend that the CIS is inadequate because it contains material beyond that required by the statute and the additional material is incorrect or insufficient. That some commentors wish that the CIS contained more or different material, even though not required by statute, provides no basis for concluding that the CIS is deficient. Thus, Section VIII, CIS at 65-68, provides a brief discussion of the standards courts apply in determining whether entry of a proposed consent judgment is in the public interest.Intended to provide general information to the public, cf. pages 35-46 below (more substantial discussion of legal standard intended for the Court), Section VIII has been the target of several commentors. E.g., Comments of Software Information Industry Association on Proposed Final Judgment, at 11 (MTC # 0030614) (“SIIA Comments”) (contending that legal standard commentor finds in CIS is “simply the wrong standard of review for the remedy in this case”). The Court will determine the standard of review it will apply and, as discussed below, see pages 35-46, the appropriate standard of review corresponds to the standard expressed in the CIS. But because there is no requirement that the CIS discuss the standard of review at all, any alleged shortcomings of that discussion in the CIS are no basis for finding that the CIS fails to satisfy the statutory requirements.

Similarly, the CIS contains two sentences explaining that the United States is not filing any determinative documents in this case because there are none within the meaning of the statute. CIS at 68. One commentor has alleged, in a separate lawsuit, that the CIS is deficient because the disclosure in this discussion is inadequate, AAI Complaint ¶ 27, and in particular because that discussion does not include our “definition or interpretation” of the word “determinative,”id.¶ 28. Because the CIS is not required to discuss determinative documents (and the statute does not require the United States to provide an interpretation or definition of the term “determinative”), this allegation provides no basis for concluding that the CIS fails to comply with the statute.

C. The United States Fully Complied With All Tunney Act Requirements Regarding Determinative Documents

The United States did not file any determinative documents with the Court, see 15 U.S.C. 16(b), did not otherwise make determinative documents available to the public, and did not list any determinative documents in the required newspaper notices, see id. § 16(c)(iii), for one simple reason: there are no such documents in this case. Moreover, although not required to do so, we stated as much in the CIS. See CIS at 68.

Commentors have nevertheless, and without any basis, questioned our compliance. One commentor, without further explanation, suggests we failed to comply with the statute because “no documents considered determinative in formulating the RPFJ throughout the negotiation process were disclosed as required by 15 U.S.C. 16(b).” Relpromax Comment, Ex. 11, at 3. As noted above, another, in a separate lawsuit, challenged our failure to provide a definition of “determinative” in the CIS, implying that under the commentor's preferred definition, there were in fact determinative documents. See Memorandum in Support of Motion for Preliminary Injunction and Expedited Hearing at 16-19 (Jan. 31, 2002), AAI.

There are no “determinative” documents in this proceeding. The Court of Appeals addressed the definition of “determinative documents” in a recent Tunney Act case. See Mass. School of Law at Andover, Inc. v. United States, 118 F.3d 776 (D.C. Cir. 1997) (“MSL”). The United States had argued that the statute referred to documents “that individually had a significant impact on the government's formulation of relief—i.e., on its decision to propose or accept a particular settlement.”Id. at 784 (quoting brief of the United States). The court concluded that the statutory language “seems to point toward the government's view . . . and confines § 16(b) at the most to documents that are either ‘smoking guns’ or the exculpatory opposite.”Id. The court added that “[t]he legislative history in fact supports the government's still narrower reading.”Id. In this case, the United States did not consider any document to be a “smoking gun or its exculpatory opposite” with a significant impact on our formulation of our decision regarding the RPFJ, and so there were no determinative documents.^[37]

D. The United States Fully Complied With All Tunney Act Requirements Regarding Publication of Summaries in Newspapers

As noted above, the United States published notices in three newspapers for the periods required by the Tunney Act and this Court's Order of November 8, 2001. The notice (the text of which is attached as Appendix B) contained “a summary of the terms of the proposal for the consent judgment” as required by 16 U.S.C. 16(c)(i), and “a summary of the competitive impact statement” as required by 16 U.S.C. 16(c)(ii).^[38] Although required to do so by neither statute nor Order, the notice also stated where copies of the complaint, the RPFJ, and the CIS could be viewed and obtained and where comments could be sent. Because there were no determinative documents, the notice did not list them. See 15 U.S.C. 16(c)(iii). The United States complied with the newspaper notice requirements of the Tunney Act, and no commentor has suggested otherwise.

E. The United States Has Fully Complied With the Tunney Act Requirement That It Respond to Public Comments

The Tunney Act requires that the United States respond to public comments and file its response with the Court “[a]t the close of the period during which such comments may be received.” 15 U.S.C. 16(d). The statutory language allows the United States “some additional time after the end of [the comment period] to prepare and file responses,”United States v. Bechtel Corp., 648 F.2d 660, 664 (9th Cir. 1981), and this Court allowed 30 days. Nov. 8 Order at 3. The comment period closed on January 28, 2002, and we are filing our responses with the Court, concurrently with this Memorandum, on February 27, 2002, thereby complying with the requirement.

F. The United States Will Fully Comply With the Tunney Act Requirement That It Publish the Comments and Response

In light of the Court's Memorandum and Order of February 22, 2002, denying as non-justiciable at that time the United States' Motion for Leave of Court to Adopt an Alternative Procedure for Comment Publication (“Alternative Procedure Motion”), the United States will pursue two parallel approaches to compliance with the remaining requirement of the Tunney Act, publication of the public comments and our response thereto in the Federal Register. Approach 1 will consist of the steps set forth in our Alternative Procedure Motion and the United States' Supplement to Prior Motion for Leave of Court to Adopt an Alternative Procedure for Comment Publication (“Supplement”), filed February 21, 2002, with one difference in timing. Even with the additional demands of simultaneously pursuing Approach 2, described below, the posting of the full text of the 32,329 public comments described in the Alternative Publication Motion^[39] on the Department of Justice's website will likely be accomplished by March 4, 2002. We estimate that all of the other steps described in our Alternative Procedure Motion and Supplement will be completed by March 15, 2002. In the view of the United States, completion of these steps will constitute full, and certainly no less than substantial,^[40] compliance with the statutory requirement that comments be published in the Federal Register, for the reasons set forth in our Alternative Procedure Motion and Supplement.^[41]

Approach 2, which we will pursue in addition to and simultaneous with Approach 1, consists of publication in the Federal Register of the full text of the public comments. We will begin the process of publication of the comments in their entirety by providing the full text to the Federal Register no later than March 1, 2002; the Federal Register will then commence its process of preparing the text for publication.^[42] We estimate that publication of the full text of the comments in the Federal Register, if ultimately necessary, will occur approximately six weeks after submission to the Federal Register.

G. The Second Revised Proposed Final Judgment Needs No Separate Round of Public Comment and Response

The Tunney Act does not require a new round of publication and comment in light of the SRPFJ. The publication and comment provisions of the Act serve “to enable the district court to make” its public interest determination. Hyperlaw, Inc. v. United States, 1998 WL 388807, at *3, 159 F.3d 636 (D.C. Cir. 1998) (unpublished table decision). Accordingly, a “court should treat notice and comment under the Tunney Act as analogous to agency rulemaking notice and comment.”Id. (quotation marks omitted). Applying that analogy, “there is no need for successive rounds of notice and comment on each revision,” provided the final decree “is a ‘logical outgrowth’ of the proposed decree. . . . Further notice and comment should be required only if it ‘would provide the first opportunity for interested parties to offer comments that could persuade the agency to modify its [proposal].’ ”Id. (quoting American Water Works Ass'n v. EPA, 40 F.3d 1266, 1274 (D.C. Cir. 1974)).

The proposed decree as modified is a logical outgrowth of the RPFJ and so requires no further notice and comment. As explained in the United States' Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment, each of the modifications clarifies decree language in response to public comments on the RPFJ. They thus are in fact a natural outgrowth of the notice and comment process. Taken separately or together, the modifications do not fundamentally change the RPFJ. All contribute to the public interest. The purpose of the notice and comment has thus been well satisfied, and further notice and comment would merely delay the court's public interest determination without sound reason.^[43]

III. The Court Must Enter the Proposed Decree if It Is Within the Reaches of the Public Interest

Courts have long applied a public interest standard in determining whether to enter an antitrust consent decree. See, e.g., United States v. RCA, 46 F. Supp. 654, 655 (D. Del. 1942) (decision to enter a consent decree “involves a determination by the chancellor that it is equitable and in the public interest”), appeal dismissed, 318 U.S. 796 (1943). That standard is now embodied in the Tunney Act, 15 U.S.C. 16(e) (“the court shall determine that the entry of such judgment is in the public interest” before entering it); see ATT, 552 F. Supp. at 149 n.74 (Tunney Act “represents an endorsement of the morningline of cases in which courts examined proposed consent decrees to determine whether they were in the public interest”); House Report at 11, 1974 U.S.C.C.A.N. at 6542 (“Preservation of antitrust precedent, rather than innovation in the usage of the phrase, ‘public interest,’ is, therefore, unambiguous”).

The court of appeals in United States v. Microsoft Corp., 56 F.3d 1448 (D.C. Cir. 1995) (“Microsoft I”), set forth the factors that a Tunney Act court's public interest determination entails. That inquiry differs fundamentally from the inquiry a court conducts in resolving, by adjudicated judgment, a dispute between the litigants before it. Regardless of the stage at which the parties resolved their disputes and reached a settlement in this case, the Court's task is to determine whether it would be in the public interest to enter that settlement as a judgment, not to devise its own remedy.

A. Whether the Proposed Decree Is Within the Reaches of the Public Interest Is Determined by the Test of Microsoft I

In determining whether the proposed decree is in the public interest,^[44] a district court properly considers whether “the remedies [are] so inconsonant with the allegations charged as to fall outside of the ‘reaches of the public interest.’ ”Microsoft I, 56 F.3d at 1461. In Microsoft I, and again in MSL, 118 F.3d at 783, the D.C. Circuit explained that this inquiry entails consideration of four specific factors:

The district court must examine the decree in light of the violations charged in the complaint and should withhold approval only [1] if any of the terms appear ambiguous, [2] if the enforcement mechanism is inadequate, [3] if third parties will be positively injured, or [4] if the decree otherwise makes “a mockery of judicial power.” See [Microsoft I, 56 F.3d] at 1462.

MSL, 118 F.3d at 783.

The inquiry with respect to the first two factors, ambiguity andenforceability, is straightforward and governed by a reasonableness standard, not a search for perfection. As the Court of Appeals explained, “the district judge who must preside over the implementation of the decree is certainly entitled to insist on that degree of precision concerning the resolution of known issues as to make his task, in resolving subsequent disputes, reasonably manageable.”Microsoft I, 56 F.3d at 1461-62. Similarly, the Court's consideration of the “compliance mechanisms,”id. at 1462—see also 15 U.S.C. 16(e)(1) (“provisions for enforcement”)—is addressed to real and foreseeable problems relating to “actual compliance.”Microsoft I, 56 F.3d at 1462.

The third factor a Tunney Act court properly considers is whether a decree would inflict “positive injury” on third parties, id. at 1461 n.9, 1462. In so doing, the Court must distinguish between positive injury and injury from a decree's “mere failure to secure better remedies for a third party” for whatever reason. MSL, 118 F.3d at 780. The Court “should not reject an otherwise adequate remedy simply because a third party claims it could be better treated.”Microsoft I, 56 F.3d at 1461 n.9.

The heart of a district court's public interest determination, however, is whether the proposed remedy adequately meets the requirements for an antitrust remedy, ATT, 552 F. Supp. at 153, or instead whether “the discrepancy between the remedy and undisputed facts of antitrust violations could be such as to render the decree ‘a mockery of judicial power,’ ''MSL, 118 F.3d at 782 (quoting Microsoft I, 53 F.3d at 1462). The requirements of an antitrust remedy are familiar. As the Court of Appeals noted in remanding this case:

A remedies decree in an antitrust case must seek to “unfetter a market from anticompetitive conduct, Ford Motor Co.[ v. United States], 405 U.S. [562, ] 577 [(1972)], to “terminate the illegal monopoly, deny to the defendant the fruits of its statutory violation, and ensure that there remain no practices likely to result in monopolization in the future,”United States v. United Shoe Mach. Corp., 391 U.S. 244, 250 . . . (1968); see also United States v. Grinnell Corp., 384 U.S. 563, 577 . . . (1966).

253 F.3d at 103.

As the Court of Appeals also emphasized, however, the “ ‘[m]ere existence of an exclusionary act does not itself justify full feasible relief against the monopolist to create maximum competition.’ ”id. at 106 (quoting 3 Antitrust Law¶ 650a, at 67). Thus, in Microsoft I, the Court of Appeals, while noting the familiar standard that an antitrust remedy should “pry open to competition a market that has been closed by defendants’ illegal restraints,” 56 F.3d at 1460 (quoting Int'l Salt Co. v. United States, 332 U.S. 392, 401 (1947)), clearly required that the scope of the appropriate remedy be related to the anticompetitive effects of the illegal conduct. Although an antitrust conduct remedy is not limited to enjoining precisely the conduct found to be unlawful, e.g., Hartford-Empire Co. v. United States, 323 U.S. 386, 409 (1945); ATT, 522 F. Supp. at 150 n.80, nevertheless “the remedies must be of the ‘same type or class’ ” as the violations, and the court is not at liberty to enjoin ‘all future violations of the antitrust laws, however, unrelated to the violations found by the court.’ ”Microsoft I, 56 F.3d at 1460.^[45]

This Court's assessment of the adequacy of the RPFJ also must take into account the risks and uncertainties of further litigation that would be required before there could be an adjudicated final judgment, safe from further challenge on appeal, that would remedy the anticompetitive harm attributable to conduct found to violate the Sherman Act. The Court of Appeals explained in Microsoft I that it is “inappropriate for the judge to measure the remedies in the decree as if they were fashioned after trial. Remedies which appear less than vigorous may well reflect an underlying weakness in the government's case, and for the district court to assume that the allegations in the complaint have been formally made out is quite unwarranted.”Id. at 1461.^[46]

This case differs from Microsoft I in that there have been both findings of fact and conclusions of liability affirmed on appeal. But the difference is one of degree, not kind. Although the Court of Appeals in this case affirmed the district court's judgment of liability for monopolization, it emphasized that neither it, nor the district court, had so far found “a causal connection between Microsoft's exclusionary conduct and its continuing position in the operating systems market,” 253 F.3d at 106-07, sufficient to justify structural relief (although it did not rule out the possibility that this Court would find such a connection on remand). Absent such a causal connection, the court continued, only conduct relief is justified.^[47] Id. at 106. Moreover, the Court of Appeals vacated the district court's judgment of liability with respect to tying, id. at 84 (leaving open the possibility of further litigation on remand using a more demanding standard); reversed as to attempted monopolization, id. at 80-84; and limited the scope of the conduct found to constitute illegal monopolization, id. at 67 (overriding of user's choice of default browser), 71 (deals with ICPs), 75 (development and promotion of a JVM), 78 (course of conduct considered separately). The remedy ultimately imposed on remand, the court directed, “should be tailored to fit the wrong creating the occasion for the remedy.”Id. at 107.

In the absence of a settlement, therefore, the United States would face the prospect of extended litigation with respect to the numerous issues related to relief in this case. An appeal likely would follow the conclusion of the proceedings in this Court. Microsoft also might choose to seek Supreme Court review of the Court of Appeals' decision affirming its liability for monopoly maintenance. See Cert. Petition at 15 (listing issues for future petition). Despite the Findings of Fact and Conclusions of Law, and despite the Court of Appeals' affirmance of a number of the holdings, including liability for monopolization, the ultimate outcome of continued litigation is uncertain, and the path of litigated remedy proceedings would be both risky and costly in terms of resources that might otherwise be devoted to other antitrust enforcement concerns.^[48]

Thus, although the litigation risks the United States faces here are not identical to the litigation risks it faces when it negotiates a settlement prior to trial, the teaching of Microsoft I remains applicable. This Court's evaluation of the RPFJ is properly informed by the public interest in a certain and timely remedy for Microsoft's unlawful conduct and must take account of the uncertainties and risks of further litigation, an inquiry that properly respects the realistic choices the United States faced in deciding to settle the case on the negotiated terms of the RPFJ.

Moreover, in making its determination, the Court properly accords significant weight to the United States' predictive judgments as to the efficacy of remedial provisions. Indeed, such deference is proper even outside the consent decree context. See Ford Motor Co. v. United States, 405 U.S. 562, 575 (1972) (“'once the Government has successfully borne the considerable burden of establishing a violation of law, all doubts as to the remedy are to be resolved in its favor”') (quoting United States v. E.I. du Pont de Nemours Co., 366 U.S. 316, 334 (1961)). Similarly, it is proper to defer to the United States as representative of the public interest when the parties are requesting entry of an agreed-upon judgment.^[49]

As the Court of Appeals has explained, the degree of deference the trial court gives to “the government's predictions as to the effect of the proposed remedies” in a Tunney Act proceeding may vary with the extent of the court's familiarity with the market and other factors, Microsoft I, 56 F.3d at 1461. But, as the Court of Appeals also emphasized, even a court that has extensive relevant expertise should not lightly reject the government's predictions. For example, in the case of the ATT decree—“a decree the oversight of which had been the business of a district judge for several years,”Microsoft I at 1460—the court of appeals instructed that the district judge should not reject an agreed-upon modification of the decree unless it had “'exceptional confidence that adverse antitrust consequences [would] result—perhaps akin to the confidence that would justify a court in overturning the predictive judgments of an administrative agency.””Id. (quoting United States v. Western Elec. Co., 993 F.2d 1572, 1577 (D.C. Cir. 1993)). Indeed, if courts do not give appropriate deference to the United States' views, Tunney Act proceedings will become equivalent to the proceedings that lead to adjudicated judgments with adjudicated remedies.

B. The Court's Task in Entering a Consent Decree Differs From Adjudicating a Remedy

The fact of settlement here determines the Court's role in this proceeding and the inquiry it must make. Because the parties to this case have agreed to the Revised Proposed Final Judgment, the Court now faces a task that differs fundamentally from the task the Court of Appeals envisioned when it remanded United States v. Microsoft Corp.^[50] The Court of Appeals anticipated the necessity of “a relief-specific evidentiary hearing,” providing a basis for “judicial resolution” of factual issues in dispute between the United States and Microsoft—although it recognized that no such hearing would be required if the parties did not dispute the facts. Microsoft, 253 F.3d at 101. Moreover, anticipating continued litigation between the parties over issues related to relief, the Court of Appeals contemplated that this Court would exercise its “broad discretion to enter that relief it calculates will best remedy the conduct it has found to be unlawful,”id. at 105, in light of its findings as to the causal connection between that conduct and the maintenance of Microsoft's market power, id. at 103-07. That is, the Court of Appeals envisioned that this lawsuit would terminate in an “adjudicated judgment,” with the wording of that judgment “determined by the judge, who may draft it, accept the draft proposed by the winning party, or adopt portions of draft language proposed by any of the parties,”Janus Films, Inc. v. Miller, 801 F.2d 578, 581-82 (2d Cir. 1986), to achieve the result the Court views as appropriate—subject to review on appeal.

The parties, however, have chosen to forgo, at least conditionally, their rights to continue litigating to an adjudicated judgment, as well as their rights to further appellate review.^[51] In order to achieve a prompt and certain resolution of this case (see CIS at 2, 60-61), they have chosen the alternative means of terminating litigation “by agreement of the parties,”Janus Films, 801 F.2d at 581, a choice that is clearly permissible at this stage of the litigation. See Cascade Natural Gas Corp. v. El Paso Natural Gas Co., 386 U.S. 129, 136 (1967) (government antitrust case in which the Supreme Court noted that it did “not question the authority of the Attorney General to settle suits after, as well as before, they reach here”); see also Fifth Walnut, Inc. v. Loew's Inc., 176 F.2d 587, 592-93 (2d Cir. 1949) (consent decrees with some defendants entered on remand, while other defendants continued to litigate, after Supreme Court affirmed liability in part and reversed in part in United States v. Paramount Pictures, Inc., 334 U.S. 131 (1948)).^[52]

In these circumstances, the parties themselves have resolved their differences, and the Court therefore does not have the classic judicial task of “[r]esolving contested disputes” of fact, law, and remedy. Maimon Schwarzschild, Public Law by Private Bargain: Title VII Consent Decrees and the Fairness of Negotiated Institutional Reform, 1984 Duke L.J. 887, 903 (1984). Rather, the Court's task is only to determine whether to perform the “judicial act,”United States v. SwiftCo., 286 U.S. 106, 115 (1932), of entering the decree proposed by the parties for entry as the Court's decree.

In cases involving only private interests, the decision to enter settling parties' agreements as judgments requires little judicial attention. See United States v. City of Miami, 614 F.2d 1322, 1330 (5th Cir. 1980) (“In what can be termed “ordinary litigation,” that is, lawsuits brought by one private party against another private party that will not affect the rights of any other persons, settlement of the dispute is solely in the hands of the parties. . . . [T]he court need not and should not get involved”); Janus Films, 801 F.2d at 582 (“court normally has only a limited role so long as the dispute affects only private interests”). But in considering whether it “should enter a consent decree affecting the public interest,”Adams v. Bell, 711 F.2d 161, 170 n.40 (D.C. Cir. 1983) (en banc), “[t]he court has a larger role.”Janus Films, 801 F.2d at 582. Most fundamentally, the reason for that larger role is that a court of equity must avoid letting its decree become “an instrument of wrong” to the public. Swift, 286 U.S. at 115.^[53]

The Court's role in making a public interest determination differs from its role in formulating an adjudicated judgment. Because the Court “is evaluating a settlement, it is not as free to exercise its discretion in fashioning a remedy,”ATT, 552 F. Supp. at 151, as it would be in a case litigated to an adjudicated judgment. The Court is not “empowered to reject [the remedies sought] merely because [it] believe[s] other remedies [are] preferable.”Microsoft I, 56 F.3d at 1460. In this procedural setting, the Court's “function is not to determine whether the resulting array of rights and liabilities ‘is the one that will best serve society,’ but only to confirm that the resulting settlement is “within the reaches of the public interest.” ’ ”'Id. (quoting United States v. Western Elec. Co., 900 F.2d 283, 309 (D.C. Cir. 1990) (emphasis in original), in turn quoting Bechtel, 648 F.2d at 666, in turn quoting United States v. Gillette Co., 406 F. Supp. 713, 716 (D. Mass. 1975)).

This standard reflects not only the proper role of a court of equity asked to lend its authority to the parties' agreement, but also the critical role that consent decrees play in effective public antitrust enforcement. See Senate Report at 5 (“the consent decree is of crucial importance as an enforcement tool, since it permits the allocation of resources elsewhere”); 119 Cong. Rec. 24,600 (1973) (Statement of Sen. Gurney) (Tunney Act “is designed to enhance the value and effectiveness of the consent decree as a tool of public policy”). A consent decree, such as the RPFJ, is the product of negotiation. The parties weigh the benefits of prompt and certain resolution of the case against the possibility that continued litigation might improve their respective positions. Settlements potentially offer the public the benefits of more timely and certain relief, as well as significant savings in judicial and prosecutorial resources. But if courts refused to enter any consent decree that did not match precisely the relief the court would have imposed in the absence of a settlement, “defendants would have no incentive to consent to judgment and this element of compromise would be destroyed. The consent decree would thus as a practical matter be eliminated as an antitrust enforcement tool, despite Congress' directive that it be preserved.”ATT, 552 F. Supp. at 151.

Thus, even in the ATT case, a case of unparalleled public importance in which the trial court had unusual familiarity with both the evidence and the legal arguments of the parties, see id. at 152, the court determined to approve the parties' settlement “[i]f the [proposed] decree meets the requirements for an antitrust remedy.”Id. at 153. The court made clear that it intended to follow that standard whether or not the proposed decree corresponded to the decree the court itself would have imposed had the parties pushed forward to an adjudicated judgment. See id. at 166 n.147 (noting that if the case “were to proceed to final judgment and liability were found, the Court might determine that [certain measures not part of the proposed decree] are appropriate remedies, either as alternatives to the divestiture of the Operating Companies or in addition to such divestiture”).

IV. Entry of the Revised Proposed Final Judgment Is in the Public Interest

The RPFJ is a sound and appropriate response to the violations found by the district court and affirmed by the court of appeals, recognizing, as it must, the substantial narrowing of the case that has taken place since its commencement in 1998. In fashioning appropriate relief, the United States was bound to confine its remedial proposals to the sole basis of liability sustained by the Court of Appeals—i.e., specific acts by Microsoft to impede the emergence of middleware as a threat to the operating system monopoly. The United States also was mindful of the risks associated with tampering too greatly with market mechanisms or seeking to dictate some preferred view of how these markets should develop. While Microsoft's violations must be redressed, the purpose of an antitrust decree is to restore and preserve competition, not to displace competition with a regulatory regime.

The RPFJ meets the goals of public antitrust enforcement. First, it prohibits the conduct found by the court of appeals to be unlawful. The RPFJ contains specific affirmative prohibitions addressing each of the 12 practices the court determined to be acts of monopoly maintenance. This being a monopolization decree, the RPFJ then goes beyond the specific unlawful acts to provide fencing-in relief to address other practices that Microsoft might use to replicate the adverse effects of the offending conduct. For example, although there was no finding that Microsoft had priced its operating systems in an unlawful manner, the RPFJ requires uniform pricing and terms to the major OEM's to prevent retaliatory discrimination against those who might promote competing middleware products. Finally, the RPFJ takes affirmative steps to restore competition by creating favorable conditions under which competing middleware products can be developed and deployed. Among other things, the RPFJ requires the documentation and disclosure of applications interfaces and communications protocols to facilitate third-party development efforts and, in some instances, modifications of the operating system to accommodate competing middleware. Again, these restorative provisions go beyond the specific findings of unlawful behavior, with the goal of creating a forward-looking and comprehensive remedial scheme. Nothing in the RPFJ exempts Microsoft from the mandates of the antitrust laws; it continues to face antitrust exposure for conduct beyond that which has been litigated in this case.

Many commentors, especially many of Microsoft's competitors, urge the Court to withhold Tunney Act approval, advocating their own views of the public interest. Although many such commentors assert that alternatives to the RPFJ might advance their own private strategic and financial interests, such proposals typically lack a foundation in the court's liability findings and likely would be harmful to both competition and consumers. The most persistent complaint is that thefencing-in and restorative provisions are not absolute prohibitions on competitive activity by Microsoft or absolute requirements that Microsoft surrender its technology for the benefit of competitors. Characterizing the RPFJ's limitations as “loopholes,” these commentors fail to recognize that the limitations merely permit Microsoft to compete through actions that are not prohibited by the antitrust laws, were never at issue in this case, or were challenged under theories of liability expressly rejected by the court of appeals.

Protecting competitors from legitimate competition from Microsoft is not a goal of public antitrust enforcement. The goal of the decree is not to secure specific advantages for particular competitors or to dictate for consumers which products or technologies will succeed. In fashioning the RPFJ, the United States has taken pains to remedy the violations without seeking to dictate market outcomes. We have had to balance certain competing interests, recognizing that provisions benefitting firms at one level in the chain of distribution have potential effects on firms at other levels. In striking such balances, the United States has remained faithful to the axiom that the U.S. antitrust laws protect competition not competitors. E.g., Andrx Pharms., Inc. v. Biovail Corp. Int'l, 256 F.3d 799, 812 (D.C. Cir. 2001) (quoting Brunswick Corp. v. Pueblo Bowl-O-Mat, Inc., 429 U.S. 477, 488 (1977), petition for certiorari filed, 70 U.S.L.W. 3465 (Jan. 11, 2002), (No. 01-1050). On that basis, the United States has concluded that further fencing-in or restorative relief based upon hypothetical concerns about Microsoft's behavior not only would be unnecessary and unwarranted, but also might be affirmatively harmful to competition.

Moreover, the RPFJ bears none of the infirmities that would justify the Court's withholding of approval. See MSL, 118 F.3d at 783 (listing factors that would justify withholding approval); Microsoft I, 56 F.3d at 1462 (same). The decree is comprehensive and complex, like the computer industry itself, but its terms are carefully defined and not ambiguous.^[54] The enforcement mechanisms are creative and fully adequate. See pages 60-62 below.^[55] No third party has demonstrated positive injury that would flow from entry of the RPFJ.

A. The Revised Proposed Final Judgment Satisfies the Goals of an Antitrust Remedy and Properly Addresses All Bases of Liability Affirmed by the Court of Appeals

The Revised Proposed Final Judgment provides stringent, effective, enforceable, and immediate relief that fully comports with the purposes of relief in antitrust cases and with Microsoft's degree of liability as affirmed by the Court of Appeals. Restoring competition is the “key to the whole question of an antitrust remedy,”United States v. E.I. du Pont de Nemours Co., 366 U.S. 316, 326 (1961). Competition was injured in this case principally because Microsoft's illegal conduct contributed to the applications barrier to entry into the personal computer operating system market by impeding the emergence of middleware products that had the potential to assist competing operating systems in gaining access to applications and other needed complements. Thus, the key to the proper remedy in this case is to end Microsoft's restrictions on potentially threatening middleware, prevent it from hampering similar nascent threats in the future, and restore competitive conditions like those that existed prior to the unlawful conduct. Moreover, in fashioning relief, the United States, as the public enforcer of the federal antitrust laws, must take care that the remedy not burden the economy or distort market outcomes through unnecessarily regulatory or otherwise inappropriate restraints. The RPFJ responds to these concerns; it imposes a series of requirements and carefully crafted prohibitions on Microsoft's conduct that are designed to accomplish the critical goals of an antitrust remedy without damaging the economy. See Sibley Decl. ¶¶ 86-90.

As instructed by the Court of Appeals and this Court (see Tr. 9/28/01 at 8), the United States fashioned its relief by focusing on the specific practices for which Microsoft's liability was affirmed. Significantly, and quite properly, the RPFJ does not seek to eliminate Microsoft's operating system monopoly, see Sibley Decl. ¶ 8, though many commentors suggest it should. There was never any allegation—let alone any finding—in this case that Microsoft acquired its position in operating systems unlawfully. Further, the district court and the Court of Appeals both determined that they could not conclude that, absent Microsoft's illegal actions, any middleware product or products would have succeeded in toppling the monopoly.

In fashioning the decree, the United States began with the district court's interim conduct remedies of June 2000. See Initial Final Judgment, 97 F. Supp. 2d at 66-69. As this Court recognized (Tr. 9/28/01 at 8), however, those remedies were based on a much wider range of liability findings than were affirmed on appeal. See Microsoft, 253 F.3d at 105 (“[t]his court has drastically altered the District Court's conclusions on liability”). Accordingly, the conduct restrictions of the Initial Final Judgment had to be tailored to the findings the Court of Appeals upheld. At the same time, however, because the interim conduct restrictions were designed to apply only as a stop-gap until the district court's structural remedy was implemented (Initial Final Judgment, 97 F. Supp. 2d at 66), they had to be broadened to address more fully the remedial objectives of arresting the anticompetitive conduct, preventing its recurrence, and restoring competitive conditions in the marketplace. No longer merely a stop-gap, the conduct restrictions now must stand on their own as full relief.

In addition, the remedies needed to be updated to strengthen their long-term effectiveness in the face of the rapid technological innovation that continues to characterize the computer industry. The Court of Appeals noted that the six years that had elapsed between Microsoft's initial anticompetitive conduct and the appeal was an “eternity” in this market, Microsoft, 253 F.3d at 49 (quoted by Order at 2 (Sept. 28, 2001)), and the facts bear that out. When the complaint was filed in May 1998, Microsoft's then-current operating system was Windows 95. Shortly thereafter, Microsoft revised and updated the operating system with Windows 98, which fully integrated Internet Explorer into Windows. In October 2001, just after the case was remanded to this Court, Microsoft introduced the latest generation of its operating system, Windows XP. The remedy crafted now must be relevant in the new world of Windows XP, and beyond. The RPFJ accomplishes these objectives by fundamentally changing—for the ultimate benefit of consumers—the way Microsoft deals with OEMs, IAPs, ISVs, and others in the computer industry.

1. The RPFJ Stops the Unlawful Conduct, Prevents Its Recurrence and Restores Competitive Conditions to the Market

The Court of Appeals affirmed the district court's ruling that Microsoft unlawfully maintained its operating system monopoly through various actions designed to protect the operating system from the potential threat posed by middleware. However, the court reversed the district court's finding that Microsoft was liable based upon its general “course of conduct,” and limited liability to twelve specific anticompetitive acts out of twenty found violative by the district court. The RPFJ provides consumers with prompt, certain, and effective relief by stopping each of the specific acts found unlawful by the Court of Appeals, preventing their recurrence, and restoring competitive conditions in the market.

a. Stops the Unlawful Conduct

Each of the twelve acts found unlawful by the Court of Appeals is listed below with a brief description of the specific provisions of the RPFJ that effectively address the conduct.^[56]

Agreements With Computer Manufacturers (OEMs)

1. Prohibiting removal of desktop icons, folders or Start menu entries (see 253 F.3d at 61)

Section III.H.1 of the RPFJ prevents Microsoft from engaging in this conduct by allowing end users or computer manufacturers to enable or remove access to each middleware product by displaying or removing icons, shortcuts, or menus in the Microsoft operating system in the same place they are normally displayed. See Sibley Decl. ¶ 24.

2. Prohibiting alteration of initial boot sequence (see 253 F.3d at 61)

Section III.C.3 prohibits Microsoft from restricting OEMs from launching middleware automatically at the end of the initial boot sequence or subsequent boot sequences. Section III.C.4 prohibits Microsoft from restricting OEMs from offering users the option of launching a non-Microsoft operating system before Windows starts up. Section III.C.5 prohibits Microsoft from preventing OEMs from presenting their own Internet access offer in the initial boot sequence. See Sibley Decl. ¶ 25.

3. Prohibiting addition of icons or folders of different shape or size (see 253 F.3d at 62)

Section III.C.1 prohibits Microsoft from preventing OEMs from installing and displaying middleware on the desktop. Section III.C.2 prohibits Microsoft from preventing OEMs from distributing or promoting middleware by placing on the desktop shortcuts of any size or shape, as long as they do not impair the functionality of the user interface. Section III.H.3 ensures that Microsoft's operating system does not automatically override the “default” settings to replace competing middleware products without first seeking confirmation from the user. See Sibley Decl. ¶¶ 26, 27.

4. Prohibiting use of “Active Desktop” to promote others” products (see 253 F.3d at 62)

This specific conduct is no longer at issue because Microsoft has discontinued the use of the Active Desktop. Sections III.C.1 and III.C.2 nevertheless broadly restrict Microsoft from preventing OEMs from promoting rival products. See Sibley Decl. ¶ 28.

Binding Internet Explorer to Windows

5. Excluding Internet Explorer from the “Add/Remove” utility (see 253 F.3d at 65)

Section III.H.1 requires Microsoft to allow end users and OEMs to enable or remove access to any Microsoft middleware product. See Sibley Decl. ¶ 29.

6. Commingling code to prevent removal of Internet Explorer (see 253 F.3d at 64-66)

Section III.C.1 prohibits Microsoft from preventing computer manufacturers from installing and displaying rival middleware products on the desktop.

Section III.H.1 requires Microsoft to allow end users and computer manufacturers to remove access to any Microsoft middleware product. See Sibley Decl. ¶ 30.

Agreements With Internet Access Providers (IAPs)

7. Placement of IAP's product on desktop in return for its agreement to exclusively promote Internet Explorer (or to limit shipments of Navigator) (see 253 F.3d at 68)

Section III.G.1 prohibits Microsoft from entering into any agreement with an IAP, ICP, ISV, or OEM that grants consideration on the condition that such entity distribute, promote, use, or support any Microsoft middleware or operating system exclusively or in a fixed percentage. Section III.G.2 prohibits Microsoft from entering into any agreement with an IAP or ICP granting placement in Windows to the IAP or ICP on the condition that it refrain from distributing, promoting, or using any product competing with Microsoft middleware. See Sibley Decl. ¶ 31.

Agreements With Internet Content Providers, Independent Software Vendors, and Apple

8. Agreement with ISVs to make Internet Explorer their default hypertext-based user interface (see 253 F.3d at 71-72)

Section III.F.2 forbids Microsoft from conditioning the grant of consideration on an ISV's refraining from developing, using, distributing, or promoting software that competes with Microsoft's operating system or middleware. Section III.G.1 prohibits Microsoft from entering into any agreement with an IAP, ICP, ISV, or OEM that grants consideration on the condition that such entity distributes, promotes, uses, or supports any Microsoft middleware or operating system exclusively or in a fixed percentage. See Sibley Decl. ¶ 32.

9. Threat to end support of Apple Computer's Office product unless Apple bundled Internet Explorer with the Macintosh operating system and made Internet Explorer the default browser (see 253 F.3d at 73)

Sections III.F.1 and III.F.2, discussed above, prohibit Microsoft from retaliating against ISVs and IHVs, including Apple, for supporting competing products and from offering consideration to such entities for refraining from supporting competing products. In addition, Section III.G.1 prohibits such exclusive arrangements. Sibley Decl. ¶ 33.

Efforts To Exclude Sun's Java

10. Contracts requiring ISVs to exclusively promote Microsoft's Java product (see 253 F.3d at 75)

Section III.F.2 forbids Microsoft from conditioning the grant of consideration on an ISV's refraining from developing, using, distributing, or promoting software that competes with Microsoft's operating system or middleware. Section III.G.1 prohibits Microsoft from entering into any agreement with an IAP, ICP, ISV, or OEM that grants consideration on the condition that such entity distribute, promote, use, or support any Microsoft middleware or operating system exclusively or in a fixed percentage. See Sibley Decl. ¶ 34.

11. Deception of Java developers about Windows-specific nature of tools distributed to them (see 253 F.3d at 76)

Section III.D addresses this conduct by requiring Microsoft to disclose certain APIs required for competing middleware to interoperate with its operating system. This makes the meansby which middleware producers interoperate with the operating system more transparent, and thus hinders Microsoft's ability to disadvantage these competitors. See Sibley Decl. ¶ 35.

12. Coercion of Intel to stop assisting Sun in improving its Java technology (see 253 F.3d at 77)

Sections III.F.1 and III.F.2, discussed above, prohibit Microsoft from retaliating against ISVs and IHVs, including Intel, for supporting competing products and from offering consideration to such entities for refraining from supporting competing products. See Sibley Decl., ¶ 36.

Thus, the RPFJ effectively stops each of the specific acts found unlawful by the Court of Appeals. See Sibley Decl. ¶ 40.

b. Prevents Recurrence of Unlawful Conduct

In addition to stopping and preventing the recurrence of the specific acts found unlawful by the Court of Appeals, the RPFJ guards against the broad range of potential strategies Microsoft might develop to impede the emergence of competing middleware products. See Sibley Decl. ¶¶ 41-51.

Middleware Definition. The various definitions of middleware within the RPFJ (see “Microsoft Middleware” (Section VI.J), “Microsoft Middleware Product” (Section VI.K) “Non-Microsoft Middleware” (Section VI.M), and “Non-Microsoft Middleware Product” (Section IV.N)) are broad. They cover not only the middleware products addressed by the Court of Appeals—Internet browsers and Java—but also additional current middleware products, such as email client software, networked audio/video client software, and instant messaging software, as well as future middleware products not yet in existence. See Sibley Decl. ¶¶ 41-42. To ensure inclusion of future products, the definitions set forth an objective test for products not yet existing; the definitions are qualified, however, in recognition that not all software that exposes APIs qualifies as competitively significant “middleware.” Consequently, third-party software that, like Web browsers or Java, has the potential to create a competitive threat to Microsoft's operating system monopoly, will be covered in the future.

Non-Discrimination and Non-Retaliation. Sections III.A, III.B, and III.F impose broad prohibitions and obligations on Microsoft to ensure that it cannot implement new forms of exclusionary behavior against middleware. See Sibley Decl. ¶¶ 41-42, 51. Section III.A of the RPFJ ensures that OEMs have contractual and economic freedom to make decisions about distributing and supporting non-Microsoft middleware products without fear of coercion or retaliation by Microsoft, by broadly prohibiting retaliation against a computer manufacturer that supports or distributes alternative middleware or operating systems. Because the Court of Appeals agreed with the district court's conclusion that OEMs are a crucial channel of distribution for competing products (see 253 F.3d at 60-61), it is critical that OEMs are free to choose to distribute and promote competing middleware products without interference from Microsoft. Section III.B strengthens Section III.A further by requiring Microsoft to provide uniform licensing terms to the twenty largest and most competitively significant OEMs. Windows license royalties and terms are inherently complex, making it easy for Microsoft to use them to coerce OEM conduct. By eliminating the opportunity for Microsoft to use license terms as a club, the provision ensures that OEMs can make their own choices. Section III.F prohibits Microsoft from retaliating against ISVs and IHVs or conditioning consideration on a developer's refraining from developing, distributing, or writing to software that competes with Microsoft platform software. At the same time, it allows Microsoft to enter into lawful agreements with software developers that include provisions relating to Microsoft software, as long as the provisions are limited and reasonably necessary to effectuate the bona fide contractual relationship.

c. Restores Competitive Conditions to the Market

The RPFJ restores competitive conditions to the market by requiring Microsoft to, among other things: (1) Disclose APIs and license communications protocols that will give ISVs the opportunity to match Microsoft's middleware and server software functionality; and (2) allow OEMs and end users to replace Microsoft middleware and preserve “default” settings that will ensure that Microsoft's middleware does not override the selection of competing middleware products. See Sibley Decl. ¶ 52 Table Two.

APIs and Communications Protocols. Section III.D of the RPFJ requires Microsoft to disclose all of the interfaces and related technical information, including APIs, that Microsoft's middleware uses to interoperate with the Windows operating system. This includes APIs and other information that Microsoft has not previously disclosed. This Section creates the opportunity for ISVs, IAPs, ICPs, and OEMs to develop new middleware products that compete directly with Microsoft on a function-by-function basis, assured that their products will interoperate with the Windows operating system.

Section III.E requires Microsoft to license the communications protocols that are necessary for software located on a computer server to interoperate with the Windows operating system. This means that ISVs will have full access to, and be able to use, the protocols that are necessary for software located on a server computer to interoperate with, and fully take advantage of, the functionality provided by the Windows operating system. The competitive significance of most non-Microsoft middleware, including the browser and Java technologies—against which much of Microsoft's illegal conduct was directed—was and will continue to be highly dependant on content, data, and applications residing on servers and passing over networks (such as the Internet or corporate networks) to that middleware running on personal computers. Section III.E prevents Microsoft from incorporating into Windows features or functionality with which only its own servers can interoperate, and then refusing to make available information about those features that non-Microsoft servers need in order to have the same opportunities to interoperate with the Windows operating system. Although plaintiffs presented limited evidence about servers at trial, and no server-related violations were alleged or found, the United States believed that the RPFJ's effectiveness would be undercut unless it addressed the rapidly growing server segment of the market.

Section III.I requires Microsoft to offer the necessary related licenses of the intellectual property that are required to disclose and license under the RPFJ. Section III.I ensures that Microsoft's obligations to disclose the technical information in Sections III.D and III.E are meaningful. This Section ensures that Microsoft cannot use its intellectual property rights in such a way that undermines the competitive value of its disclosure obligations, while at the same time permitting Microsoft to take legitimate steps to prevent unauthorized use of its intellectual property.

Section III.J permits Microsoft to take certain limited acts to address security-related issues that may arise from the broad disclosures required in Sections III.D and III.E. Section III.J provides a narrow exception for disclosure of APIs and other information for disclosuresthat would compromise system security. See Sibley Decl. ¶ 65.

Power to Replace Microsoft Middleware and Preserve Defaults. Section III.H further ensures that OEMs will be able to offer and promote, and consumers will be able to use, competing middleware products. Section III.H.1 requires Microsoft to allow end users and OEMs to enable or remove access to each Microsoft middleware product. Thus, all middleware products will have equal opportunity for desktop placement. Section III.H.2 requires Microsoft to allow end users, OEMs, and Non-Microsoft Middleware Products to designate non-Microsoft middleware to be invoked in place of the Microsoft middleware. This will allow competing programs to be launched automatically, as defaults, in numerous competitively significant instances.

2. The RPFJ Contains Stringent Enforcement Mechanisms

Sections IV, V, and VII of the RPFJ contain some of the most stringent enforcement provisions ever contained in any modern consent decree. Sections IV and VII provide that the United States' full enforcement powers are available to enforce the judgment. As with any other decree, the United States will have prosecutorial access powers to monitor compliance, and authority to bring: (1) Both civil and criminal contempt petitions; (2) petitions for injunctive relief to halt or prevent violations; (3) motions for declaratory judgment to clarify or interpret particular provisions; and (4) motions to modify the Final Judgment, as appropriate.^[57] Though not required by the RPFJ, the United States has charged a core team of lawyers and economists experienced in the software industry with enforcing the RPFJ. Section IV also provides, as the United States typically requires, that Microsoft maintain an antitrust compliance program to help ensure compliance with the RPFJ. Microsoft is required to appoint an internal compliance officer responsible for supervising the review of Microsoft's activities to determine whether they comply with the RPFJ and for ensuring that Microsoft undertakes internal notification and education responsibilities as required.

But the enforcement provisions do not stop there; rather, they contain two other, aggressive features. First, the RPFJ establishes the Technical Committee, a full-time, on-site compliance team of software design and programming experts, with the means to hire its own staff and consultants, as needed. The Technical Committee will facilitate enforcement by monitoring compliance with the RPFJ and reporting violations to the United States. Additionally, the Technical Committee is available to mediate compliance issues in a manner that will not supplant legal enforcement by the United States. This dispute resolution function reflects the recognition that the market will benefit from rapid, consensual resolution of issues, whenever possible, more so than litigation under the United States' contempt powers. Dispute resolution complements, but does not supplant, the other methods of enforcement. Furthermore, should the United States bring an enforcement action against Microsoft, it will not have to start from scratch. Rather, it will have the Technical Committee's work product, findings, and recommendations to help start any investigation.

In order to fulfill these important responsibilities, the Technical Committee will have complete access to Microsoft's records, facilities, systems, equipment, and personnel. Significantly, this includes access to Microsoft's source code and related materials, which will assist in resolving or identifying any disputes relating to Microsoft's disclosure obligations. The Technical Committee will also have the benefit of written reports and data, which Microsoft must prepare.

Second, under Section V, the RPFJ is scheduled to terminate in five years, but may be extended by two years if the Court finds that Microsoft has engaged in a pattern of wilful and systemic violations. The five-year duration provides sufficient time for the remedies to take effect in this evolving market and to restore competitive conditions to the greatest extent possible. And, because Microsoft will have an incentive to get out from under the RPFJ's restrictions and affirmative obligations as soon as possible, the prospect that it might face a two-year extension will provide an extra incentive to comply.

3. The RPFJ Fully Addresses the Unlawful Conduct While Avoiding an Unnecessarily Regulatory Decree That Would Distort Market Outcomes

As discussed above, the United States carefully crafted the RPFJ to fully address the conduct found unlawful by the Court of Appeals. In doing so, the United States was mindful not to implement an overly broad, unnecessarily regulatory decree that would interfere with competitive conditions in the market. As discussed more fully in the Response to Comments, many commentors seek remedies that preordain market outcomes, require extensive on-going regulation, are vulnerable to manipulation by Microsoft's rivals, or are simply crafted to weaken Microsoft as a competitor.^[58] Such remedies would create inefficiencies in the market and likely result in harm to consumer welfare. See Sibley Decl. ¶¶ 19-21, 86-88.

B. The Revised Proposed Final Judgment Compares Favorably to the Initial Final Judgment

In the Joint Status Report filed September 20, 2001, plaintiffs informed the Court that their proposal for relief would be modeled on the conduct restrictions in the Initial Final Judgment. Joint Status Report at 2 (Sept. 20, 2001). A week later, the Court admonished plaintiffs to determine which relief was no longer appropriate given the Court of Appeals' narrowing of the underlying liability. See Tr. 9/28/01 at 8. Although some commentors have argued that any relief short of the Initial Final Judgment is inadequate, that is contrary to the Court's statements, as well as the Court of Appeals' ruling.

The RPFJ parallels the Initial Final Judgment in many ways, provides for greater relief in some respects, and, in light of the Court of Appeals' decision, omits some provisions. A comparison of the two decrees highlights why the RPFJ is in the public interest.

1. The Revised Proposed Final Judgment Relies on Conduct Restrictions, Rather Than Structural Relief

The most significant difference between the Initial and Revised Proposed Final Judgment is that theformer required a break-up of Microsoft while the latter does not. See IFJ §§ 1-2. Shortly after remand, plaintiffs informed Microsoft and this Court that, in light of the Court of Appeals' decision, we would no longer seek to break up the company. Joint Status Report 2 (Sept. 20, 2001). Thus, even if the United States had not entered into a negotiated settlement and instead litigated a remedy, we would not have sought structural relief. Plaintiffs abandoned the effort to break up Microsoft for both legal and practical reasons.

First, although the Court of Appeals merely vacated—but did not reverse—the Initial Final Judgment, it also made clear that it viewed structural relief in this case skeptically, at best. The court questioned whether plaintiffs had “established a sufficient causal connection between Microsoft's anticompetitive conduct and its dominant position in the [operating system] market” to justify divestiture. Microsoft, 253 F.3d at 106. The court continued that “[a]bsent such causation, the antitrust defendant's unlawful behavior should be remedied by “an injunction against continuation of that conduct.”Id. (quoting 3 Antitrust Law¶ 650a, at 67). The court also suggested that the necessary causation might be lacking, noting that even the district court “expressly did not adopt the position that Microsoft would have lost its position in the [operating system] market but for its anticompetitive behavior.”Id. at 107 (quoting Findings of Fact,¶ 411) (emphasis added). Moreover, the Court of Appeals accepted Microsoft's argument that divestiture is usually reserved for “dissolution of entities formed by mergers and acquisitions,” and directed this Court to “reconsider” whether “divestiture is appropriate with respect to Microsoft, which argues that it is a unitary company.”Id. at 105. And the court emphasized that, when fashioning a new remedy, the district court should bear in mind that the Court of Appeals had “drastically” altered the basis of liability (id. at 105, 107) and that the new remedy should reflect the “limited ground of liability” upheld on appeal. Id. at 107.

Second, if plaintiffs had pursued structural relief on remand, Microsoft would have been entitled to present evidence challenging a “wide range of plaintiffs’ factual representations, including the feasibility of dividing Microsoft, the likely impact on consumers, and the effect of divestiture on shareholders.”Id. at 101. This not only would have been time consuming—both in the district court and then, assuming this Court actually ordered structural relief anew, again in the Court of Appeals—but also would have permitted Microsoft to introduce a plethora of new evidence. Foregoing a structural remedy permitted plaintiffs to speed along the remand proceedings and obtain quicker relief and relief that was more likely to be affirmed on appeal.

2. Remedying Tying Is No Longer an Objective

The Revised Proposed Final Judgment also departs significantly from the Initial Final Judgment by omitting a prohibition on tying. See IFJ § 3.f (“Ban on Contractual Tying”). The Court of Appeals vacated Microsoft's liability on the tying claim (Microsoft, 253 F.3d at 84-97), and soon thereafter plaintiffs informed Microsoft and this Court that, in light of the appellate court's decision, we would no longer pursue allegations of tying. Joint Status Report 2 (Sept. 20, 2001). Thus, even if the United States had not entered into a negotiated settlement and instead continued its litigation, we would not have pursued the tying claim. As with structural relief, plaintiffs abandoned the tying claim for both legal and practical reasons.

The Court of Appeals vacated and remanded, rather than reversed, the tying claim, but left clear instructions on what it expected on remand. See Microsoft, 253 F.3d at 95-97. First, plaintiffs would have to pursue the claim under the rule of reason—with its rigorous proof requirements—rather than the per se rule, which obviates many difficult problems of proof. Id. at 89-95. Second, plaintiffs would be required to show that Microsoft's conduct “unreasonably restrained competition . . . in the tied good market,” but would be “precluded from arguing any theory of harm that depends on a precise definition of browsers or barriers to entry . . . other than what may be implicit in Microsoft's tying arrangement.”Id. at 95. Plaintiffs considered these to be significant legal hurdles.

Of course, pursuing the tying claim on remand also would have raised many of the same practical difficulties as discussed with respect to pursuing structural relief on remand. For example, continued pursuit of tying would have delayed the remand proceedings significantly, thereby further delaying any relief for consumers. Also, Microsoft would have been entitled to introduce a whole host of new evidence relating to its claimed procompetitive justifications for its actions. Thus, the decision to abandon the tying claim was a sound exercise of prosecutorial discretion.

The United States' decision to abandon the tying claim, coupled with the Court of Appeals' decision to reject the attempted monopolization count, had a significant impact on the scope of relief the United States could obtain. The tying and attempted monopolization claims were the only two considered by the Court of Appeals that asserted a direct anticompetitive impact in the market for Web browsers. The remaining count, monopoly maintenance, asserted an anticompetitive impact in the operating system market. The only connection that Web browsers had to this claim was that they were one of the nascent middleware threats that Microsoft had impeded. Therefore, without a claim asserting a direct impact in the Web browser market, the United States' was entitled to relief that restored nascent threats like those that Web browsers had presented, not relief that addressed some broader injury in the browser market.

3. The New Conduct Restrictions Compare Favorably to Those in the Initial Final Judgment

The Revised Proposed Final Judgment is based on the interim conduct restrictions of the Initial Final Judgment of June 7, 2000.

a. Substantive Provisions Included in Both the Initial Final Judgment and the Revised Proposed Final Judgment

Both decrees prohibit Microsoft from retaliating against OEMs that support non-Microsoft products. Compare IFJ § 3.a.i with RPFJ § III.A. Both decrees also require Microsoft to license its Windows operating system products to the 20 largest OEMs on uniform terms. Compare IFJ § 3.a.ii, with RPFJ § III.B. The Initial Final Judgment also afforded OEMs flexibility in product configuration, as does the Revised Proposed Final Judgment. Compare IFJ § 3.a.iii, with RPFJ § III.C. The Initial Final Judgment also barred Microsoft from prohibiting OEMs from automatically launching a substitute user interface upon completion of the boot process (IFJ § 3.a.iii(3)), but the Court of Appeals expressly rejected this basis for liability (Microsoft, 253 F.3d at 63), so the Revised Proposed Final Judgment has no equivalent provision. And both decrees require Microsoft to provide OEMs and consumers the means to remove access to any Microsoft middleware that comes with Windows so that rival middleware may be substituted. Compare IFJ§ 3.g.i, with RPFJ § III.H.

Section 3.b of the Initial Final Judgment required Microsoft to disclose to ISVs and OEMs all Windows APIs necessary for interoperation, including interoperation with servers; Sections III.D and III.E of the RPFJ accomplish the same result. The Initial Final Judgment also required Microsoft to establish a “secure facility” where ISVs, OEMs, and others could “study, interrogate and interact” with the Windows source code to help ensure interoperability. See IFJ § 3.b. The RPFJ omits this provision, but provides for affirmative disclosure of interfaces and protocols, and empowers the Technical Committee to ensure that those disclosures are being made. See RPFJ § IV.B. This approach strikes the appropriate balance by ensuring that developers will have the access they need, while protecting Microsoft's intellectual property from misappropriation.

Both decrees also comprehensively address Microsoft's relations with ISVs and IHVs to ensure that developers can create or use rival software. Both decrees accomplish this objective by broadly prohibiting Microsoft from threatening or retaliating against ISVs or IHVs' actual or contemplated action to develop, use, distribute, promote, or support software that competes with Microsoft middleware or operating system software. Compare IFJ §§ 3.d, 3.h, with RPFJ § III.F. Similarly, both decrees prohibit Microsoft from entering into exclusive agreements with third parties that would require them to refrain from distributing, promoting, using, or supporting rival software. Compare IFJ § 3.e, with RPFJ § III.G.

There are also similarities with respect to enforcement of the two decrees. For example, both decrees require Microsoft to maintain an internal antitrust compliance program (compare IFJ § 4, with RPFJ § IV.C), and both give plaintiffs access to Microsoft's source code, books, correspondence, personnel, etc. and the right to require Microsoft to submit written reports under oath. Compare IFJ § 5, with RPFJ § IV.A.2.

b. The RPFJ Contains Provisions Not Included in the Initial Final Judgment

Although the Initial Final Judgment required Microsoft to disclose its APIs to facilitate interoperation (IFJ § 3.b), the RPFJ goes further by requiring Microsoft to offer the necessary related licenses for the intellectual property that Microsoft must disclose. See RPFJ §§ III.I.1, III.I.4. This ensures that Microsoft cannot use its intellectual property rights to undermine the competitive value of its disclosure obligations.

The RPFJ also significantly enhances enforcement of the decree as compared to the Initial Final Judgment. As previously discussed (see page 60 above), the RPFJ establishes a Technical Committee—a full-time, on-site compliance team of computer experts, complete with its own staff and the power to hire consultants—to monitor compliance with the decree, report violations to the Department, and attempt to resolve technical disputes under the disclosure provisions. RPFJ §§ IV.B.8, IV.D.4. The Technical Committee will have complete access to Microsoft's source code (RPFJ § IV.B.8.c), records, facilities, and personnel. Its dispute resolution responsibilities (RPFJ § IV.D) reflect the recognition that the market will benefit from rapid, consensual resolution of issues whenever possible, more so than litigation under the Department's contempt powers. The dispute resolution process complements, but does not supplant, ordinary methods of enforcement. Complainants may still bring their inquiries directly to the Department, and need not go first to the Technical Committee (RPFJ § IV.D.1). The Technical Committee represents an innovation in consent decrees that the United States believes will improve the speed and quality of enforcing a decree in a field as technical and fast-paced as the computer industry.

The Revised Proposed Final Judgment provides for extending the decree's duration in the event Microsoft is found to have engaged in a “pattern of willful and systematic violations” of its terms. RPFJ § V.B. This potential threat is yet another means to ensure that Microsoft will comply with all of the decree's provisions, to the ultimate benefit of consumers.

Finally, the United States updated the RPFJ in several key ways to improve the clarity of the decree and account for changes in the industry since the IFJ was proposed. First, the RPFJ contains a new provision in Section III.H.3 that prohibits Microsoft from designing Windows to automatically alter an OEMs middleware configurations on the desktop without first seeking confirmation from the user no sooner than 14 days after the consumer has first booted the computer. This provision was included in response to Microsoft's inclusion of the Clean Desktop Wizard product in Windows XP that “sweeps” the unused icons that the OEM has chosen to place on the desktop. Second, the definition of middleware products in the RPFJ was updated by including the actual names of the current Microsoft middleware products—Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger and Outlook Express. (RPFJ § VI.K). This significantly improves the clarity of the decree because the IFJ had not explicitly indicated which current Microsoft products constituted middleware. The RPFJ's middleware definitions were also updated to account for the increased emphasis on downloading as a distribution mechanism in the market.

C. The Revised Proposed Final Judgment Creates Competitive Conditions

There can be no guarantee that consumers and industry participants will prefer rival middleware over Microsoft's software, or that rival middleware will ever displace—or facilitate the displacement of—Microsoft's monopoly position, but the RPFJ restores competitive conditions that foster such threats. Indeed, even the district court, in its extensive findings of fact and conclusions of law, expressly disclaimed the conclusion that but for Microsoft's anticompetitive acts, Netscape's browser and/or Sun's Java technologies necessarily would have eroded Microsoft's monopoly position. See Findings of Fact,¶411; Microsoft, 253 F.3d at 107. Thus, consistent with the antitrust laws, the RPFJ refrains from picking winners and losers, and sticks to restoring the competitive conditions. Consumers benefit from competition, and the goal of the antitrust laws is to protect it, not weight it to a particular result.

V. The Court Should Make Its Public Interest Determination and Enter the Decree as Expeditiously as Possible

Time is of the essence. When the Court five months ago ordered the parties to “expend and concentrate all of their resources upon resolving these cases through a fair settlement for all parties,” Order at 2 (Sept. 28, 2001), the Court recognized:

The claims by Plaintiffs of anticompetitive conduct by Microsoft arose over six years ago, and these cases have been litigated in the trial and appellate court for over four years. As the Court of Appeals has noted, the relevant time frame for this dispute spans “an eternity in the computer industry.”

Order at 2 (Sept. 28, 2001). The public has waited long enough. The Court should make a determination that entry of the proposed final judgment is in the public interest, and then enter it as expeditiously as possible.

A. The Court Should Not Hold an Evidentiary Hearing

As the Court has recognized, the Tunney Act does not require anevidentiary hearing as part of this proceeding,^[59] Tr. at 20 (Feb. 8, 2002), although the Court left open the possibility that it will decide to hold one. Id. at 20-21. The question lies within the Court's sound discretion, guided by the principle that “the trial judge will adduce the necessary information through the least complicated and least time-consuming means possible.” Senate Report at 6; accord House Report at 8.

In our view, at the conclusion of the one- or two-day hearing the Court has ordered, Order (Feb. 15, 2002); see Tr. 2/15/02 at 5, at which the Court is considering allowing oral argument by third parties, id. at 9, the Court will have more than ample information on which to base its public interest determination. The Court should not hold an evidentiary hearing.

First, the very length and size of this case, to which some commentors point as justification for an evidentiary hearing, actually show that there is no need for one. The Court already has available to it a massive trial record—including testimony and thousands of exhibits—plus tens of thousands of comments (some including affidavits, technical reports, and other evidentiary presentations) submitted as part of the Tunney Act process. This record contains extensive information about the competitive structure of the industry and myriad other matters relevant to the public interest determination. Little if anything more would be learned from live witnesses and cross-examination than is already known from the record, comments, and the United States' responses to the comments.^[60]

Second, the most analogous precedent, ATT, does not support an evidentiary hearing. In that case, considering the entry of a decree that would massively restructure the entire telecommunications industry, Judge Greene held two days of hearings, permitting some organizations to “present[] oral argument”ATT, 552 F. Supp. at 147 n.65. But the court “concluded that none of the issues before it require[d] an evidentiary hearing. That being so, there [was] obviously no need, nor indeed any occasion, for the presentation by a third party of its own witnesses or for the cross-examination of adverse witnesses.”Id. at 219. See also id. at 188 n.233 (rejecting contention that “the Court should not assess the propriety of the restrictions without holding evidentiary hearings with regard to the need therefor”).^[61]

Third, it is clear that much of the impetus behind the call for an evidentiary hearing comes from commentors who want that hearing to inquire into the Department of Justice's decision to enter into a settlement. The drive to challenge the propriety of prosecutorial decisions provides no warrant for an evidentiary hearing, because “the district court is not empowered to review the actions or behavior of the Department of Justice; the court is only authorized to review the decree itself.”Microsoft I, 56 F.3d at 1459. See also Maryland v. United States, 460 U.S. 1001, 1005-06 (1983) (Rehnquist, J., dissenting) (considerations that led the Department of Justice to settle are not amenable to judicial review).

Fourth, an evidentiary hearing would further complicate the Tunney Act process and invite unwarranted delay in entering the RPFJ. Given the number of commentors and persons interested in participating in the Tunney Act process, it could prove difficult to manage an evidentiary hearing equitably without causing substantial delay. The public interest in achieving a prompt resolution of this case and rapid implementation of remedies^[62] should not be frustrated absent a showing of very good cause.

B. The Court Should Not Delay Entry of the Decree Pending the Remedies Hearing in New York v. Microsoft

The remedies hearing in New York v. Microsoft Corp., No. 98-CV-1233, is currently scheduled to begin on March 11, 2002. Some commentors have suggested that the Court delay its public interest determination in this case pending the results of that hearing, evidently so that the record, and perhaps the Court's adjudicated judgment, in New York can be imported into this Tunney Act proceeding. The suggestion that the Court link the two proceedings in this manner is legally flawed and ill-advised. Were the Court to follow the suggestion, it would undermine the foundations of the Tunney Act, bring into question the authority of the Department of Justice to settle lawsuits, threaten the viability of the consent decree as a tool of antitrust enforcement, and risk serious damage to federal/state cooperation in the prosecution of antitrust cases. It would be an unfortunate precedent for this Court to set.

1. Linking This Case to the Remedies Hearing in New York Would Be Bad Law and Bad Policy

Linking this case to the remedies hearing, and outcome, in New York would transform the nature of this proceeding in ways Congress did not intend and the law does not countenance. The Tunney Act establishes a complete framework for review and entry of a consent decree in a civil antitrust suit brought by the United States, a framework that does not encompass separate litigation brought by other plaintiffs. The Court's role in this case is to determine whether the judicial act of entering a proposed decree arrived at by agreement of the parties is “within the reaches of the public interest.”Microsoft I, 56 F.3d at 1458 (quotation marks and emphasis omitted). In contrast, the role of the Court in New York is that of judicially resolving disputes between the parties—according to the applicable evidentiary standard—and ultimately imposing an adjudicated judgment. The Court's ability to play different roles in the two cases is not in doubt. But the Tunney Act does not provide for mixing those roles.

To the extent the Court delays this proceeding so as to rely on the New York record or result, the Court bringsadversary litigation, with all that entails, into the Tunney Act process, which is intended to be something quite different. The Tunney Act, intended “to encourage[] settlement by consent decrees as part of the legal policies expressed in the antitrust laws,”United States v. Alex. Brown Sons, 963 F. Supp. 235, 238-39 (S.D.N.Y. 1997) (quoting House Report at 6, 1974 U.S.C.C.A.N. at 6537), aff'd sub nom. United States v. Bleznak, 153 F.3d 16 (2d Cir. 1998), would become the continuation of litigation by other means.

Linking the two proceedings would also leave the United States with two equally improper alternatives. Either the United States would have to participate, through intervention or other means, in litigation in New York (where it is too late to participate in remedy-phase discovery), or if not, it would have to let the outcome of its own case turn on a litigation record to which it is a stranger. Each alternative effectively deprives the United States of its ability to resolve a case by consent decree. Each deprives the Department of Justice of its authority to settle cases, Supreme Court precedent to the contrary notwithstanding, see Cascade Natural Gas Corp. v. El Paso Natural Gas Co., 386 U.S. 129, 136 (1967) (Court does “not question the authority of the Attorney General to settle suits after, as well as before, they reach here”), because the case effectively continues in full litigation despite the settlement agreed to by the parties. The only difference between the alternatives left to the government is that the first continues to draw upon the resources a settlement should have freed up for use in other antitrust enforcement as the price of continued influence over the outcome of the government's own case, while the second provides a resource savings, but at the cost of that very influence.

Both the United States and antitrust defendants would have a substantially reduced incentive to settle cases at all if Tunney Act proceedings could be linked to other litigation. Why settle, if the entry of judgment in the “settled” case could be delayed pending the outcome of parallel litigation that remains unsettled, and if the result in the “settled” litigation could depend on what happens in the remaining litigation? That result may satisfy those who think government antitrust cases in general, or at least this government antitrust case in particular, should not be settled, but it is inconsistent with the Tunney Act policy favoring settlement as a viable tool in the antitrust enforcement arsenal.

The possibility of this linking comes about here only because the United States, 20 States, and the District of Columbia joined forces in a cooperative effort to challenge anticompetitive conduct by a monopolist. This case and New York were consolidated for all purposes, and the plaintiffs worked closely to bring the matter to a successful resolution.^[63] Last November, the remaining plaintiffs reached a point where they could not all agree on the next step; the United States and nine States settled with Microsoft, while the other nine plaintiff States (including the District of Columbia) chose to continue litigating. If that fact means, as a result of linkage between the remedy phase of New York and this Tunney Act proceeding, that the United States effectively has been prevented from settling its own lawsuit, the United States surely will view the prospect of future such collaborative enforcement efforts in a less favorable light. Such a result would be exceedingly unfortunate for the future of antitrust enforcement.

Finally, of course, linkage inevitably would delay entry of a final judgment, thereby further thwarting the public interest in prompt resolution of this case. Cf. ATT, 552 F. Supp. at 213 (deferring approval of the proposed decree “would be unfair to the parties and to the public;” delay “can only multiply the costs of uncertainty that have plagued the industry far too long”).

2. The Claimed Benefits of Linkage Are Illusory

Perhaps these costs of linkage would be acceptable if the gains to be had were substantial. They are not.

Some argue that delaying this proceeding until after the remedies phase of New York will avoid the risk that the Court will prejudge that remedies phase by its determination here. But that risk is trivial. What the two cases share is one defendant (Microsoft), and a common record as of November 6, 2001. Two things principally set them apart. One is their different records from November 6 forward. The other, more important, distinction is that the Court faces two radically different tasks and addresses two radically different questions in the two proceedings. See pages 42-46, above. The Court's task here is to determine whether entry of a negotiated settlement is in the public interest according to a deferential standard of review; its task in New York is to enter an adjudicated judgment, perhaps devised by the Court itself, that the Court, in the exercise of its “broad discretion . . . [,] calculates will best remedy the conduct it has found to be unlawful,”Microsoft, 253 F.3d at 105, in light of the facts proven before it. The risk that its determination here would lead the Court to prejudge the result in New York is therefore minuscule.

Some also suggest that delay here until a remedy is determined by adjudication in New York will avoid the risk of inconsistent remedies in the two cases. This risk, too, is small. Although it is quite possible that the remedy in New York might impose on Microsoft requirements not imposed here, or not impose on Microsoft requirements that are imposed here, that possibility need not give rise to inconsistency. Only if the two remedies actually conflict—for example, one remedy requires Microsoft to do something the other prohibits, or one remedy requires Microsoft to provide access to a facility the other takes away from Microsoft—is there a troubling inconsistency. There is no reason to expect such an inconsistency to arise, especially given that the Court will be well aware of the specific terms of the RPFJ when it eventually enters judgment in New York. If an inconsistency does arise, however, there are ample means to deal with it. See, e.g., RPFJ § VII (Court retains jurisdiction to modify decree).

Finally, some have suggested that delaying the proceedings here would conserve judicial resources. But apart from study of the existing record, which is necessary for both cases, judicial resources in the two proceedings will be devoted primarily to the remedies trial in New York and to the review of the public comments and the United States' response in this matter. The Court could not properly reduce the resources it devotes to these two tasks whatever the sequence of the two proceedings. Moreover, the Tunney Act provides the Court broad latitude to streamline its review process, 15 U.S.C. § 16(f). Linking that review to separate litigation makes the Tunney Act review dependent on trials or hearings that are far less flexible, which can only complicate and delay the Tunney Act review.

Conclusion

The proposed final judgment satisfies all of the requirements of an antitrust remedy, complies with the decision of the court of appeals, and, most importantly, is in the public interest. Accordingly, the Court should enter the decree as soon as possible.

Dated: February 27, 2002.

Respectfully submitted,

Charles A. James,

Assistant Attorney General.

Deborah P. Majoras,

Deputy Assistant Attorney General.

Phillip R. Malone,

Renata B. Hesse,

David Blake-Thomas,

Paula L. Blizzard,

Kenneth W. Gaul,

Adam D. Hirsh,

Jacqueline S. Kelley,

Steven J. Mintz,

Barbara Nelson,

David Seidman,

David P. Wales,

Attorneys.

Philip S. Beck,

Special Trial Counsel.

U.S. Department of Justice, Antitrust Division, 601 D Street, NW., Suite 1200, Washington, DC 20530, [phone].

Appendix A to Memorandum in Support of Entry of Proposed Judgment

Comparison of Court of Appeals' Findings on Liability toProvisions of the Revised Proposed Final Judgment

I. Liability Findings Affirmed by the Court of Appeals

Agreements with Computer Manufacturers (“OEMs”)

1. Microsoft prohibited OEMs from removing any desktop icons, folders, or “Start” menu entries, thereby “thwart[ing] the distribution of a rival browser by preventing OEMs from removing visible means of user access to IE.”United States v. Microsoft Corp., 253 F.3d 34, 61, 64 (D.C. Cir. 2001).

RPFJ Provisions:

• Section III.H.1 requires Microsoft to “[a]llow end users (via a mechanism readily accessible from the desktop or Start menu such as an Add/Remove icon) and OEMs (via standard preinstallation kits) to enable or remove access to each Microsoft Middleware Product . . . The mechanism shall offer the end user a separate and unbiased choice with respect to enabling or removing access . . . and altering default invocations . . . with regard to each such Microsoft Middleware Product . . . .”

2. Microsoft prohibited OEMs from “modifying the initial boot sequence . . ., thus prevent[ing] OEMs from using that process to promote the services of IAPs. . . .” 253 F.3d at 61-62, 64.

RPFJ Provisions:

• Section III.C.3 prohibits Microsoft from restricting OEMs from “[l]aunching automatically, at the conclusion of the initial boot sequence or subsequent boot sequences, or upon connections to or disconnections from the Internet, any Non-Microsoft Middleware . . . .”
• Section III.C.4 prohibits Microsoft from restricting OEMs from “[o]ffering users the option of launching other Operating Systems . . . or a non-Microsoft boot-loader or similar program. . . .”
• Section III.C.5 prohibits Microsoft from restricting OEMs from “[p]resenting in the initial boot sequence its own IAP offer . . .”

3. Microsoft prohibited OEMs from “adding icons or folders different in size or shape from those supplied by Microsoft,” thereby preventing OEMs from “promot[ing] rival browsers, which keeps developers focused upon the APIs in Windows.” 253 F.3d at 62, 64.

RPFJ Provisions:

• Section III.C.1 prohibits Microsoft from restricting OEMs from “[i]nstalling, and displaying icons, shortcuts, or menu entries for, any Non-Microsoft Middleware . . . on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed . . . .”
• Section III.C.2 prohibits Microsoft from restricting OEMs from “[d]istributing or promoting Non-Microsoft Middleware by installing and displaying on the desktop shortcuts of any size or shape . . . .”
• Section III.H.3 requires Microsoft to “[e]nsure that a Windows Operating System Product does not (a) automatically alter an OEM's configuration of icons, shortcuts or menu entries . . . pursuant to Section III.C of this Final Judgment without first seeking confirmation from the user and (b) seek such confirmation . . . until 14 days after the initial boot up of a new Personal Computer . . . .”

4. Microsoft prohibited OEMs from “using the ‘Active Desktop’ feature to promote third-party brands,” thereby preventing OEMs from “promot[ing] rival browsers, which keeps developers focused upon the APIs in Windows.” 253 F.3d at 62, 64.

RPFJ Provisions:

• Section III.C.1 prohibits Microsoft from restricting OEMs from “[i]nstalling, and displaying icons, shortcuts, or menu entries for, any Non-Microsoft Middleware . . . on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed . . . .”
• Section III.C.2 prohibits Microsoft from restricting OEMs from “[d]istributing or promoting Non-Microsoft Middleware by installing and displaying on the desktop shortcuts of any size or shape . . . .”

Binding of Internet Explorer to Windows

5. Microsoft excluded IE from the “Add/Remove Programs” utility, thereby “reduc[ing] the usage share of rival browsers not by making Microsoft's own browser more attractive to consumers but, rather, by discouraging OEMs from distributing rival products.” 253 F.3d at 65, 67.

RPFJ Provisions:

• Section III.H.1 requires Microsoft to “[a]llow end users (via a mechanism readily accessible from the desktop or Start menu such as an Add/Remove icon) and OEMs (via standard preinstallation kits) to enable or remove access to each Microsoft Middleware Product . . .. The mechanism shall offer the end user a separate and unbiased choice with respect to enabling or removing access . . . and altering default invocations . . . with regard to each such Microsoft Middleware Product. . . .”

6. Microsoft “'plac[ed] code specific to Web browsing in the same files as code that provided operating system functions”' (253 F.3d at 65 (quoting Findings of Fact¶ 161)), thus “deter[ring] OEMs from pre-installing rival browsers, thereby reducing the rivals' usage share and, hence, developers' interest in rivals' APIs as an alternative to the API set exposed by Microsoft's operating system.” 253 F.3d at 66.

RPFJ Provisions:

• Section III.C.1 prohibits Microsoft from restricting OEMs from “[i]nstalling, and displaying icons, shortcuts, or menu entries for, any Non-Microsoft Middleware . . . on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed . . . .”
• Section III.H.1 requires Microsoft to “[a]llow end users (via a mechanism readily accessible from the desktop or Start menu such as an Add/Remove icon) and OEMs (via standard preinstallation kits) to enable or remove access to each Microsoft Middleware Product . . .. The mechanism shall offer the end user a separate and unbiased choice with respect to enabling or removing access . . . and altering default invocations . . . with regard to each such Microsoft Middleware Product . . . .”

Agreements With Internet Access Providers (“IAPs”)

7. Microsoft “agreed to provide easy access to IAPs” services from the Windows desktop in return for the IAPs' agreement to promote IE exclusivelyand to keep shipments of internet access software using Navigator under a specific percentage, typically 25%.” 253 F.3d at 68. Such agreements ensure “that the “majority” of all IAP subscribers are offered IE either as the default browser or as the only browser. . . . .”Id. at 71.

RPFJ Provisions:

• Section III.G.1 prohibits Microsoft from entering into any agreement with “any IAP, ICP, ISV, IHV, or OEM that grants Consideration on the condition that such entity distributes, promotes, uses, or supports, exclusively or in a fixed percentage, any Microsoft Platform Software . . . .”
• Section III.G.2 prohibits Microsoft from entering into any agreement with “any IAP or ICP that grants placement on the desktop or elsewhere in any Windows Operating System Product to that IAP or ICP on the condition that the IAP or ICP refrain from distributing, promoting or using any software that competes with Microsoft Middleware.”

Agreements With Internet Content Providers (“ICPs”), Independent Software Vendors (“ISVs”) and Apple

8. In dozens of “First Wave” agreements, Microsoft “ ‘promised to give preferential support, in the form of early Windows 98 and Windows NT betas, other technical information, and the right to use certain Microsoft seals of approval, to important ISVs that agree to certain conditions. One of these conditions is that the ISVs use Internet Explorer as the default browsing software for any software they develop with a hypertext-based user interface.“ ” 253 F.3d at 71-72 (quoting Findings of Fact¶339). In so doing, Microsoft kept “rival browsers from gaining widespread distribution (and potentially attracting the attention of developers away from the APIs in Windows) . . . .”Id. at 72.

RPFJ Provisions:

• Section III.F.2 prohibits Microsoft from “condition[ing] the grant of any Consideration on an ISV's refraining from developing, using, distributing, or promoting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software . . . .”
• Section III.G.1 prohibits Microsoft from entering into any agreement with “any IAP, ICP, ISV, IHV, or OEM that grants Consideration on the condition that such entity distributes, promotes, uses, or supports, exclusively or in a fixed percentage, any Microsoft Platform Software . . . .”

9. Microsoft agreed to continue development of Mac Office, a suite of business productivity applications needed by Apple, only when Apple agreed to make Internet Explorer the default browser on Apple's operating system and to refrain from positioning icons for non-Microsoft browsing software on the desktop of new Apple Macintosh computers or Mac OS upgrades. 253 F.3d at 73. “Microsoft's exclusive contract with Apple has a substantial effect in restricting distribution of rival browsers . . . .”Id. at 73-74.

RPFJ Provisions:

• Section III.F.1 prohibits Microsoft from retaliating against any ISV or IHV because of that ISV's or IHV's “developing, using, distributing. promoting or supporting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software.”
• Section III.F.2 prohibits Microsoft from “condition[ing] the grant of any Consideration on an ISV's refraining from developing, using, distributing, or promoting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software . . . .”
• Section III.G. 1. prohibits Microsoft from entering into any agreement with “any IAP, ICP, ISV, IHV, or OEM that grants Consideration on the condition that such entity distributes, promotes, uses, or supports, exclusively or in a fixed percentage, any Microsoft Platform Software . . . .”

Efforts to Exclude Sun's Java

10. In dozens of “First Wave” agreements with ISVs, Microsoft “conditioned receipt of Windows technical information upon the ISVs” agreement to promote Microsoft's JVM [Java Virtual Machine] exclusively. . . .” 253 F.3d at 75. Such agreements “foreclosed a substantial portion of the field for JVM distribution and . . ., in so doing, they protected Microsoft's monopoly from a middleware threat . . . .”Id. at 76.

RPFJ Provisions:

• Section III.F.2 prohibits Microsoft from “condition[ing] the grant of any Consideration on an ISV's refraining from developing, using, distributing, or promoting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software. . . .”
• Section III.G.1 prohibits Microsoft from entering into any agreement with “any IAP, ICP, ISV, IHV, or OEM that grants Consideration on the condition that such entity distributes, promotes, uses, or supports, exclusively or in a fixed percentage, any Microsoft Platform Software . . . .”

11. Microsoft “deceived Java developers regarding the Windows-specific nature” of Microsoft's Java software development tools. Thus, “developers who relied upon Microsoft's public commitment to cooperate with Sun and who used Microsoft's tools to develop what Microsoft led them to believe were cross-platform applications ended up producing applications that would run only on the Windows operating system.” 253 F.3d at 76.

RPFJ Provisions:

• Section III.D requires Microsoft to disclose to all ISVs “the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product.”

12. Microsoft threatened Intel, which was developing a high-performance cross-platform Windows-compatible JVM, that if Intel “did not stop aiding Sun on the multimedia front, then Microsoft would refuse to distribute Intel technologies bundled with Windows.” 253 F.3d at 77.

RPFJ Provisions:

• Section III.F.1 prohibits Microsoft from retaliating against any ISV because of that ISV's “developing, using, distributing, promoting or supporting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software.”
• Section III.F.2 prohibits Microsoft from “condition[ing] the grant of any Consideration on an ISV's refraining from developing, using, distributing, or promoting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software . . . .”

II. Liability Findings Rejected by the Court of Appeals

1. Microsoft prohibited OEMs from “causing any user interface other than the Windows desktop to launch automatically.” 253 F.3d at 62. The court of appeals found that this restriction had an anticompetitive effect (id.), but does not violate Section 2 because “a shell that automatically prevents the Windows desktop from ever being seen by the user is a drastic alteration of Microsoft's copyrighted work, and outweighs the marginal anticompetitive effect of prohibiting the OEMs from substituting a different interface automatically uponcompletion of the initial boot process.”Id. at 63.

2. Microsoft designed Windows 98 to “override the user's choice of a default browser in certain circumstances.” 253 F.3d at 67. The court of appeals found that plaintiffs had failed to rebut Microsoft's proffered technical justification that such overriding was necessary in a “few” circumstances, e.g., invoking the Windows 98 Help system, Windows Update feature, or accessing the Internet through “My Computer” or “Windows Explorer.”Id.

3. Microsoft offered Internet Explorer free of charge to IAPs and ISVs. The court of appeals held that “the antitrust laws do not condemn even a monopolist for offering its product at an attractive price, and we therefore have no warrant to condemn Microsoft for offering . . . IE . . . free of charge or even at a negative price.” 253 F.3d at 68 (giving IE to IAPs); see also id. at 75 (giving IE to ISVs).

4. Microsoft offered “IAPs a bounty for each customer the IAP signs up for service using the IE browser.” 253 F.3d at 67. The court of appeals held that “the antitrust laws do not condemn even a monopolist for offering its product at an attractive price, and we therefore have no warrant to condemn Microsoft for offering . . . IE . . . free of charge or even at a negative price.”Id. at 68.

5. Microsoft developed the IE Access Kit (IEAK), a “software package that allows an IAP to ‘create a distinctive identity for its service in as little as a few hours by customizing the [IE] title bar, icon, start and search pages,' '' and offered the IEAK to IAPs for free. 253 F.3d at 68 (quoting Findings of Fact¶ 249). The court of appeals held that “the antitrust laws do not condemn even a monopolist for offering its product at an attractive price, and we therefore have no warrant to condemn Microsoft for offering . . . the IEAK . . . free of charge or even at a negative price.”Id.

6. Microsoft entered into exclusive dealings with ICPs, which develop websites, in exchange for the ICPs' agreement to distribute, promote, and rely on IE rather than Netscape's Navigator browser. 253 F.3d at 71. The court of appeals found that “plaintiffs failed to demonstrate that Microsoft's deals with the ICPs have a substantial effect upon competition. . . .”Id.

7. Microsoft developed a JVM that “allows Java applications to run faster on Windows than does Sun's JVM, . . . but a Java application designed to work with Microsoft's JVM does not work with Sun's JVM and vice versa.” 253 F.3d at 74. The court of appeals held that “a monopolist does not violate the antitrust laws simply by developing a product that is incompatible with those of its rivals.”Id. at 75.

8. The court of appeals reversed the district court's finding that Microsoft was liable based on its “general ‘course of conduct’ '' apart from specific acts that violated Section 2. 253 F.3d at 78.

Appendix B to Memorandum in Support of Entry of Proposed Judgment

United States v. Microsoft Corp. — NEWSPAPER NOTICE; Department of Justice, Antitrust Division

Take notice that a revised proposed Final Judgment as to Microsoft Corporation has been filed in a civil antitrust case, United States of America v. Microsoft Corporation, Civil No. 98-1232. On May 18, 1998, the United States filed a Complaint alleging that Microsoft, the world's largest supplier of computer software for personal computers, restrained competition in violation of Sections 1 and 2 of the Sherman Act, 15 U.S.C. 1-2. Following a 78-day trial in late 1998 and early 1999, the United States District Court for the District of Columbia found that Microsoft had violated both Sections 1 and 2 of the Sherman Act. On appeal, the United States Court of Appeals for the District of Columbia unanimously affirmed portions of the district court's finding and conclusion that Microsoft illegally maintained its operating system monopoly in violation of Section 2 of the Sherman Act, but reversed and remanded other portions of the district court's determinations. Specifically, the court of appeals reversed the district court's determination that Microsoft violated Section 2 by illegally attempting to monopolize the Internet browser market and remanded the district court's determination that Microsoft violated Section 1 of the Sherman Act by unlawfully tying its browser to its operating system. The court of appeals also vacated the district court's remedial order, including its order that Microsoft be split into separate operating systems and applications businesses, and remanded the case to a new district court judge for further proceedings. Following intensive mediation efforts, the United States and Microsoft subsequently reached the agreement embodied in the revised proposed Final Judgment, which would impose injunctive relief to enjoin continuance and prevent recurrence of the violations of the Sherman Act by Microsoft that were upheld by the court of appeals.

The revised proposed Final Judgment, filed November 6, 2001, will stop recurrence of Microsoft's unlawful conduct, prevent recurrence of similar conduct in the future and restore competitive conditions in the personal computer operating system market by, among other things, prohibiting actions by Microsoft to prevent computer manufacturers and others from developing, distributing or featuring middleware products that are threats to Microsoft's operating system monopoly; creating the opportunity for independent software vendors to develop products that will be competitive with Microsoft's middleware products; requiring Microsoft to disclose interfaces in order to ensure that competing middleware and server software can interoperate with Microsoft's operating systems; ensuring full compliance with the revised proposed Final Judgment; and providing for swift resolution of technical disputes. A Competitive Impact Statement has been filed by the United States describing the Complaint, the revised proposed Final Judgment, the industry, and the remedies available to private litigants who may have been injured by the alleged violation. Copies of the Complaint, revised proposed Final Judgment and Competitive Impact Statement are available for inspection at the Department of Justice in Washington, DC, at Antitrust Documents Group, 325 7th Street NW., Ste. 215 North, Washington, DC 20530 (please call 202-514-2481, for appointments only), on the Department of Justice Web site at http://www.usdoj.gov/​atr,, and at the Office of the Clerk of the United States District Court for the District of Columbia, 333 Constitution Avenue, NW., Washington, DC 20001.

Interested persons may address comments to Renata Hesse, Trial Attorney, Suite 1200, Antitrust Division, Department of Justice, 601 D Street, NW., Washington, DC 20530; (facsimile) 202-616-9937 or 202-307-1454; or (e-mail) [e-mail] within 60 days of the date of publication of the revised proposed Final Judgment and Competitive Impact Statement in the Federal Register. While comments may also be sent by regular mail, in light of recent events affecting the delivery of all types of mail to the Department of Justice, including U.S. Postal Service and other commercial delivery services, and current uncertainties concerning when the timely delivery of this mail may resume, the Department strongly encourages, whenever possible, that comments be submitted via e-mail or facsimile.

Appendix C to Memorandum in Support of Entry of Proposed Judgment

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant; Declaration of David S. Sibley.

Next Court Deadline: March 6, 2002; Tunney Act Hearing.

I. Qualifications and Introduction

1. My name is David S. Sibley. I am the John Michael Stuart Centennial Professor of Economics at the University of Texas at Austin. I received the degree of B.A. in Economics from Stanford University in 1969 and a Ph.D. in Economics from Yale University in 1973. In addition to my current teaching responsibilities, I have taught graduate level courses in economics at the University of Pennsylvania and Princeton University. Prior to joining the University of Texas, I was Head of the Economics Research Group at Bell Communications Research. I have also served as a Member of the Technical Staff in economics at Bell Laboratories. During the last thirty years, I have carried out extensive research in the areas of industrial organization, microeconomic theory, and regulation. My publications have appeared in a number of leading economic journals, including the Journal of Economic Theory, Review of Economic Studies, Rand Journal of Economics, American Economic Review, Econometrica, and the International Economic Review, among others. I am also the co-author (with Steven J. Brown) of a leading textbook on monopoly pricing, The Theory of Public Utility Pricing, which was first published by Cambridge University Press in 1986.

2. I have consulted extensively for various firms and agencies, both in the United States and abroad, on antitrust and regulatory matters. In 1998, I was retained by the U.S. Department of Justice (“DOJ”) to examine the competitive effects of contractual restrictions in agreements between Microsoft Corporation (“Microsoft”) and personal computer original equipment manufacturers (“PC manufacturers” or “OEMs”), Internet access providers (“IAPs”), and Internet content providers (“ICPs”). The declaration that I filed in May 1998 on behalf of the Antitrust Division of the DOJ summarized my economic analysis.^[1] Appendix A contains a copy of my curriculum vitae.

3. I have been asked by the DOJ to review the terms of its proposed settlement with Microsoft and to provide an opinion as an independent economist as to whether the antitrust remedy embodied in the settlement is in the “public interest.” It is my understanding that key components of the public interest standard of the Tunney Act are satisfied when the antitrust remedy is sufficient to (1) stop the offending conduct, (2) prevent its reoccurrence, and (3) restore competitive conditions.^[2]

4. In conducting this analysis, I examined the following documents: (1) the Revised Proposed Final Judgment,^[1] the Second Revised Proposed Final Judgment, including the accompanying memorandum regarding modifications,^[2] and the Competitive Impact Statement of the DOJ;^[3] (2) the Findings of Fact and Conclusions of Law issued by Judge Jackson;^[4] (3) the decision issued by the U.S. Court of Appeals for the D.C. Circuit in June of 2001;^[5] (4) the record from the U.S. Senate Judiciary Committee's December 12, 2001, hearing regarding the proposed settlement, including the responses to follow-up questions posed to Assistant Attorney General Charles James;^[6] (5) the DOJ's written response to questions regarding the proposed settlement raised by Senator Orrin Hatch;^[7] (6) the Litigating States Proposed Final Judgment; (7) comments on the settlement filed by third parties, including declarations submitted by other economists; and (8) public documents and websites containing relevant information.

5. My conclusions are summarized as follows:

• Any economic analysis of the SRPFJ must have as its starting point a clear delineation of the conduct found to be unlawful. The remedy presently under consideration must therefore focus attention on and fully resolve the appellate court finding that Microsoft engaged in specific anticompetitive acts to maintain its operating system monopoly.
• In developing this remedy, it is necessary to balance two broad factors: (1) the need to impose constraints on Microsoft's current and future behavior so that the unlawful acts stop and do not recur, and competitive conditions are restored; and (2) the requirement that these constraints not be so intrusive and complex that they themselves distort market outcomes.
• The SRPFJ achieves the right balance. Broadly defined provisions banning exclusivity, discrimination, and retaliation fundamentally alter the way Microsoft does business, and eliminate the artificial entry barriers erected by Microsoft that are the source of competitive concern. At the same time, the SRPFJ does not create market distortions, such as over-extensive regulation of Microsoft that may invite inefficient rent-seeking by Microsoft's competitors, and make Microsoft a less efficient competitor.
• Microsoft erected artificial entry barriers to slow or halt the natural tendency of the marketplace to provide certain alternative technologies (known as “middleware”) that have the potential to erode Microsoft's operating system monopoly. The proposed decree aims to restore and enhance competitive conditions by removing technical barriers between Microsoft and rival middleware suppliers. This is the appropriate conduct to be remedied, not the existence of the monopoly itself, or barriers which arise naturally in software markets.
• The proposals of other commentators fail to strike the right balance. In an attempt to eliminate all theoretical ways in which Microsoft could harm competition, they propose a complex regulatory program that is likely to be slow-moving, litigious, and vulnerable to manipulation byMicrosoft's competitors, to say nothing of Microsoft itself.
• In analyzing the SRPFJ, I have had the benefit of reviewing a number of thoughtful and probing comments on the proposed decree. I found that most of the potential problems raised by the various commentators are, in fact, not problems at all, but are met by the SRPFJ upon careful analysis. My review of their criticisms reveals the potential loopholes that are theoretical possibilities are either unimportant, or rely on strategies that Microsoft would not have the incentive to undertake.
• In light of the above, in my opinion, the SRPFJ is in the public interest.

6. I have organized my declaration as follows: In Section II, I discuss the specific anticompetitive acts that are the focus of this inquiry and provide an overview of the proposed remedy embodied in the SRPFJ. This section also reviews the characteristics of software markets that are relevant to an economic analysis of the proposed decree. Section III presents my analysis of the SRPFJ and discusses why, in my opinion, the proposed decree meets the public interest requirement of the Tunney Act. Section IV addresses the main suggestions for additional remedy provisions discussed by various commentators. My conclusions are presented in Section V.

II. Microsoft's Unlawful Conduct and Proposed Remedy in the SRPFJ

7. Any economic analysis of the SRPFJ must have as its starting point a clear delineation of the conduct found to be unlawful. To be in the “public interest,” an antitrust remedy must stop the offending conduct, prevent its recurrence, and restore competitive conditions. The remedy presently under consideration must therefore focus attention on and fully resolve the appellate court finding that Microsoft engaged in specific anticompetitive acts to maintain its monopoly position in the market for operating systems designed to run on Intel-compatible personal computers (“PCs”).

8. To assess the remedial effectiveness of the SRPFJ, it is useful for two reasons to review the characteristics of software markets that gave rise to the Microsoft operating system (“OS”) monopoly. First, as discussed below, certain economic forces can lead naturally to dominance by a single firm, even apart from anticompetitive conduct. It was alleged, and both the District Court and the Court of Appeals agreed, that Microsoft's conduct erected artificial entry barriers on top of those that occur naturally in software markets. These artificial entry barriers were added to slow or halt the adoption of alternative technologies (known as “middleware”) that have the potential to erode Microsoft's OS monopoly. This is the conduct to be remedied, not the existence of the monopoly itself.

9. Second, there is widespread agreement that the middleware threat to the Microsoft operating system posed by the Netscape Web browser (i.e., Navigator) and the Java programming technology was a “nascent” one.^[8] While there is no question that Microsoft's conduct was aimed at eliminating that threat, there is significant uncertainty regarding when Microsoft's OS monopoly would have been substantially eroded (if at all). Thus, the appropriate remedy in this case is to restore the potential threat that middleware provides, not to eliminate natural entry barriers that are not in themselves a cause for competitive concern. This point has been overlooked by those critical of the proposed decree who argue the appropriate antitrust remedy in this case calls for the elimination of the applications barrier to entry.

A. Characteristics of Software Markets

10. In many software markets, including OS markets, there are fundamental forces that may lead to one firm being dominant at a given time and that tend to create barriers to entry. These forces have been widely discussed in the economics and computing literature. The first is the presence of scale economies. For complex software such as an OS, the initial or “first-copy” costs to writing software are often very large, whereas the incremental cost of producing additional copies is small. Hence, average cost declines as the scale of output rises. The second is increasing returns in consumption. The larger the market share of a particular OS, the more independent software vendors (“ISVs”) will tend to write applications for that OS. The more this happens, the more attractive will customers find that OS, further increasing its market share, which leads to the development of more new software applications, and so forth. Thus, increasing returns in consumption induce a series of feedback effects, which tend to make a dominant OS more dominant over time.^[9]

11. Economies of scale and increasing returns to consumption give rise to a phenomenon that lies at the heart of antitrust analysis of network industries: monopoly tipping.^[10] If a large set of users adopts a new network technology, then that technology becomes more attractive to everyone else as a result of increasing returns in consumption. As more users join, the technology becomes still more attractive until it becomes dominant; in economic terminology, the market has “tipped” to the new technology. Because users invest time and money in learning to use a given technology proficiently, for a newer technology to succeed, it would have to offer a substantial improvement in performance—i.e., enough of an improvement at least to overcome the switching costs associated with the change. In the normal course of markets and competition, such improvements do in fact occur. One example is the displacement of slide rules by pocket calculators.

12. The economic theory of network effects describes well the performance of the OS market. As an operating system gains popularity, the incentive to develop software for that operating system grows since the number of potential customers for the application developer is larger. This, in turn, increases the value of the operating system to end users (and likely its market share), which is determined by the quality and variety of software applications written for it. As the OS gains market share, software developers find it even more advantageous to produce additional applications for that system. This feedback effect explains why the number of complementary software applications and the installed base of these applications serve as natural barriers to entry, and also why alternative operating systems already in the market at a small scale are not effective competitors. This feature of software markets has become known as the applications barrier to entry.^[11]

13. Microsoft's dominant market share was a predictable consequence of the applications barrier to entry. At trial, it was documented that Microsoft's market share in each period from 1991 to 1997 held consistently at about ninety percent. Further, it was documented that Microsoft's OS dominance was stable, that it had hardly fluctuated in the face of determined attempts at entry by rival operating systems, and that it was forecast to remain stable in the future.^[12]

B. The Middleware Threat to the Microsoft OS

14. The above discussion suggests that, to enter with a product consumers would want installed on their PCs, OS vendors would have to create or induce others to create an extensive set of software applications to go with it. Alternatively, the product would have to emulate the Windows applications programming interfaces (“APIs”) needed to run existing Windows applications. APIs permit software applications running on an OS to access the basic computing functions performed by that operating system, such as opening a file, executing a print command, drawing a box, etc. The Netscape Web browser was a new class of software—called middleware—that itself exposed a broad range of APIs to which software developers could write applications. This middleware product threatened Microsoft's OS dominance because the browser could serve as a software applications platform independent of the underlying OS.^[13] Thus, a new entrant in the OS market would not have to create an installed base of software applications for its OS comparable in size and use to those of Microsoft in order to succeed. Instead, applications written to the browser platform (perhaps using the Java programming technology of Sun Microsystems, Inc. (“Sun”)) would be accessible to a user using any OS supporting that browser. Application developers would have the incentive to write to these browser APIs because their applications would then run on Windows plus the operating systems that were previously unprofitable for these ISVs to write applications. This would ultimately make it less important for users to which operating systems were installed on their computers. As Bill Gates stated: “[t]hey [Netscape] are pursuing a multi-platform strategy where they move the key [APIs] into the client [browser] to commoditize the underlying operating system.”^[14]

15. As the evidence in this case demonstrates, Microsoft engaged in specific anticompetitive actions intended to displace the Netscape browser with its own Web browser, Internet Explorer (“IE”). In particular, the commingling and contractual browser restrictions that Microsoft insisted upon in its agreements with OEMs, IAPs, ICPs, and Independent Software Vendors (“ISVs”) impeded the growth of the Netscape Web browser by adding artificial entry barriers to those that occur naturally. Such restrictions are therefore a source of competitive concern.

16. In challenging Microsoft's commingling and contractual practices, the plaintiffs' antitrust complaint alleged the following: (1) Microsoft engaged in a series of anticompetitive acts to maintain its OS monopoly; (2) Microsoft attempted to monopolize the Web browser market; (3) Microsoft illegally tied IE to its operating system; and (4) Microsoft entered into unlawful exclusive dealing arrangements. The District Court sustained claims (1) through (3). The appellate court, however, sustained only the monopoly maintenance claim, and with fewer anticompetitive actions than the District Court had found.^[15] Thus, the focus of the SRPFJ is on remedying the twelve specific anticompetitive actions the appellate court found Microsoft to have taken to maintain its OS monopoly. (See Table One.) In addition, the SRPFJ includes measures designed to enhance the ability of rival middleware vendors to interoperate with the Microsoft OS. As addressed in Sections III and IV below, many critics of the proposed decree appear to have ignored the fact that the government's case had been significantly narrowed.

Table One—Summary of Findings of Anticompetitive Acts

Anticompetitive findings of district court	Appellate court
Agreements With OEMs
1. Prohibition on OEM removing desktop icons, folders, or Start Menu entries	Yes.
2. Prohibition on OEM altering initial boot sequence	Yes.
3. Prohibition on OEM allowing alternative user interface to launch automatically	No.
4. Prohibition on OEM adding icons or folders in different size or shape	Yes.
5. Prohibition on OEM using Active Desktop to promote others' products	Yes.
Binding of IE to Windows
6. Excluding IE from the “Add/Remove” utility	Yes.
7. Designing Windows to override users' choice of default browser other than IE	No.
8. Commingling code to eliminate OEM choice of removal of IE from Windows	Yes.
Agreements With IAPs
9. Licensing IE for free	No.
10. Payment for use of IE with IAP service signup	No.
11. Developing IE Access Kits and offering them for free	No.
12. Placement of IAP's product on desktop in return for IE exclusivity (or limit to Navigator shipments)	Yes.
Agreements With ICPs, ISVs, and Apple
13. Exclusive agreements with ICPs	No.
14. Agreements With ISVs to make IE the default hypertext interface	Yes.
15. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OS	Yes.
Efforts To Contain and Subvert Java
16. Design of Java Virtual Machine (“JVM”) that was incompatible with Sun's product	No.
17. Exclusive agreements to promote Microsoft's JVM	Yes.
18. Deceived Java developers about Windows-specific nature in Microsoft Java	Yes.
19. Coerced Intel to stop aiding Sun by threats to support Advanced Micro Devices, Inc. (“AMD”)	Yes.
Course of Conduct
20. Apart from specific acts, Microsoft's general course of conduct violated Section 2 of the Sherman Act	No.

C. Summary of SRPFJ Provisions

17. Given the appellate court findings, the SRPFJ focus is appropriately on middleware. Each of the twelve anticompetitive acts were directed toward eliminating the middleware threat to the Microsoft OS. However, by its nature, the proposed decree must be forward looking, and this requirement imposes challenges as to how middleware should be defined. As the appellate court noted, “[s]ix years has passed since Microsoft engaged in the first conduct plaintiffs alleged to be anticompetitive. And as the record in this case indicates, six years seems like an eternity in the computer industry.”^[16] The anticompetitive actions taken by Microsoft targeted the middleware threat posed by the Netscape Web browser and Java.^[17] However, there is general agreement that Microsoft has won the “browser war.” Relief focusing only on this threat is thus likely to be ineffective. Moreover, the characteristics of middleware products today focus not on access to the Internet but on the range of offerings that access to the Internet can provide. Thus, middleware is properly defined in the proposed decree to encompass present and future middleware threats. In particular, middleware is broadly defined in the SRPFJ to capture almost any software that exposes a range of APIs. For example, as defined, middleware captures Internet browsers, email client software, networked audio/video client software, and instant messaging software.

18. As shown in Table Two, to stop the unlawful conduct found by the appellate court, the SRPFJ targets Microsoft's business practices by broadly banning exclusive dealing, providing OEMs more control of the desktop and initial boot sequences, and prohibiting retaliatory conduct by Microsoft. The remedy for preventing recurrence of that conduct consists of provisions for non-discrimination and non-retaliation. With regard to lost competition, the SRPFJ seeks to restore the potential middleware threat. This is to be accomplished primarily through provisions requiring API disclosure and the licensing of communication protocols embedded in the OS. This will enable independent software developers to more effectively interoperate with Windows and thus compete with the middleware functionality offered by Microsoft. Middleware developers are also aided by (1) the requirement that Microsoft create and preserve default settings when Windows launches or invokes rival middleware in certain cases, and (2) the requirement that Microsoft create “add/delete” functionality that makes it easier for OEMs and users to replace end-user access to Microsoft Middleware functionality with rival middleware.

Table Two—Summary of SRPFJ Provisions

Provision	Section in SRPFJ
Remedy To Stop Offending Conduct
Prohibits retaliatory conduct	III.A.1-3, III.F.1
Broadly bans exclusive dealing	II.F.2, III.G.1-2
Provides OEMs more control of desktop and initial boot sequence	III.C.1-6
Remedy To Prevent Recurrence
Non-discrimination and non-retaliation provisions	III.A.1-3,
Remedy To Restore Competitive Conditions
If Microsoft middleware products rely on an API, then that API must be disclosed	III.D, III.I
Microsoft required to create and preserve default settings, such that certain of	III.H.2
Microsoft required to create add/delete functionality that makes it easier for OEMs	III.H.1
Microsoft required to license communications protocols embedded in the OS, but	III.E, III.I

19. The difficult task is to create a balanced remedy that constrains anticompetitive behavior by Microsoft without limiting competition on the merits. Thus, in developing an antitrust remedy in this case, it is necessary to balance two broad factors: (1) the need to impose constraints on Microsoft's current and future behavior so that the unlawful business practices stop and do not recur, and competitive conditions are restored and (2) the requirement that these constraints not be so intrusive and complex that they themselves distort market outcomes.

20. By focusing on Microsoft's anticompetitive business practices, the provisions in the SRPFJ eliminate the artificial barriers to entry erected by Microsoft that are the source of competitive concern. The provisions in the proposed decree aim to deter conduct that (1) seeks exclusivity or (2) is backed by retaliatory threats. The SRPFJ also aims to restore and enhance competitive conditions by removing technical barriers to competition between Microsoft and rival middleware suppliers. As discussed above, from an economic standpoint, middleware is important because it can expose APIs and has the potential to become an applications platform distinct from the Windows OS.

21. At the same time, the SRPFJ does not attempt to preordain market outcomes or to weaken Microsoft as a legitimate competitor. Overly broad remedies can create socially wasteful costs by eliminating efficiencies, and remedies designed to “manage” the competitive process can indirectly reduce consumer welfare. In particular, over-extensive government regulation of Microsoft may result in inefficient rent-seeking by Microsoft's competitors,^[18] and make Microsoft a less efficient competitor. As discussed below, in my opinion, the SRPFJ achieves the right balance.

III. Economic Analysis of the SRPFJ in Light of the Tunney Act Requirements

22. It is my understanding that key components of the public interest standard of the Tunney Act are satisfied when the antitrust remedy is sufficient to (1) stop the offending conduct, (2) prevent its recurrence, and (3) restore competitive conditions. In this section, I examine the extent to which the SRPFJ satisfies this three-part test. In so doing, I respond to many of the thoughtful comments on the proposed decree that were submitted during the public comment period recently concluded.

A. Does the SRPFJ Stop the Offending Conduct?

23. To answer this question it is first necessary to review both the specific acts of Microsoft that were held to be anticompetitive and the linkage between those acts and the provisions in the SRPFJ. Table Three identifies the twenty specific acts related to the monopoly maintenance claim that were found to be anticompetitive by the District Court and the twelve claims upheld by the appellate court. The right-hand column of Table Three presents the provisions in the SRPFJ that I believe likely would effectively prevent those acts from occurring. I begin my analysis by examining the acts of Microsoft found to be unlawful by the appellate court.

24. Prohibition on OEM removing desktop icons, shortcuts, or Start Menu entries. If the SRPFJ had been in effect when Microsoft imposed this requirement on OEMs, Microsoft would have been in violation of Section III.H.1.a of the proposed decree. This section of the SRPFJ specifically allows either end users or OEMs to enable or remove access to each Middleware Product by displaying or removing icons, shortcuts, or menu entries anywhere in a Windows Operating System Product that a list of icons, shortcuts, or menu entries is normally displayed. According to the SRPFJ, the mechanism that accomplishes this task must be readily accessible from the desktop or the Start Menu entries, and it must be available to OEMs using standard pre-installation kits.

Table Three—Provisions in SRPFJ That Address Anticompetitive Acts

Anticompetitive findings of District Court	Appellate	Addressed in
Agreements With OEMs
1. Prohibition on OEM removing desktop icons, folders, or Start	Yes	III.H.1
2. Prohibition on OEM altering initial boot sequence.	Yes	III.C.3-5
3. Prohibition on OEM allowing alternative user interface to	No
4. Prohibition on OEM adding icons or folders in different size or	Yes	III.C.1-2
5. Prohibition on OEM using Active Desktop to promote others'	Yes	III.C.1-2
Binding of IE to Windows
6. Excluding IE from the “Add/Remove” utility	Yes	III.H.1
7. Designing Windows to override users' choice of default	No	III.H.2
8. Commingling code to eliminate OEM choice of removal of IE	Yes	III.C.1
Agreements with IAPs
9. Licensing IE for free	No
10. Payment for use of IE with IAP service signup	No
11. Developing IE Access Kits and offering them for free	No
12. Placement of IAP's product on desktop in return for IE Exclusivity (or limit to Navigator shipments)	Yes	III.G.1-2
Agreements With ICPs, ISVs, and Apple
13. Exclusive agreements with ICPs	No	III.G.1-2
14. Agreements with ISVs to make IE the default hypertext user	Yes	III.F.2
15. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OS	Yes	III.F.1-2 III.G.1
Efforts To Contain and Subvert Java
16. Design of Java Virtual Machine (“JVM”) that was	No
17. Exclusive agreements to promote Microsoft's JVM	Yes	III.F.2
18. Deceived Java developers about Windows-specific nature in	Yes	III.D
19. Coerced Intel to stop aiding Sun by threats to support AMD	Yes
Course of Conduct
20. Apart from specific acts, Microsoft's general course of conduct violated Section 2 of the Sherman Act	No

25. Prohibition on OEM altering the initial boot sequence. This Microsoft prohibition would have violated Sections III.C.3-5 of the proposed decree. These sections require that OEMs be allowed to alter the initial boot sequence in certain ways to promote rival middleware. Section III.C.3 allows OEMs to launch rival middleware in place of a Microsoft Middleware Product at the end of the initial boot sequence. Section III.C.4 allows OEMs to offer machines that dual boot to two different operating systems. Section III.C.5 allows OEMs to present Internet access offers which may promote rival software.

26. Prohibition on OEM adding icons or folders in different size or shape. Microsoft began to impose this restriction, which was intended to prevent OEMs from pre-installing Netscape Navigator, in its first Windows 95 contracts. Under the proposed decree, the only restrictions that Microsoft would now be able to place on the icons, shortcuts, and menu entries placed by an OEM are those described in Section III.C.1-2. These sections state that Microsoft can restrict the OEM from placing such icons, shortcuts, and menu entries in any list in Windows that is described in the Windows documentation as being for particular types of functions. These provisions would, however, apply also to Microsoft's own placement of icons, menu entries, and shortcuts and do not restrict the OEM from choosing the size and shape of its shortcuts.^[19]

27. I note that Section III.H.3 of the SRPFJ is also relevant with regard to Microsoft's prohibition against the addition of OEM-specified icons, shortcuts, and menu entries. This section states that Microsoft cannot alter an OEM's desktop configuration of icons, etc. without end-user actions, and, in any case, it cannot even ask the user to undertake such action for fourteen days after the initial boot. Based on my reading of the Competitive Impact Statement (which serves as an explanation of SRPFJ provisions) and on conversations with personnel from the DOJ, the only existing Microsoft technology to which this section refers is the Desktop Cleanup Wizard, which currently exists only on Windows XP. The Desktop Cleanup Wizard simply asks the end user if he or she wants to retain infrequently-used icons on the desktop, whether or not these icons refer to rival software. The SRPFJ requires that it treat Microsoft and Non-Microsoft icons in an unbiased manner.

28. Prohibition on OEMs using Active Desktop to promote others' products. It is my understanding that this prohibition is no longer a relevant concern because the Active Desktop is no longer significantly in use. Indeed, I note that the Microsoft pre-installation kit for Windows XP instructs the OEM not to activate the Active Desktop. However, should features similar to the Active Desktop exist in the future, Sections III.C.1-2 would prevent similar types of restrictions by providing OEMs more control and flexibility over the desktop.

29. Exclusion of Internet Explorer from the “Add/Remove” utility. This violation would clearly have been prevented by Section III.H.1 of the proposed decree. Section III.H.1 requires Microsoft to allow the removal of the means of access to Microsoft Middleware Products.

30. Commingling of code to eliminate OEM choice of removal of IE from Windows. This offense is addressed by Sections III.H.1 and III.C.1 of the proposed decree. Section III.H.1 requires Microsoft to allow the removal of the means of end-user access to Microsoft Middleware Products, which would include IE. Section III.C.1 allows the OEM to install and display icons, shortcuts, and menu entries that facilitate easy end-user access to middleware offered by Microsoft rivals. From the standpoint of most end-users, a software product, such as a browser, has been removed and is not present if there are no visible means to access it. Accordingly, Section III.C.1 and III.H.1 together enable the OEM or end user to select another browser as the default browser, without IE being visible to the end user. I do not interpret the appellate court decision as requiring that code internal to Windows be removed without regard to the competitive significance of its removal merely because it is also used in Web browsing. The appellate court stated that such removal of code would be needed if such removal was required to permit OEMs to remove the means of access to Microsoft products, since their inability to do so resulted in the exclusion of rival products. Thus, because the SRPFJ requires Microsoft to make it possible for OEMs effectively to remove Microsoft Middleware Products by removing access to them and to install rival products, the actual removal of code is not necessary.

31. Placement of an IAP's product on the desktop in return for IE exclusivity (or limit to Navigator shipments). This offense would have been prevented by Sections III.G.1 and III.G.2 of the proposed decree. With one exception, these sections prevent Microsoft from entering into an agreement with any IAP, ICP, ISV, independent hardware vendor (“IHV”), or OEM requiring either exclusivity for a Microsoft Middleware product or that such software be distributed in a fixed percentage, irrespective of consumer choice. The exception is that fixed percentage agreements that provide Microsoft preferential status are permitted under the SRPFJ as long as it is commercially feasible for the OEM, IAP, etc. to give equivalent treatment to rival middleware. When preferential status for Microsoft necessarily excludes rival middleware, Section III.G.1 implies thatpreferential status from Microsoft cannot extend to more than fifty percent of the shipments of the OEM, IAP, etc. Also, Microsoft cannot grant an IAP or ICP placement on the desktop or any other favored place in Windows in return for the IAP or ICP refraining from distributing, promoting, or using any software that competes with Microsoft Middleware.

32. Agreements with ISVs to make IE the default hypertext user interface. Such exclusive agreements are ruled out by Sections III.F.2, and III.G.1. Section III.F.2 prevents Microsoft from rewarding ISVs for refraining from developing, promoting, or using software that competes with Microsoft middleware and operating systems. Provision III.G.1 prohibits Microsoft from entering into agreements which give Microsoft preferential status (e.g., fixed percentage agreements) when an ISV or IHV is unable to offer an equivalent status to a rival product. Fixed percentage agreements are permissible, however, when it is commercially feasible for the other party to the agreement to provide at least the same level of promotion to the rival middleware.

33. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OS. For the purpose of the SRPFJ, Apple is considered an ISV. One of the historical incidents involving Microsoft and Apple was that Microsoft threatened to end the support of Office on the MAC platform if Apple continued to promote Netscape's Web browser. Section III.F.1 forbids retaliation of the kind Microsoft threatened. This restriction would have rendered the threat itself ineffective. Microsoft also signed an agreement with Apple which ported Office to the MAC and made IE the default browser and relegated Netscape's browser to a folder. This agreement would have violated Section III.F.2 because it represented consideration in return for Apple's refraining from promoting the Netscape browser. Finally, because Apple could not have made both IE and Navigator the default browser on the MAC, the agreement would have violated Section III.G.1.

34. Exclusive agreements to promote Microsoft's JVM. These agreements between Microsoft and ISVs gave those ISVs advance information on new Microsoft APIs in return for writing to the Microsoft version of the Java Virtual Machine (“JVM”). Section III.F.2 would have prevented Microsoft from offering the ISV consideration, in the form of advance information, in return for promoting the Microsoft JVM over the Sun JVM. Section III.G.1 would also block such a transaction since the ISVs were being asked to promote the Microsoft JVM exclusively.

35. Deception of Java developers regarding the Windows-specific nature of Microsoft Java. To the extent that such deceit on the part of Microsoft involved the disclosure of additional APIs developed by Microsoft for its JVM that worked only on Windows, this behavior would have been blocked by the API disclosure requirement of Section III.D. However, I see nothing in the SRPFJ that speaks directly to the issue of deceit.

36. Coerced Intel to stop aiding Sun by threats of support to AMD. Microsoft's interaction with Intel in this regard contained a threat. Section III.F.1 forbids retaliation against an IHV, so that had the SRPFJ been available at the time, the threat of retaliation would have been without force. Section III.F.2 would have been invoked by the Microsoft offer of consideration, which essentially took the form of increased support for Intel's microprocessors. Thus, this conduct would have been prevented by the SRPFJ.

37. In addition to likely preventing the anticompetitive acts upheld as illegal by the appellate court, the SRPFJ also provides at least partial protection with regard to two Microsoft behaviors found to be unlawful by the District Court but not upheld as such on appeal. (See Table One, items 7, and 13.) In this regard, the SRPFJ addresses actions that go beyond the violations upheld by the appellate court.

38. Designing Windows to override a user's choice of default browser other than IE. Section III.H provides partial protection against this act. To restore this access would take positive action by the end user and could not be initiated and completed by Microsoft otherwise. Section III.H.2 allows end users and OEMs to select a Non-Microsoft Middleware Product to be launched automatically whenever the Microsoft Middleware would have been launched in a Top-Level Window and have displayed either all of the user interface elements or the trademark of the Microsoft Middleware Product.^[20] This requirement forces Microsoft to have default in some circumstances and provides a “bright line” rule in a situation where previously Microsoft had complete discretion.

39. Exclusive agreements with ICPs. Although the appellate court did not find these agreements to be unlawful, Section III.G.1 of the proposed settlement prevents exclusive and “fixed percentage” agreements for Microsoft Middleware products with ICPs. In addition, Section III.G.2 outlaws an exchange of placement of the ICP's icon on the desktop for the ICP refraining from using, distributing, or promoting middleware offered by Microsoft's rivals.

40. Based on the above analysis, I conclude that the SRPFJ is likely to stop effectively the Microsoft conduct found to be unlawful by the appellate court. The proposed decree also is likely to address two areas that were originally found to be unlawful by the District Court but reversed on appeal.

B. Does the SRPFJ Prevent Recurrence of the Offending Conduct?

41. In addition to preventing the recurrence of acts similar to those that occurred in the past, the SRPFJ contains provisions to guard against future acts that differ substantially from those listed in Table Three but would also be anticompetitive. The SRPFJ identifies non-Microsoft products whose distribution and usage cannot be impeded by Microsoft's actions. Covered products, such as Microsoft Middleware Products, are described in terms of their general functionalities and not just with reference to specific products now commercially available.

42. In particular, “Microsoft Middleware Product” is broadly defined in the decree to cover the functionality provided by Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express, as well as their successors. In addition, new and yet-undreamed-of products in the general categories of Internet browsers, email client software, networked client audio/video client software, and instant messaging software are also covered. The SRPFJ also covers any new Microsoft Middleware distributed separately from a Windows Operating System Product that is similar to the functionality of a rival middleware product and is either trademarked or distributed by Microsoft as a major version of a Microsoft Middleware Product. In this last category, the new Microsoft Middleware Product need not even be something currently recognized as middleware. This definition is not perfectly general, and it is possible to imagine future Microsoft products that would not fall under this definition but nevertheless would still compete with rival middleware. However, the middleware definition does appear broad enough to capture the types ofmiddleware threats most likely to emerge during the term of the proposed decree. Similarly, provisions in the proposed decree regarding non-discrimination and non-retaliation (i.e., Sections III.A, III.B, and III.F) are broad and go beyond the specific acts found to be unlawful by the appellate court.

43. During the effective period of the decree, the Technical Committee and other compliance and enforcement measures set out in the SRPFJ should work to prevent a recurrence of the offending acts. However, before reaching a conclusion about the SRPFJ's compliance with this part of the Tunney Act's requirements, there remains the issue of possible “loopholes” and “overly-broad exclusions,” which was commented upon in many thoughtful submissions provided during the public comment period just concluded. I will discuss below those comments pertaining to provisions in the SRPFJ that are intended to prevent recurrence of acts such as those described at trial, in the general areas of retaliation and exclusive dealing. (Potential loopholes in the general area of disclosure of APIs and other technical interfaces are discussed in Section III.C of this document.)

44. Claimed Loopholes. The SRPFJ contains various provisions (Sections III.A and III.F) that protect parties from retaliation by Microsoft in those cases involving a middleware product that competes with a Microsoft Middleware Product and operating system. These provisions do not address explicitly the possibility that Microsoft may have a competitive concern involving rival middleware that has no counterpart at present among Microsoft's suite of middleware products. In this situation, Microsoft might retaliate against an OEM, ISV, or IHV that supported the product in question, perhaps to prevent it from ever becoming a serious threat to its OS monopoly. However, there are several reasons why this is unlikely to occur.

45. First, this action would be blocked by Section III.A.1, which forbids Microsoft from retaliating against an OEM supporting, or contemplating supporting, any rival software that competes with Microsoft Platform Software whether or not Microsoft has a counterpart to the rival software. Section III.F.1 contains similar protection for ISVs and IHVs. While it is not possible at first glance to rule out the occurrence of such an event, further analysis suggests that such an event is unlikely to occur. This is because as discussed in Section II above, Microsoft's strength is derived from having an operating system that runs many applications, and, in the past, Microsoft has consistently supported applications that do not compete with its own applications. The Microsoft Software Developer's Network and the many developer seminars that Microsoft sponsors are evidence in support of this position. Second, if Microsoft were to adopt this strategy, the strategy itself would impose a cost on Microsoft in that the company would have to refrain from developing its own version of the threatening software. This would encourage other, non-Microsoft developers to produce another version of the competing product and end-users to use the non-Microsoft middleware product. Also, there remains the issue of exactly how Microsoft would retaliate and against whom.

46. Previously, Microsoft has retaliated against OEMs by charging uncooperative OEMs a higher price for Windows. However, this form of retaliation is ruled out by Section III.B, which requires that OEMs pay royalties pursuant to uniform license agreements that can be viewed by other OEMs and by the plaintiffs for monitoring purposes. If retaliation were to take the form of manipulation of other types of consideration (e.g., MDA discounts), such action would make it impossible for Microsoft to comply with Section III.B.3.a of the proposed decree, which states that such discounts must be offered to all covered OEMs, including OEMs that cooperate with Microsoft.

47. Based on Microsoft's past practices, Microsoft might withhold APIs, documentation, or access to communications and security protocols. Such behavior is likely to be an ineffective means of retaliation or control. There are thousands of published APIs, and the very existence of a Non-Microsoft Middleware Product that prompts retaliation implies such a product was built around published APIs and technologies, in addition to whatever its developer may have invented and embodied in the product. Attempting to manipulate these APIs would invariably harm products that are complementary to the Microsoft OS and enhance its value. For all these reasons, I believe that Microsoft's incentives would be not to retaliate against an ISV regarding a product without a Microsoft counterpart. In my opinion, reliance on incentives will be superior, in this instance, to detailed regulation.

48. A second possible loophole is that Microsoft could provide special treatment or discriminatory prices on other (non-middleware) products as rewards or retaliation, presumably for a third party's favoring or impeding a Non-Microsoft Middleware product. (See Declaration of Joseph Stiglitz and Jason Furman, hereafter “Stiglitz and Furman Decl.” at 31, and Declaration of Kenneth J. Arrow, hereinafter “Arrow Decl.,” at ¶ 41.) Regarding special treatment, I note that if such treatment refers to non-monetary consideration of some kind, this behavior would be ruled out by Section III.A.1 of the proposed decree. This section of the SRPFJ prohibits Microsoft from retaliating against or withholding newly developed forms of non-monetary compensation from an OEM because the OEM is developing, promoting, or using software that competes with Microsoft Platform Software.

49. I also consider the possibility that special treatment might take the form of monetary discounts on other Microsoft products, such as Microsoft Office. I will assume that the alleged discrimination takes the form of requiring the OEM to establish the Microsoft Middleware Product as the default on all of its computers. This action violates Section III.A.1 and III.A.3 because linking the price of Office to an OEM's promotion of rival middleware would represent an alteration in Microsoft's commercial relationship with that OEM in connection with that OEM's promotion of rival middleware, and the withholding of such a discount would occur because it was known to Microsoft that the OEM was exercising options provided for by Section III.H (e.g., making rival middleware the default). Furthermore, this would be a case of preferential treatment within the meaning of Section III.G. Since only one middleware product in a given category can by definition be the default on a given computer, the OEM could not represent that it was commercially feasible for it to give greater or equal distribution to the Non-Microsoft Middleware Product.

50. The third loophole cited in the comments pertains to Section III.A and the process that governs how Microsoft must proceed if it wants to terminate dealings with an OEM. In the past, Microsoft has had the ability to cancel an OEM's Windows license without prior notice. The SRPFJ adds constraints to Microsoft's ability to terminate an OEM. The SRPFJ requires that Microsoft provide any one of the top twenty OEMs (defined by volume) written notice of its intent to cancel, in which it must specify the deficiency prompting the cancellation, as well as a 30-day opportunity to cure the deficiency. Because Microsoft must provide a reason in the written notice and an opportunity for a cure, it obviously cannot terminate an OEM for conductauthorized under the SRPFJ. Again, Microsoft does not have to do this currently. Because Microsoft cannot terminate an OEM's license for conduct consistent with the SRPFJ, the presumption is that, if an OEM is terminated, the cause must be related to a normal commercial dispute. Viewed in this light, I do not agree with Stiglitz and Furman when they allege that Section III.A provides Microsoft “substantial leverage” to force an OEM to distort its choice among competing middleware products. (See Stiglitz and Furman Decl. at 31-32.) I do not believe that detailed regulation would achieve a better outcome.

51. This discussion has summarized the major comments on the SRPFJ Sections III.A, III.B, and III.F as they relate to retaliation and discrimination. On balance, I conclude that these provisions are likely to fulfill the Tunney Act requirement that the SRPFJ prevent a recurrence of the offending conduct.

C. Will the SRPFJ Restore Competitive Conditions?

52. As discussed above, the SRPFJ's focus is on restoring the competitive threat provided by middleware (see Table Two). This is accomplished by providing middleware developers the means to create competitive products through: (1) provisions for API disclosure; (2) provisions that require Microsoft to create and preserve default settings, such that Microsoft's integrated middleware functions will not be able to over-ride the selection of third-party middleware; (3) the creation of “add/delete” functionality that make it easier for OEMs and end-users to replace Microsoft middleware functionality with independently developed middleware; and (4) requirements for Microsoft to license communications protocols embedded in the OS while maintaining Microsoft's ability to deploy proprietary technology provided separately. These provisions are discussed more fully below.

53. The SRPFJ requires Microsoft to release certain types of technical information to rival middleware suppliers. This information is to be provided in order to enable rival software developers to configure their products so that they are able to use the same Windows capabilities that Microsoft Middleware uses. To better evaluate these provisions, recall from above that Microsoft has published thousands of APIs, which are used by software developers to allow their products to run on Windows. Microsoft rivals (e.g., RealNetworks) use those APIs to build products to run on Windows and compete with Microsoft products. Microsoft has many more APIs that it does not publish or otherwise make available to ISVs. Potentially, some of these unpublished APIs give Microsoft products capabilities or features that rival products cannot easily duplicate. When these APIs are used by Microsoft Middleware Products, the SRPFJ obliges Microsoft to disclose them to ISVs, IHVs, IAPs, ICPs, and OEMs meeting certain requirements. The same obligation applies to certain types of communications protocols and security features developed by Microsoft that are used in connection with its Window Operating System products. The sections of the SRPFJ dealing with technical disclosure are III.D, III.E, III.I, and III.J.

54. The API disclosure provisions of the SRPFJ have attracted perhaps more comments than any others in the proposed decree. Criticisms of these provisions generally follow two lines of argument: (1) The proposed decree provides too much latitude, enabling Microsoft to delay the release of APIs until a Microsoft product has a decisive first-mover advantage over the competition; and (2) Microsoft could evade the intent of the proposed decree and avoid releasing this information at all. I will first describe the relevant sections of the SRPFJ dealing with the API disclosure provisions and then evaluate their likely effectiveness.

1. API Disclosure and Communications Protocol Provisions

55. Section III.D of the proposed decree specifies the main process for releasing the APIs and the documentation used by Microsoft Middleware to interoperate with Windows. Starting with the release of Service Pack 1 for Windows XP or twelve months after the submission of the SRPFJ to the Court (whichever is earlier), Microsoft must disclose APIs and documentation used in association with Microsoft Middleware. Going forward, there are to be disclosures occurring in a “Timely Manner” whenever there is a new version of a Windows operating system product or a new major version of Microsoft Middleware.^[21]

56. Section III.E pertains to the use of Microsoft's client-server communications protocols. It does not apply to the use of communications protocols between other types of Microsoft products. The basis for the client-server focus is that there is now a growing number of applications that run on servers, rather than on the desktop. I discussed this factor in my May 1998 Declaration.^[22] It represents a strong source of competition to Microsoft in the business computing segment and may yet make a serious attack on the applications barrier to entry in the desktop PC market. Therefore, it is important that rival middleware be able to operate with Microsoft server operating systems. It is equally important that a non-Microsoft server be able to operate with Windows as efficiently as would a Microsoft server. Communications protocols are essential for that purpose and are just as necessary to rival middleware developers as is access to Windows APIs. By contrast, I have not yet seen an argument that clearly articulates why the applications barrier to entry would be threatened by the disclosure by Microsoft of communications between other types of Microsoft software.

57. Under Section III.E, starting nine months after the submission of the SRPFJ to the Court, Microsoft shall make available to qualifying third parties any communications protocol implemented in a Windows Operating System Product (on or after the date of SRPFJ submission), installed on a client and used to interoperate or communicate with a Microsoft server operating system product. This will have both of the effects discussed above. It will enable rival middleware to communicate with a Microsoft server and also will allow a non-Microsoft server operating system to communicate effectively with a Windows operating system. To protect Microsoft intellectual property rights, Microsoft may charge for the use of these protocols as long as it does so on “reasonable and non-discriminatory terms.” (See SRPFJ at Section III.E.) Section III.E also references Section III.I, which says that Microsoft must offer to license any intellectual property that it owns and that is needed to allow ISVs, IHVs, IAPs, ICPs, or OEMs to exercise their rights under the SRPFJ. The SRPFJ also states that all terms governing payment must be reasonable and non-discriminatory.

58. Section III.J can be viewed as “carving out” exceptions to Section III.D and III.E. Section III.J.1 states that Microsoft cannot be required to disclose portions of APIs, documentation, or portions of communications protocols if disclosure would “compromise the security of a particular installation orgroup of installations” in the general areas of anti-piracy, anti-virus, software licensing, digital rights, encryption, or authentication systems, “including, without limitation, keys, authorization tokens or enforcement criteria.” (See SRPFJ at Section III.J.1.) Section III.J.2 similarly allows Microsoft to condition the licensing of any API, documentation, or communications protocol relating to anti-piracy, anti-virus, license enforcement mechanisms, authentication/authorization security, or third party IP protection. Microsoft may require that a licensee: (a) have no history of software piracy, counterfeiting, etc.; (b) have a “reasonable business need” for the API, documentation, or communications protocol for a planned or shipped product; (c) meets “reasonable, objective standards” established by Microsoft for certifying the authenticity and viability of its business; and (d) agrees to have a third party verify that its product complies with the technical specifications for whatever Microsoft APIs or interfaces it may use.

59. Before evaluating these sections of the SRPFJ, one observation is in order. The API disclosure required under Section III.D is triggered by the existence of Microsoft Middleware, meaning that a version of a Microsoft Middleware Product is distributed apart from the operating system. Thus, if Microsoft bundles a piece of middleware with the operating system and does not distribute this middleware in some other way (e.g., by download), then Microsoft need not disclose the APIs used by that piece of middleware. There is a current example of this situation: Windows Media Player version 8.0 is available only with Windows XP. Therefore, Microsoft under the SRPFJ does not have to disclose the APIs applicable to Windows Media Player version 8.0. However, as discussed below, it would be impractical for Microsoft to affect competition in this way.

2. Comments Regarding API Disclosure and Communications Protocol Provisions

60. This group of decree provisions attracted a large number of thoughtful comments. Rather than address all of the commentators, I will discuss the major comments which tend to recur in the various submissions. As noted above, a potential loophole in the SRPFJ is that Microsoft's disclosure obligations only begin when it distributes a piece of middleware separately from the operating system. If Microsoft chooses to bundle this product and does not create a redistributable version, the APIs used by that product need not be disclosed. (See Stiglitz and Furman Decl. at 29-30, and Comment of Rebecca M. Henderson (hereinafter “Henderson Comment”) at 5-6, and 9, and Comments of Software Information Industry Association at 26.) In theory, this feature of the SRPFJ could allow Microsoft to avoid disclosing APIs on new products and major new versions of current products.

61. In my opinion, this concern has little practical significance. If Microsoft were to follow such a strategy as a matter of broad policy to deter competition, it would come at a high price. First, none of the installed base of Windows users would have the new product, which alone would impose a large cost on Microsoft, if the product's use were at all competitively significant, as was the case in 1995 with the browser. Second, since competing providers would continue to innovate, as RealNetworks has done, at some point Microsoft would face the danger (since most users tend not to replace their operating system readily) that the Windows user's best option becomes obtaining the relevant piece of middleware from Microsoft's competition. Had Microsoft refrained from any separate distribution of IE in 1995, the effect would have been to solidify Netscape's hold on the browser market. Third, this problem is substantive only if the bundled Microsoft product uses an API that is not published. Even then, there are thousands of published APIs to which competing ISVs can and do write. RealNetworks, for example, has always written to these publicly available APIs, unless it could persuade Microsoft to produce or reveal a particular proprietary API. Based on the comments submitted by RealNetworks in this proceeding, its main API concern is not over unpublished APIs that only Windows Media Player 8.0 may use (if any), but about the Secure Audio Path API, sometimes called SAP. This API is used by a previous version of Windows Media Player that was distributed separately from the operating system, so Microsoft will have to disclose SAP under the SRPFJ. For these reasons, I do not believe that the ability of Microsoft to withhold API disclosure by a bundling-only strategy is likely to lead to significant competitive harm.

62. The definition of “Non-Microsoft Middleware Product” has also been criticized because of the requirement that the middleware product have had at least one million copies distributed in the previous year. For example, RealNetworks objected to this as “a huge number of copies . . . that will take a great deal of time, money and resources for most middleware companies to reach.” (See Comments of RealNetworks, at 13, and Comments of SBC at 40-41.) The comments of RealNetworks also note that the above definition of “Non-Microsoft Middleware Product” does not state whether new versions are to be counted separately. My understanding is that the word “product” refers for this purpose to an aggregation of versions. Thus, if in the course of a single year, version 1 of a product had 200,000 copies distributed, version 2 had 300,000 copies distributed, and version 3 had 500,000 copies distributed, it is my understanding that the product would qualify. Furthermore, the term “distributed” should not be confused with “sold.” Under my reading of the proposed decree, mass mailings of CDs (i.e., so-called “carpet-bombing”) would constitute distribution for this purpose, as would “downloads.” While one million distributed copies might have been significant in the early stages of the Internet, the recent explosive growth in the Internet and its use suggests that this requirement can be easily met by most, if not all, middleware vendors.^[23]

63. It has been argued that the requirement that the million copy threshold must have been reached in the previous year is a further impediment, leading to the result that the “entrepreneur will begin to gain some of the settlement rights only a year after the widespread distribution of her product. She will be entitled to information about how this new product can interact with Windows only after Microsoft has imitated the innovation.”^[24] However, based on my reading of the SRPFJ, this concern is misplaced. The million copy requirement only comes into play in Section III.H, which is the only section in which the term “Non-Microsoft Middleware Product” is used. This section is solely concerned with the ability of the end user or OEM to have a Non-Microsoft Middleware Product launch automatically or be featured on the desktop. That is, it has nothing to do with the API disclosure requirement. Furthermore, it is my understanding that, once a particular Non-Microsoft Middleware Product meets the millioncopy requirement and Microsoft has created a default setting, an OEM will be able to set as the default a competing product by another vendor, even if that competing product has not yet met the one million copy requirement. Thus, when RealNetworks asks, “Must [middleware distributors] accumulate one million distributions . . . before they are protected?”, it betrays a misunderstanding of this section of the proposed decree.^[25]

64. The proposed release schedule for APIs and documentation has also attracted criticism. (See, e.g., Bresnahan Article at 69; and Stiglitz and Furman Decl. at 30.) The requirement in Section III.D is that, once the initial disclosure for Windows XP has taken place, Microsoft must disclose new APIs no later than the date of the last major beta release, if the disclosures are triggered by new Microsoft middleware, or in a “Timely Manner,” if the disclosure is triggered by a new Windows operating system product.^[26] Whether this is too long a period of time or not appears to depend on the case at hand. For an API to be published by Microsoft, it must first be “hardened,” which means that it must undergo an extensive testing procedure to make sure that it works in different programming environments and in the hands of developers who may not use it in the same way that Microsoft does. If an API has been developed for a Microsoft Middleware Product and has not been hardened, it may well take some period of time before it can usefully be disclosed to ISVs and others. On the other hand, if that Microsoft Middleware Product uses APIs that have been published or that have been hardened, then the process would likely be much shorter. Thus, the appropriate disclosure period would depend on the case at hand, and my own expertise as an economist does not qualify me to opine further. I note, however, that alternatives to the SRPFJ on this matter do not appear to represent a clear improvement. For example, one alternative would be for Microsoft to disclose APIs tentatively at an earlier stage, subject to the understanding that further testing might cause Microsoft to change them. In this case, a software developer, OEM or other party that uses Microsoft APIs may have earlier access to them but may well feel reluctant to make extensive use of a very preliminary list of APIs, knowing that Microsoft may make changes at a later date. From Microsoft's standpoint, to release APIs that are only preliminary could pose legitimate risks. If Microsoft were to release a tentative new API at the alpha testing stage and were to change the API at a later date, even a Microsoft disclaimer could leave Microsoft open to charges that it was changing APIs throughout the testing process in order to deceive and manipulate. Indeed, the disclaimer would almost indemnify Microsoft for such manipulation. Its precise reasons for changing the API would then lead to litigation. For these reasons, it is unclear that preliminary, earlier disclosure is an obvious improvement to the provisions currently embodied in the SRPFJ. Indeed, it would probably extend regulation into the testing process, which seems likely to reduce and distort innovation in APIs.

65. Other features of the proposed API disclosure process that have drawn comment include the limitations contained in Section III.J. For example, Professor Bresnahan states that the settlement “overbroadly exempts the most competitively important protocols such as security, authentication and identity protocols.” (Bresnahan Article at 68.) The same concern is expressed by Stiglitz and Furman. (See Stiglitz and Furman Decl. at 30.) These fears are unfounded, based on my understanding of the SRPFJ. In particular, I observe that Section III.J.1 exempts from disclosure portions or layers of APIs, documentation, and protocols that, if disclosed, would compromise the security of a particular actual installation. The exemption, as described in the CIS, “is limited to specific end-user implementations of security items such as keys, authorization tokens or enforcement criteria.” (See CIS at 51.) That is, the SRPFJ only limits disclosure of specific end-user implementation of security features. For example, Microsoft would not have to disclose the actual key used by an actual customer. It would not need to disclose an API written especially for an actual customer, and no other. These limits appear reasonable. APIs relating to general Microsoft technologies for security, etc. must be disclosed.

66. Apart from the disclosure of APIs, there is also the issue of the disclosure of the communications protocols between Windows installed on a client and a Microsoft server. Several commentators are of the opinion that this provision is very limiting and excludes, for example, communications between hand-held computers and servers.^[27] As discussed above, it is not clear how including such communications (e.g., in Section III.E) would reduce Microsoft's monopoly power. I do not see a need to extend Section III.E to cover non-desktop products, as proposed by the litigating states. The Microsoft operating system monopoly has always been centered on the desktop. This is why Section III.E focuses on facilitating server-based applications, which provide indirect competition to Microsoft. There is no evidence that Microsoft has monopoly power in operating systems for handheld computers, set-top boxes, etc. Indeed, the operating system sold for use in these areas, Windows CE, has been characterized by poor performance since its inception and has been out-performed by Palm OS, Blackberry, and other such competing operating systems. Similarly, Microsoft is not dominant in the server market, and it currently faces competition from servers by Linux and others. I present data confirming these claims in Section IV below. For these reasons, I am convinced that Section III.E provides the right focus. To extend Section III.E to cover additional areas would, as I have discussed, certainly increase antitrust regulation with no clear rationale or benefit.

67. There does remain the issue of how Microsoft will decide what “reasonable and non-discriminatory” charges it will set for access to these communications protocols. This is a reasonable concern that has been raised by several commentators.^[28] The basis for such license fees is apparently limited to intellectual property that Microsoft may have embedded in these protocols, as set out in Section III.I. Some guidance offered for what “reasonable and non-discriminatory” might mean is in the CIS, where it says that the “overarching goal of this Section is to ensure that Microsoft cannot use its intellectual property rights in such a way that undermines the competitive value of its disclosure obligations, while at the same time permitting Microsoft to take legitimate steps to prevent unauthorized use of its intellectual property.” (CIS at 49.) Presumably, any charging mechanism that excluded substantial numbers of ISVs, IAPs, ICPs, or OEMs would violate this requirement. It is my understanding that previous DOJ antitrust consent decrees imply that the term “reasonable and non-discriminatory” is likely to be interpreted as not significantly excluding competitors. On this assumption, the lack of specific rate-setting guidance in Section III.I is not likely to be a severe problem.

68. Because Section III.B does not constrain the structure or levels of the royalty schedule beyond the uniformity requirement, some commentators have expressed the concern that Microsoft might be able to stay within the confines of this provision but still price in such a way as to be anticompetitive. For example, RealNetworks opines that Microsoft could “establish the price of versions of Windows without its middleware set as the default at some artificially high price and the actual price Microsoft wanted to receive as a cash incentive to carry Microsoft's middleware as the default application.” (See RealNetworks Comments at 27.)

69. Contrary to RealNetwork's hypothetical, Section III.B.3.c states that Microsoft cannot discount the price of Windows based on any requirement that is inconsistent with the proposed decree. This means that Microsoft cannot offer discounts on Windows that are tied to OEMs foregoing such options as installing non-Microsoft icons pursuant to Section III.C, or setting defaults, or removing Microsoft Middleware Products pursuant to Section III.H. For instance, Microsoft cannot set the price of Windows at $500 but offer a cash discount of $450 if an OEM sets some Microsoft Middleware Product as the default. Alternatively, should Microsoft offer a direct payment based on the level of support for the Microsoft Middleware Product, this would be a case of preferential treatment within the meaning of Section III.G, so that the OEM could not give Microsoft preferential status more than fifty percent of the OEM shipments.

IV. Issues Not Addressed by the Proposed Decree

70. Many of the parties publicly commenting about asserted loopholes in the proposed decree also have been critical of claimed limitations to the remedy achieved by the settlement.^[29] In this section, I address the main suggestions for additional remedies discussed by these commentators.

A. Unbundling of Microsoft Middleware From the OS.

71. An issue raised in this case is that, if Microsoft proceeds to bundle application software with the OS, an available “stripped down” version of the OS without the application in question should also be released.^[30] Alternatively, when Microsoft releases a new operating system, it should continue to offer the previous version at the original price.

72. This is a potentially important issue. If the OEM has to pay a positive price for a rival middleware product and pays a marginal price of zero for the same functionality bundled in the operating system, then the competitive battle is stacked against the competitor (see Arrow Decl. at ¶ 27). The critics also suggest that OEMs will not want to support more than one product with such functionality, even if icons were removed for the Microsoft Middleware version as permitted under the SRPFJ. With the underlying Microsoft Middleware code embedded in the system, the critics suggest that end users will still find this functionality being invoked and thus will have support concerns and needs, lessening the OEM interest in carrying the rival middleware. Further, the critics claim the availability of the commingled Microsoft Middleware code will further encourage ISVs to write applications to Microsoft products rather than to Non-Microsoft Middleware.^[31] Thus, these commenting economists have urged the DOJ to require the unbundling of Microsoft Middleware from Windows Operating System Products.

73. However, on closer inspection, the requirement to have an unbundled operating system is highly regulatory and is likely to lead to more litigation. For example, to determine the appropriate discount for the unbundled operating system, the general approach would necessarily involve some estimate of the costs of the Microsoft Middleware Products that are to be removed from the bundled version. Such estimates, however, are likely to be arbitrary and complex to calculate. This is because software development efforts involve substantial shared costs between projects and benefit from common overhead expenditures. For example, suppose that a given server is used for ten development projects, both middleware and non-middleware; the cost of this server would have to be allocated between projects. But such cost allocation rules are inherently arbitrary.^[32] Should corporate overhead be allocated between development projects for the purpose of pricing the unbundled operating system? If so, on which of the many accounting bases should it be done? How should the cost of a computer used by one individual on three different projects be allocated between them? To answer questions such as these, regulatory agencies (e.g., the Federal Communications Commission (“FCC”) and the Federal Energy Regulatory Commission (“FERC”)) evolved highly complex case law over a period of decades. Speaking as a regulatory economist with nearly three decades of experience, I can assert with confidence that such pricing of the unbundled operating system would be a regulatory quagmire at least equal in complexity to those that have kept regulatory bodies such as the FCC busy for years.

74. In its comments intended to support the notion of an unbundled operating system, SBC unintentionally discredits this proposal. In referring to the problem of pricing an unbundled version of Windows, SBC states:

Several such mechanisms are possible. The Final Judgment provided that pricing be guided based on bytes of code. . . .. SBC believes that it would be preferable to allocate costs between the operating system and the removed middleware based on measurement of “function point code.” . . . Alternatively, SBC supports the use of a pricing mechanism based on the fully allocated product development costs for the operating system product and middleware products in questions. (See Comments of SBC at 143).

In this revealing passage, SBC makes it clear that because of the numerous and subtle common costs incurred in software development, each interested party would have wide scope to select and litigate for the (arbitrary) pricing mechanism that favored it the most.

75. In any case, it appears to be true that many applications on the desktop are not paid for by the OEM or (initially) by the end user. Indeed, all three of the current major Instant Messaging products are available without charge. I am aware of several instances in which third-party software applications are included by OEMs in their PC offerings, even though similar functionality is bundled by Microsoft in Windows XP. For example, Dell Computer offers photo imaging and CD “burning” software with Microsoft XP Home Edition-based PCs even though XPHome includes similar capabilities.^[33] Dell includes Sierra Imaging's Image Expert 2000 software on some systems, pre-installing a premium version that is available to the end user for 60 days (an additional fee applies to retain premium features after this time limit).^[34] Clearly, Microsoft's bundling does not eliminate the OEM's incentive to use such alternative applications when they are offered under desirable arrangements. Generally in such cases, the business model of an ISV is to provide the software to the OEM for free with hope for future fees from Web services (or other services) provided to end users through the software or from potential upgrade revenue when end users desire premium versions of the product. For example, RealNetworks is pursuing such a strategy and by August or September 2001 was enjoying usage rates approximately twice that of Windows Media Player.^[35] RealNetworks' momentum has continued despite the fact that a version of Windows Media Player has been bundled with every version of Windows since Windows 95. RealNetworks appears to have competed well with products produced by Microsoft and bundled in Windows.^[36]

B. Protections Concerning Microsoft Office Practices

76. Several commentators suggest it is necessary to require Microsoft to “port” Office to other operating systems, such as Apple MAC OS and Linux. For example, Stiglitz and Furman stated a concern that the proposed decree “does not address any issues relating to the pricing, distribution, or porting of Microsoft Office.” (Stiglitz and Furman Decl. at 38.) Stiglitz and Furman and Litan et al. argue that the “porting” of Office is likely to reduce the applications barrier to entry (or at least reduce Microsoft's ability to raise them deliberately). (See Stiglitz and Furman Decl. at 42 and Litan et al. Comment at 71-72.) I agree that this remedy would be a more direct attack on the applications barrier to entry. However, Office has never been a significant part of the case brought against Microsoft. Where Office has been an issue, it relates to Microsoft's efforts to control middleware, such as the “club” used against Apple to harm Netscape, found to be anticompetitive by the District Court and upheld by the Court of Appeals. (See Opinion at 72-74.) The SRPFJ remedies directed at ensuring that rival middleware opportunities exist and can be freely pursued should be sufficient in this regard.^[37]

C. Network Server, Handheld Computer and Web Services Issues

77. Some commentators would prefer the antitrust remedy to extend beyond middleware and the PC environment to cover such emerging product areas as servers, handheld devices, and Web services to insure Microsoft does not extend its monopoly to dominate additional markets and erect new barriers to entry. (See Stiglitz and Furman Decl. at 38-39; Comments of SBC Communications Inc. (“SBC”) at 42-43; and Arrow Decl. at ¶¶ 55, 68-70.) Arrow, for instance, suggests that end users will access the Internet with server and handheld devices, and he concludes that the remedy should protect competing server operating systems and web services. Given Microsoft's anticompetitive practices, he concludes it is reasonable to require parity in access to APIs, protocols, and documentation for interoperability across product areas. (See Arrow Decl. at ¶¶ 55, 68-70). These remedies go well beyond the scope of the case brought against Microsoft (as well as the findings upheld by the appellate court) and also well beyond the desktop, where Microsoft has its proven monopoly. Hence, regulatory intervention is not called for in these areas, as is further addressed in the following assessment of certain specific issues raised relating to corresponding Litigating States proposals in these product areas.

1. Servers

78. Litan et al. point to the increasing importance of client-server networks and server-based computing and conclude that a new platform entrant must not only overcome the application advantages that Microsoft illegally obtained in the desk top OS, but must also provide compatibility with “servers which are increasingly relying on Microsoft's server operating systems” (see Litan et al. at 30.) This suggestion is at variance with the focus of the present antitrust case, which involves Microsoft's desktop monopoly, not the server market. In addition, there is no clear monopoly issue in the server market. Microsoft's share of server operating systems has grown from approximately 27 percent in 1996 to 41 percent in 2000. This gain has apparently come at the expense of other PC compatible network software providers (such as Novell), but not at the expense of competitors likely to be the more relevant factors in the future.^[38] For example, according to a 1999 estimate issued by the International Data Corporation (“IDC”), Linux's server share more than doubled in 1998 to reach 17.2 percent.^[39] More recently, IDC has reported that Linux's worldwide market share in 2000 of new and upgraded operating systems for servers had climbed to 27 percent, ranking it second behind Microsoft's share of 41 percent.^[40] Litan et al. acknowledge that “the Linux OS has made significant inroads into the server market,”^[41] while IDC confirms that, excepting Microsoft and Linux, “market share declined for other server systems, including Unix”over the past year.^[42] For these reasons, I do not believe the server market by itself raises any monopoly power issues.

2. Handheld Computers and Web Services

79. Similarly, some commentators are concerned that Microsoft practices will lead to dominance in operating systems for handheld devices, removing a partial threat to at least some Windows-based personal computers. This leads them to assert that the proposed decree improperly ignores this segment of the computer industry. Again, this remedy seeks a penalty outside the scope of the case. No findings were found or upheld relating to Microsoft conduct directed at handheld devices or handheld competitors. Further, the Microsoft Windows CE operating system has not been gaining systematically on competing systems over the last several years, and there is little reason to divert the focus of the SRPFJ to this area.^[43]

D. Restoring Java as a Competitive Threat

80. Some commentators have suggested that the proposed decree should require mandatory distribution of a Sun-compatible Java runtime environment with each copy of Windows (and IE) shipped by Microsoft. Critics of the proposed decree have suggested this provision is appropriate to attempt to compensate for Sun's lost position and lost momentum as Microsoft deceived developers and discouraged distribution and use of Sun-compliant Java. (See, e.g., Litan et al. at 25 and 71.) Stiglitz and Furman believe this would decrease the applications barrier to entry. (See Stiglitz and Furman Decl. at 42.) There is no question that the cross platform potential of Java was real, but there exists significant uncertainty as to the timing and impact that Java would have had absent Microsoft's unlawful conduct, as discussed in the Findings of Fact. Furthermore, if there is consumer demand for PCs that come with JVMs installed, the OEMs are free to meet that demand and are protected from retaliation by Microsoft under the SRPFJ if they do so. Therefore, in my opinion, this “must carry” provision is disproportionate and will improperly preordain market outcomes. Furthermore, other platforms or products, aided by the SRPFJ, will have an opportunity to serve as a carrier for Java distribution or otherwise provide alternative middleware platforms for future application developers.

E. Publishing IE Source Code

81. Similarly, critics have suggested that the proposed decree should force the open-source licensing of IE in order to reduce the applications barrier to entry and deny Microsoft one of the fruits (i.e., the dominant position of IE) of its anticompetitive conduct. (See Stiglitz and Furman at 41-42, and Litan et al. at 71.) Litan et al. claim that third parties will then “transform IE into a true independent middleware platform,” ensuring that alternative middleware will be ubiquitous even if the SRPFJ anti-retaliatory and disclosure provisions are not enough to foster such an alternative.

82. This claim may well be true, but open-source licensing of IE will inflict economic harm on Microsoft by expropriating its intellectual property. This appears to be either an effort to collect damages from Microsoft or an exercise in competition policy well outside the confines of an antitrust case. If it is an attempt to collect damages from Microsoft, then it should be linked to an estimate of the damages caused by Microsoft's acts. I am not aware that such an estimate exists. Moreover, Microsoft is clearly subject to other punishment outside this case, as Netscape has recently filed suit seeking treble damages for losses associated with Microsoft's anticompetitive conduct aimed at eliminating Netscape's browser as a competitive threat.

F. Continued Licensing of the Predecessor Version of an Operating System

83. One proposal made by Litan et al. is that, whenever Microsoft makes a major release of a Windows Operating System Product, it must continue to license the predecessor version of the new product at its original price. Possibly, the objective is to limit Microsoft's ability to have customers upgrade to the new operating system by increasing the price of the predecessor version. Of course, there is nothing inherently anticompetitive about inducing customers to upgrade to a new major release of an operating system. However, based on my understanding of submission of Litan et al., this proposal is designed to correct a perceived loophole in the proposed decree. Litan et al. state:

In the absence of this provision, Microsoft could frequently offer new, slightly modified versions of the OS that render the middleware based on the predecessor APIs unworkable with the new version. Middleware developers would be discouraged if they knew that Microsoft could raise their costs simply by slightly revising the operating system code in such a way that requires the middleware to be significantly modified. (Litan et al. at 72.)

84. It is not possible to assert that the SRPFJ prevents this from occurring, but it seems unlikely that Microsoft would find such a strategy profitable. First, it would appear to be difficult for Microsoft to limit the damage thus created to threatening middleware products. By changing APIs in the manner suggested by Litan et al., Microsoft would be requiring both ISVs and its own developers to rewrite their code substantially. Moreover, such a strategy would be counterproductive for Microsoft because it would serve to reduce the applications barrier to entry, since the new version of the OS would run fewer applications than its predecessor. This necessarily implies that Microsoft and its ISVs would have to rewrite, at least in part, the thousands of applications available prior to release and would have to coordinate the development schedule of these rewrites with each new release of the operating system. Microsoft's own spotty record in meeting and coordinating the release schedules for even one or two major products makes this outcome an unlikely event.

85. It may be that Microsoft would attempt a less extreme version of the Litan et al. scenario, in which only some of the APIs are changed between versions of Windows. However, there would still exist the problem of limiting the damage to only the middleware that Microsoft regards as threatening. Even moderate changes in APIs would likely lead to large failures of backward compatibility in Windows applications. Thus, to make this strategy work, Microsoft would need to reduce the number of published APIs by a significant amount each year. This action would certainly “discourage” software developers, as Litan et al. suggest, but at the same time it would also discourage ISVs from writing programs for the Windows desktop.

IV. Conclusions

86. The antitrust remedy in this case must focus attention on and fullyresolve the appellate court finding that Microsoft engaged in specific anticompetitive acts to maintain its operating system monopoly. In developing this remedy, it is necessary to balance two broad factors. First, the remedy must place constraints on Microsoft's current and future behavior so that the unlawful acts stop and do not recur, and competitive conditions are restored. However, these constraints should not be so intrusive and complex that they themselves distort market outcomes. This potential distortion can take many forms, but two of the most important are (1) over-extensive government regulation of Microsoft that may result in inefficient rent-seeking by Microsoft's competitors, or (2) requirements that make Microsoft a less efficient competitor. Thus, the difficult task is to create a balanced remedy that constrains anticompetitive behavior by Microsoft without limiting competition on the merits.

87. In my opinion, the SRPFJ achieves the right balance. By focusing on Microsoft's anticompetitive business practices, its provisions eliminate the artificial barriers to entry erected by Microsoft that are the source of competitive concern. The provisions in the proposed decree are likely to deter conduct that (1) seeks exclusivity or (2) is backed by retaliatory threats. The SRPFJ also aims to restore and enhance competitive conditions by removing technical barriers to fair competition between Microsoft and rival middleware suppliers. From an economic standpoint, middleware is important because it can expose APIs and has the potential to become an applications platform distinct from the Windows OS. The SRPFJ does not attempt to preordain market outcomes or to weaken Microsoft as a legitimate competitor.

88. I have considered other proposals carefully, including that of the Litigating States. However, in my view, these proposals fail to achieve the right balance. In an attempt to erase all theoretical ways in which Microsoft could harm competition, these alternative proposals tend to require a complex regulatory program that is certain to be slow-moving, litigious, and vulnerable to manipulation by Microsoft's competitors. For example, the provision for how to price the proposed unbundled operating system invites arguments over cost allocations, and other ratemaking issues, that have the potential to slow down the competitive process.

89. Finally, in analyzing the SRPFJ, I have had the benefit of reviewing a number of thoughtful and probing comments on the proposed decree. As the discussion in Section III demonstrates, most of the potential problems raised by the various commentators are, in fact, not problems at all, but are met by the SRPFJ. However, at first glance there does appear to exist potential ways in which Microsoft could engage in behavior that reduces competition while claiming nonetheless that it satisfied the provisions of the SRPFJ. For example, some commentators have alleged Microsoft could (1) sell middleware only as bundled with the operating system, (2) set prices for access to its client-server communications protocols so high that they exclude competition, and (3) change large numbers of APIs frequently through numerous releases of new operating systems. Although these strategies may be theoretical possibilities, my analysis shows either that these acts would be unimportant or that Microsoft would lack the incentive to undertake such actions.

90. In sum, in my opinion, the SRPFJ focuses attention on and fully resolves the appellate court finding that Microsoft engaged in a series of anticompetitive acts to maintain its OS monopoly. The SRPFJ contains provisions that will stop the offending conduct, prevent its recurrence, and restore competitive conditions. In my opinion, in light of the above, the SRPFJ is in the public interest.

* * * * *

I declare under penalty of perjury that the foregoing is true and accurate. Executed on February 27, 2002 in Austin, Texas.

David S. Sibley.

Appendix A

Curriculum Vitae of Professor David S. Sibley

David S. Sibley, Department of Economics, University of Texas at Austin, Austin, TX 78712, Phone: [phone], Fax: [phone].

Education

1973Ph.D. in Economics, Yale University

1969B. A. in Economics, Stanford University

Teaching Fields

Industrial Organization, Economics of Information

Research Fields

Economics of asymmetric information, telecommunications policy, public utility pricing, models of firm's internal organization.

Professional Experience

March, 1992-Present: John Michael Stuart Centennial Professor of Economics, University of Texas at Austin.

August, 1991-March, 1992: Edward Everett Hale Centennial Professor of Economics, University of Texas at Austin.

September, 1983-August, 1991: Research Manager, Bell Communications Research, Morristown, NJ. Head of Economics Research Group.

September 1981-September 1983: Member of Technical Staff, Bell Laboratories, Murray Hill, NJ.

September 1980-September 1981: Adviser to the Chairman of the Civil Aeronautics Board.

January 1980-September 1980: Consultant, Civil Aeronautics Board, Washington, D.C.

September 1978-January 1980: Senior Staff Economist, Council of Economic Advisers, Executive Office of the President, Washington, D.C.

October 1973-September 1978: Member of Technical Staff, Bell Laboratories, Holmdel, NJ.

Teaching

September 1991-Present: Introductory Microeconomics, undergraduate and graduate Industrial Organization.

Fall 1989: Visiting Lecturer, Woodrow Wilson School of Public and International Affairs, Princeton University. Graduate course in regulation and public choice.

September 1983-December 1983: Adjunct Lecturer in Economics, University of Pennsylvania. Graduate course on regulation.

Publications

A. Journal Articles

“Pricing Access to a Monopoly Input,” (with M. J. Doane, M. A. Williams, and S. Tsai), Journal of Public Economic Theory, 2001 (forthcoming).

“Exclusionary Restrictions in U.S. vs. Microsoft,” (with M.J. Doane and A. Nayyar), UWLA Law Review, 2001.

“Raising Rivals' Costs: The Entry of a Upstream Monopolist into Downstream Markets,” (with D. L. Weisman), Information, Economics and Policy 10:451-470.

“Having Your Cake—How to Preserve Universal-Service Cross Subsidies While Facilitating Competitive Entry,” (with M.J. Doane and M.A. Williams), Yale Journal on Regulation, Summer 1999.

“The Competitive Incentives of Vertically-Integrated Local Exchange Carriers: An Economic and Policy Analysis,” (with D.L. Weisman), Journal of Policy Analysis and Management, Winter 1998.

“Multiproduct Nonlinear Prices with Multiple Taste Characteristics,” (with P. Srinagesh), Rand Journal of Economics, Winter 1997.

“Optional Two-Part Tariffs: Toward More Effective Price Discounting,” (with R. Rudkin) in Public Utilities Fortnightly, July 1, 1997.

“A Bertrand Model of Pricing and Entry,” (with W.W. Sharkey), Economics Letters, 1993.

“Regulatory Incentive Policies and Abuse,” (with D.M. Sappington), Journal of Regulatory Economics, June 1993.

“Optimal Non-linear Pricing With Regulatory Preference over Customer Types,” (with W.W. Sharkery), Journal of Public Economics, February 1993.

“Ex Ante vs. Post Pricing: Optional Calling Plans vs. Tapered Tariffs,” (with K. Clay and P. Srinagesh), Journal of Regulatory Economics, 1992.

“Thoughts on Nonlinear Pricing Under Price Cap Regulation,” (with D.M. Sappington), Rand Journal of Economics, Spring 1992.

“Compensation and Transfer Pricing in a Principal-Agent Model,” (with D.E. Besanko), International Economic Review, February 1991.

“Regulating Without Cost Information: Some Further Thoughts,” (with D.M. Sappington), International Economic Review, November 1990.

“Asymmetric Information, Incentives and Price Cap Regulation,”Rand Journal of Economics, Fall 1989.

“Optimal Two Part Tariffs for Inputs,” (with J.C. Panzar), Journal of Public Economics, November 1989.

“Regulating Without Cost Information: The Incremental Surplus Subsidy Scheme,” (with D.M. Sappington), International Economic Review, May 1989.

“Optimal Consumption, the Interest Rate and Wage Uncertainty,” (with D. Levhari), Economics Letters, 1986.

“Reply to Lipman and Further Results,”International Economic Review, June 1985.

Public Utility Pricing Under Risk: A Generalization,”Economics Letters, June 1985.

“Optimal Non-Uniform Pricing,” (with M.B. Goldman and H.E. Leland), Review of Economic Studies, April 1984.

“Efficiency and Competition in the Airline Industry,” (with D.R. Graham and D.P. Kaplan), Bell Journal of Economics, Spring 1983.

“Optimal Nonlinear Pricing for Multiproduct Monopolies,” (with L.J. Mirman), Bell Journal of Economics, Autumn 1980.

“A Dynamic Model of the Firm with Stochastic Regulatory Review,” (with V.S. Bawa), International Economic Review, October 1980.

“Public Utility Pricing Under Risk: The Case of Self-Rationing,” (with J.C. Panzar), American Economic Review, December 1978.

“Regulatory Commission Behavior: Myopic vs. Forward-Looking,” (with E.E. Bailey), Economic Inquiry, June 1978.

“Optimal Decisions with Estimation Risk,” (with L.C. Rafsky, R.W. Klein and R.D. Willig), Econometrica, November 1977.

“The Demand for Labor in a Dynamic Model of the Firm,”Journal of Economic Theory, October 1977.

“Optimal Foreign Borrowing with Export Revenue Uncertainty,” (with J.L. McCabe), International Economic Review, October 1976.

“Permanent and Transitory Income Effects in a Model of Optimal Consumption with Wage Income Uncertainty,”Journal of Economic Theory, August 1975.

“A Note on the Concavity of the Mean-Variance Problem,”Review of Economic Studies, July 1975.

B. Reports and Articles in Conference Volumes, and Other Publications

“U.S. v. Microsoft: Were the Exclusionary Practices Anticompetitive” (with Michael J. Doane), Computer Industry Newsletter, American Bar Association, Spring 2000, Vol. 5., No. 1.

“Optional Tariffs for Access in the FCC's Price Cap Proposal,” (with D.P. Heyman and W.E. Taylor), in M. Einhorn (ed.), Price Caps and Incentive Regulation in the Telecommunications Industry, Kluwer, 1990.

Report to the Governor, The Task Force on Market-Based Pricing of Electricity. Co-authored with D.M. Sappington, Appendix III.

“An Analysis of Tapered Access Charges for End Users,” (with W.E. Taylor, D.P. Heyman and J.M. Lazorchak), published in the Proceedings of the Eighteenth Annual Williamsburg Conference on Regulation, H. Treeing (ed.), Michigan State, 1987.

“Deregulation and the Economic Theory of Regulation,” (with W.W. Sharkey), in Proceedings of the Eleventh Annual Telecommunications Policy Research Conference, 1983.

“Antitrust Policy in the Airline Industry,” (with S.B. Jollie), Civil Aeronautics Board, October 1982. Transmitted by the CAB to Congress as part of proposed sunset legislation.

“Optimal Non-Uniform Pricing for Electricity: Some Illustrative Examples,” (with R.W. Koenker), in Sichel (ed.) Public Utility Ratemaking in an Energy-Conscious Environment, Praeger, 1979.

“The Dynamics of Price Adjustment in Regulated Industries,” (with E.E. Bailey), in Proceedings of IEEE Conference on Systems Control, 1974.

C. Books:

Co-editor of Telecommunications Demand Analysis: An Integrated View, North-Holland, 1989.

The Theory of Public Utility Pricing, (with S.J. Brown), Cambridge University Press, 1986. Second printing 1986. Third printing 1989. Revised edition planned.

Current Research Areas

Telecommunications policy, especially access pricing and optional tariff design; Design of incentive mechanisms; Organizational slack/informational asymmetries.

Other Professional Activities

Associate Editor of the Journal of Regulatory Economics.

Consultant to the Governor of New Jersey's Task Force on Market-Based Pricing of Electricity.

Referee for National Science Foundation and numerous professional journals.

Consulting for Bell operating companies on a variety of pricing and public policy issues.

Memberships: American Economic Association; listed in Who's Who in the East 1990.

Response of United States to Public Comments on the Revised Proposed Final Judgment

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant;Response of the United States to Public Comments on the Revised Proposed Final Judgment.

Next Court Deadline: March 6, 2002; Tunney Act Hearing

Dated: February 27, 2002.

Charles A. James,

Assistant Attorney General.

Deborah P. Majoras,

Deputy Assistant Attorney General.

Phillip R. Malone,

Renata B. Hesse,

David Blake-Thomas,

Paula L. Blizzard,

Kenneth W. Gaul,

Adam D. Hirsh,

Jacqueline S. Kelley,

Steven J. Mintz,

Barbara Nelson,

David Seidman,

David P. Wales,

Attorneys.

Philip S. Beck,

Special Trial Counsel.

U.S. Department of Justice,

Antitrust Division,

601 D Street NW., Suite 1200

Washington, DC 20530-0001

[phone].

Table of Contents

Introduction

I. General Comments

A. Should Never Have Brought Suit

B. Allegations Of Political Influence

C. Removing The “Fruits” Of Microsoft's Anticompetitive Conduct

D. The Litigating States' Proposal

E. Fines

F. Senate Hearing

II. Tunney Act Issues

A. Adequacy Of The United States' Competitive Impact Statement

1. The CIS Complies With The Requirements Of The Tunney Act

2. The CIS Recites “A Description And Evaluation Of Alternatives To Such Proposal Actually Considered By The United States”

B. The United States Fully Complied With All Tunney Act Requirements Regarding Determinative Documents

C. Timing And Process Of Hearing

1. The Court Has Discretion To Determine The Nature And Format Of The Tunney Act Proceedings

2. An Evidentiary Hearing Is Not Required In This Case

3. The Court Is Not Required To Permit Any Third-Party Participation

4. Allowing Third-Party Participation Through An Evidentiary Hearing Would Unnecessarily Delay And Complicate These Proceedings

5. The Tunney Act Proceedings Should Not Be Held In Conjunction With, Or Rely Upon Evidence From, The Litigating States' Remedy Hearing

D. Standard Of Review Under The Tunney Act

1. The Tunney Act Requires That Entry Of The RPFJ Be “In the Public Interest”

2. The Court Should Grant Deference to the Judgment of the United States

E. Microsoft's Compliance With Section 16(g)

III. Definitions

A. Definition Of “ISV” (RPFJ § VI.I)

B. “Microsoft Middleware” (RPFJ § VI.J)

1. Distributed Separately To Update A Windows Operating System Product

2. Trademarked Or A Major Version Of Any Microsoft Middleware Product

3. Same Or Substantially Similar Functionality

4. Includes At Least The Software Code That Controls Most Or All Of The User Interface

5. Major Updates

C. “Microsoft Middleware Product” (RPFJ § VI.K)

D. “Non-Microsoft Middleware” (RPFJ § VI.M)

E. “Non-Microsoft Middleware Product” (RPFJ § VI.N)

F. “Personal Computer” (RPFJ § VI.Q)

G. “Trademarked” (RPFJ § VI.T)

H. “Windows Operating System Product” (RPFJ § VI.U)

1. Microsoft's Discretion

2. Prior Windows Versions

3. Operating Systems for Other Devices

IV. OEM Provisions

A. Overreliance On OEMs

B. Non-Retaliation (RPFJ § III.A)

1. Section III.A Is Sufficiently Broad

2. Section III.A Properly Allows Microsoft To Enforce Intellectual Property Rights

3. Section III.A Protects OEMs From Arbitrary Termination Of Their Licenses

4. Requiring Proof Of Knowledge Is Necessary And Can Be Met

5. Microsoft's Permitted Use Of “Consideration” Is Appropriate

6. The RPFJ Uses The Common Language Definition Of “Retaliate”

C. Uniform Terms (RPFJ § III.B)

1. Top Twenty OEMs

2. MDAs Or Other Discounts

3. OEMs Should Be Able To Negotiate

4. Volume Discounts

5. Termination—Cause, Materiality, And Notice

6. Servers Or Office

7. Key License Terms

8. Prohibition On Enforcing Agreements Inconsistent With The RPFJ

D. Freedom Of OEMs To Configure Desktop (RPFJ § III.C)

1. Section III.C.1

2. Section III.C.2

3. Section III.C.3

4. Section III.C.4

5. Section III.C.5

6. Comparison To Litigating States' Proposal

E. Microsoft's Obligations To Provide Add/Remove Functionality And Automatic Invocations (RPFJ § III.H)

1. Obligation To Provide Add/Remove Functionality

2. Obligation To Provide Automatic Invocations And Exceptions

a. Obligations To Provide Automatic Invocations

b. Exceptions To The Obligation To Provide Automatic Invocations

3. Microsoft's Ability To Change Configurations

4. Timing Issues

F. Commingling Of Operating System Code And Middleware Code

V. Retaliation Against ISVs or IHVs (RPFJ § III.F)

A. Comments On Section III.F.1

B. Comments On Section III.F.2

C. Comments On Section III.F.3

VI. Exclusionary Agreements (RPFJ § III.G)

A. Omissions

B. Exemptions

VII. Disclosure Provisions (RPFJ §§ III.D, III.E)

A. Disclosure Of APIs (RPFJ § III.D)

1. Product Issues

a. Microsoft's Ability To Manipulate The Definitions To Avoid Disclosure

b. Products Other Than Microsoft Middleware

c. Products Other Than Windows Operating System Products

2. API Issues

a. Definition Of “API”

b. Definition Of “Documentation”

c. Source Code Access

d. Intellectual Property Issues

3. Timing Issues

a. First Disclosures: Windows XP Service Pack 1 Or No Later Than November 2002

b. Triggered By New Version Of Microsoft Middleware: Last Major Beta Test Release

c. Triggered By New Version Of Windows Operating System Product: Timely Manner (RPFJ § VI.R)

B. Disclosure Of Communications Protocols (RPFJ § III.E)

1. Product Issues

a. Windows Operating System Product

b. Microsoft Server Operating System Product

c. Non-Microsoft Client Operating Systems

d. Server-To-Server Communications

e. Other Devices

2. Communications Protocols,Disclosure And Licensing

a. Definition Of “Communications Protocols” (RPFJ § VI.B)

b. The Meaning Of “Interoperate”

c. License For Use

d. The Meaning Of “Natively”

e. Licensing On “Reasonable And Non-Discriminatory Terms”

3. Timing Issues

C. Compulsory Licensing (RPFJ § III.I)

1. Reasonable And Non-Discriminatory Royalty

2. Restriction On Sublicenses

3. Cross-Licenses

4. Scope Of Intellectual Property Rights

5. Comparison To Litigating States' Proposal

D. Security Carve-Outs (RPFJ § III.J)

1. Limitation On Obligations To Document, Disclose Or License

2. Conditioning Licenses On Certain Requirements

E. Disclosure Of File Formats

VIII. Enforcement

A. The Enforcement Powers Of Plaintiffs And The Court

B. The Technical Committee

1. Technical Committee Powers

2. Composition And Control Of The Technical Committee

C. Internal Compliance

D. Voluntary Dispute Resolution

E. Proposals For A Special Master

F. Proposed Reporting Requirements

IX. Termination

X. Comparing the RPFJ to the IFJ

A. Structural Relief vs. Conduct Restrictions

B. Anti-Tying Provisions

C. Intentionally Disabling Rival Software

D. Agreements Limiting Competition

XI. Other Proposed Remedies

A. Restrictions On Software Development Tools

B. Java Must-Carry

C. Porting Microsoft Office

D. Licensing Of Predecessor Versions Of Windows

E. Industry Standards

F. Protection For Large End Users

G. Non-Retaliation For Participation In Litigation

XII. Miscellaneous Comments

A. Microsoft's “.Net” Initiative

B. Course Of Conduct

C. Restoring Java/Netscape Threats

D. Microsoft's Responses To The Litigating States' RFAs

1. Meeting Of The Minds

2. Objections To Language In The CIS As “Vague And Ambiguous”

E. “Open Source” Community

F. “Reasonableness” Standard

G. Computers For Schools

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant; Response of the United States to Public Comments on the Revised Proposed Final Judgment.

Next Court Deadline: March 6, 2002; Tunney Act Hearing.

1. Pursuant to the requirements of the Antitrust Procedures and Penalties Act (“Tunney Act”), 15 U.S.C. 16(b)-(h), the United States hereby responds to the public comments received regarding the Revised Proposed Final Judgment (RPFJ) in this case.

2. Simultaneously with this Response, the parties have filed a Second Revised Proposed Final Judgment (SRPFJ), which includes modifications to which the United States, Microsoft, and the Settling States have agreed.^[1] Because every comment addresses the RPFJ, this Response is couched in terms of, and generally refers to, the proposed decree before the modifications (i.e., the RPFJ), addressing the modifications of the SRPFJ only as required. However, the decree the Court should enter is the modified version of the RPFJ—that is, the SRPFJ.

Introduction^[2]

3. The United States and Microsoft^[3] filed the RPFJ on November 6, 2001, thereby proposing to end on mutually agreeable terms litigation that began on May 18, 1998. Pursuant to the requirements of the Tunney Act, the United States filed its Competitive Impact Statement (CIS) on November 15, 2001, and published the RPFJ, CIS, and a description of the procedures for submitting public comments on the proposed decree in the Federal Register on November 28, 2001. 66 FR 59452 (2001). The United States also posted information on those procedures on the Department of Justice website. See http://www.usdoj.gov/​atr/​cases/​ms-settle.htm.

4. The 60-day public comment period began on November 28, 2001, and ended on January 28, 2002.^[4] During that period, the United States received 32,329 public comments. This was by far the most comments ever received on any proposed decree under the Tunney Act. By comparison, the number of comments received on the RPFJ vastly exceeds the number received in the ATT case—which completely restructured the telecommunications industry—by more than an order of magnitude. United States v. ATT, 552 F. Supp. 131, 135 (D.D.C. 1982) (“over six hundred documents”), aff'd mem. sub. nom. Maryland v. United States, 460 U.S. 1001 (1983); 47 FR 21214-24 (1982) (listing name and address of each commentor on proposed ATT decree, with length of comment in pages).^[5]

5. The large volume of comments in this case reflects, in part, the widespread use of electronic mail to submit comments (approximately 90-95% of the comments were submitted via e-mail, as opposed to approximately 5-10% via facsimile and fewer than 1% via hand delivery) and the fact that various groups, both opposed to and in favor of entry of the RPFJ, placed solicitations on their websites or sent mass electronic mailings urging submission of comments on the proposed settlement.^[6]

6. Approximately 1,500 comments were unrelated to either the United States v. Microsoft case generally or the RPFJ specifically, or were merely duplicate copies of comments by the same individual or entity. A small number of these submissions are simply advertisements or, in at least one case, pornography. The United States has not filed these comments with the Court and does not intend to publish them. Approximately 1700 comments relate to other antitrust suits against Microsoft.^[7] Most of these comments address only the proposed settlement of the private, class action against Microsoft, and not the RPFJ; erring on the side of over-inclusiveness, the United States has filed these latter unrelated comments with the Court and will publish them.

7. Approximately 22,750 comments express an overall view of the RPFJ. Of these, roughly 5,700 do not, for example, attempt to analyze the substance of the RPFJ, do not address any of its specific provisions, and do not describe any particular strengths or shortcomings of it.^[8] Approximately 16,700 comments can be characterized as containing some generally limited analysis of the RPFJ. These comments typically are one-to-two pages and contain limited discussion of issues related to the RPFJ.^[9] The remaining 350 comments expressing an overall view can be characterized as containing a degree of detailed substance concerning the RPFJ. These comments range from one- or two-page discussions of some aspect of the RPFJ, to 100-plus-page, detailed discussions of numerous of its provisions or alternatives.^[10] There is substantial overlap among these more substantial comments in terms of the issues and arguments that they address. Of these roughly 350 comments, the United States characterized 47 as “detailed” comments based on their length and the detail with which they analyze significant issues relating to the RPFJ.^[11] There is also considerable duplication of the issues addressed and arguments raised among these “detailed” comments.

8. Of the total comments received, roughly 10,000 are in favor of or urge entry of the RPFJ, roughly 12,500 are opposed, and roughly 9,500 do not directly express a view in favor of or against entry. For example, a significant number of comments contain opinions concerning Microsoft generally (e.g., “I hate Microsoft”), or concerning this antitrust case generally (e.g., “This case should never have been brought”), but do not state whether they support or oppose entry of the RPFJ.

9. In the remainder of this Response, the United States responds to the various types of comments according to the issues that the comments raise. For example, we respond to comments that raise issues relating to the disclosure provisions of the RPFJ (Sections III.D and III.E) in one section, and we respond to comments that suggest that the United States should have pursued a structural remedy against Microsoft in another section. Although the United States has reviewed and categorized every comment individually, it is not responding to comments on an individual comment-by-comment basis; rather, it summarizes the issues raised by specific comments and provides references for locating these issues in specific comments. On each issue, the Response refers to some of the comments that raised it;^[12] other comments may raise the same issue but are not identified in this Response.

I. General Comments

A. Should Never Have Brought Suit

10. Many comments complain about the legitimacy of the charges brought against Microsoft. These comments typically characterize the prosecution of Microsoft as an unjustified assault upon a successful business, and often refer to the benefits Microsoft has generated for the economy and shareholders. These comments object to the RPFJ as unnecessary relief.^[13]

11. Comments challenging the validity of the United States' case, or alleging that it should not have been brought, are challenges to the initial exercise of the United States' prosecutorial discretion and are outside the scope of this proceeding. The purpose of this proceeding is not to evaluate the merits of the United States' case. A Tunney Act proceeding is not an opportunity for a “de novo determination of facts and issues,” but rather “to determine whether the Department of Justice's explanations were reasonable under the circumstances” because “[t]he balancing of competing social and political interests affected by a proposed antitrust decree must be left, in the first instance, to the discretion of the Attorney General.”United States v. Western Elec. Co., 993 F.2d 1572, 1577 (D.C. Cir. 1993) (citations omitted). Courts consistently have refused to consider “contentions going to the merits of the underlying claims and defenses.”United States v. Bechtel, 648 F.2d 660, 666 (9th Cir. 1981). Accordingly, those comments seeking to challenge the legitimacy of the United States' underlying case against Microsoft are beyond the purview of appropriate Tunney Act inquiry.

12. Nevertheless, the United States notes in response to these comments that, prior to filing the Complaint, the United States conducted an extensive and thorough investigation into specific Microsoft practices that unlawfully restrained competition in the PC operating system market. This investigation led the United States to conclude that Microsoft undertook several illegal actions to protect its market position. Both the District Court's decision and the unanimous, en banc Court of Appeals' decision “uphold[ing] the District Court's finding of monopoly power in its entirety,” and affirming in part “the District Court's judgment that Microsoft violated § 2 of the Sherman Act by employing anticompetitive means to maintain a monopoly in the operating system market,”United States v. Microsoft Corp., 253 F.3d 34, 51, 46 (D.C. Cir. 2001) (en banc) (per curiam) (“Microsoft”), support the United States' conclusion.

B. Allegations of Political Influence

13. Certain commentors allege that the RPFJ resulted from improper influence exerted by Microsoft on the United States. They generally base their allegations on the fact and size of Microsoft's political contributions and assert that, because the RPFJ does not contain the relief that the commentors prefer, the RPFJ must be the result of malfeasance or corruption on the part of the United States.^[14]

14. The commentors' allegations, however, lack any factual support. Commentors contend that Microsoft extensively lobbied both the legislative and executive branches of the federal government to bring an end to the litigation.^[15] By citation to Microsoft's lobbying and political contributions, commentors apparently seek to raise an inference of impropriety on the part of representatives of the Antitrust Division of the Department of Justice. Commentors suggest that these representatives somehow were corrupted by Microsoft's general lobbying activities.

15. Allegations that the substance of the RPFJ reflects any kind of political corruption are meritless. Just as a judge should not accept conclusory allegations of bias or prejudice based upon mere opinions or rumors as the basis for disqualification,^[16] so too mustallegations of corruption on the part of Department of Justice attorneys be supported by something more than supposition and innuendo.^[17] Actual evidence of corruption is required in order to support rejection of a consent decree. Mere speculation and conjecture are insufficient. Because there is simply no credible evidence of corruption in this case, there are no specific facts to which the United States can respond on this issue.

16. More generally, the comments on this issue ignore the indisputably neutral influences on the settlement process, such as (1) the decision of nine independent States to join the settlement, (2) the decision by the Court of Appeals in Microsoft, which significantly narrowed the scope of Microsoft's potential liability and cast substantial doubt on the legal viability of potential remedies, particularly divestiture, and (3) the interest in obtaining prompt implementation of remedies without the delay inherent in further litigation and appeals.

C. Removing the “Fruits” of Microsoft's Anticompetitive Conduct

17. Certain public comments suggest that the RPFJ does not sufficiently remove the “fruits” of Microsoft's illegal conduct,^[18] and that the decree must go further than simply barring Microsoft from further bad behavior.^[19] Such criticism is not well-taken. As the United States previously stated in the CIS (at 24), the restoration of competition is the “key to the whole question of an antitrust remedy,”United States v. E.I. du Pont de Nemours Co., 366 U.S. 316, 326 (1961). Competition was injured in this case principally because Microsoft's illegal conduct maintained the applications barrier to entry into the PC operating system market by thwarting the success of middleware that had the potential to erode that barrier. Thus, the key to the proper remedy in this case is to end Microsoft's restrictions on potentially threatening middleware, prevent it from hampering similar nascent threats in the future, and restore the competitive conditions created by similar middleware threats. In this context, the fruit of Microsoft's unlawful conduct was Microsoft's elimination of the ability of potentially threatening middleware to undermine the applications barrier to entry without interference from Microsoft. The RPFJ addresses and remedies precisely this issue.

18. Criticism of the RPFJ's alleged failure to remove the fruits of Microsoft's unlawful conduct falls into two general categories: (1) comments that define “fruits” consistently with the Court of Appeals' ruling, as described in the preceding paragraph, but claim that the RPFJ does not restore competitive conditions sufficiently that middleware has the potential to flourish without risk of interference from Microsoft; and (2) comments whose definition of “fruits” is inconsistent with either the claims alleged in this case, the Court of Appeals' decision, or both.

19. The first group argues that the RPFJ permits Microsoft to retain the fruits of its illegal conduct by allowing it “free rein to squash nascent, albeit unproven competitors at will,”^[20] and does not sufficiently remove the applications barrier to entry.^[21] In the phrasing of one commentor, as a result of its anticompetitive conduct toward Netscape, Microsoft allegedly is left with the freedom from a competitive environment in which threats could be nurtured.^[22] As described in detail below (see Sections III-VII), however, the RPFJ protects the ability of middleware to compete by imposing a variety of affirmative duties and conditions on Microsoft. The RPFJ is devised to ensure that middleware developers have access to the necessary information—e.g., through disclosure of APIs and server communications protocols—to create middleware that can compete with Microsoft's products in a meaningful way.^[23] It also restricts Microsoft's conduct toward OEMs and others, and thus opens the door for competing middleware to obtain necessary support, promotion, and distribution.

20. The second group of commentors sets forth a variety of different views regarding what the “fruit of the illegal conduct” is in this case. Many of these comments rely on assertions that exceed the scope of either the liability findings in this case, or the theory of the case generally, or both. For example, some comments define the fruit as Microsoft's enduring monopoly in its Windows operating system and suggest that an appropriate remedy must directly attack the operating system monopoly.^[24] But the United States never alleged in this case that Microsoft illegally acquired its operating system monopoly. And neither the District Court nor the Court of Appeals adopted the view that Microsoft “would have lost its position in the OS market but for its anticompetitive behavior.”Microsoft, 253 F.3d at 107; see also United States v. Microsoft Corp., 84 F. Supp. 2d 9, 111 at ¶ 411 (D.D.C. 1999) (“Findings of Fact”) (“There is insufficient evidence to find that, absent Microsoft's actions, Navigator and Java already would have ignited genuine competition in the market for Intel-compatible PC operating systems.”). In keeping with the original framework of the case and the Court of Appeals' decision, the United States believes that there is no basis for imposing a remedy that seeks to strip Microsoft of its position in the operating system market.

21. Other commentors define the “unlawful fruit” as Microsoft's control of the browser market and contend that any remedy must prevent Microsoft from using similar conduct to gain control of services that rely on Internet Explorer.^[25] Other criticism is directed toward the decree's failure to ban contractual tying.^[26] A number of commentors, including the Litigating States, propose that Microsoft be required to offer open source licenses to Internet Explorer source code without royalty.^[27] These commentors claim that, because Microsoft's intent in offering Internet Explorer as a free product was central to its unlawful conduct, the open source remedy may be appropriate to restore competition and deprive Microsoft of the fruits of its unlawful conduct.^[28] Similarly, certain commentors propose that Microsoft berequired to port Internet Explorer to other operating systems.^[29]

22. Stripping Microsoft of its market position in the browser market or banning contractual tying, however, are remedies that are not warranted on the existing record. This case was not a monopoly leveraging case, and the Court of Appeals reversed the District Court's judgment as it related to attempted monopolization of the browser market, and vacated and remanded the District Court's judgment on the tying claim. Microsoft, 253 F.3d at 46. The remedy in this case must be evaluated in terms of the viable claims remaining after the Court of Appeals' decision; under that construct, remedial measures targeted at Internet Explorer are unsupportable.

23. In particular, neither open sourcing the Internet Explorer source code nor requiring Microsoft to port Internet Explorer to other operating systems would be an appropriate remedy. As one commentor notes, that remedy would benefit Microsoft's competitors rather than ensuring a level playing field for all participants in the software industry.^[30] Most importantly for consumers, it would not significantly enhance those competitors' incentives or ability to develop new or better products. The disclosure provisions of the RPFJ instead provide middleware developers with access to sufficient information for interoperability that will allow them to create middleware—including browsers—that have the ability to compete with Microsoft's middleware in a meaningful way.^[31] The goal of the RPFJ is to restore the opportunity for middleware of all types. The United States believes that this approach is consistent with the Court of Appeals' opinion and will sufficiently deprive Microsoft of the fruits of its unlawful conduct.

D. The Litigating States' Proposal

24. A number of comments suggest that the United States should have proposed a remedy similar to the proposal submitted by the Litigating States in their remedy proceeding with Microsoft in New York.^[32] The United States' primary consideration when crafting the RPFJ was to focus on the practices engaged in by Microsoft that the Court of Appeals found unlawful. As explained in the CIS, elsewhere in this Response, and in the U.S. Memorandum, the United States believes that the RPFJ takes the correct approach toward addressing the anticompetitive conduct found by the Court of Appeals, preventing its recurrence, and restoring lost competitive conditions in the marketplace.^[33]

25. Where relevant, we have addressed the differences between the Litigating States' proposals and their counterparts in the RPFJ and have responded to the comments that address these differences. The Litigating States' Proposal also contains several provisions that are not directly comparable to any of the provisions in the RPFJ. For the reasons described below, the United States believes that such provisions are not appropriate as a remedy for the violations found by the Court of Appeals.

E. Fines

26. Many comments criticize the RPFJ for not imposing monetary damages on Microsoft. According to these critics, the decree does not “include anything that would make Microsoft pay for its past misdeeds.”^[34] Others similarly complain that the proposed decree does not contain any provision for the disgorgement of illegal profits.^[35] Still others complain that the decree should have required Microsoft to reimburse the United States for the attorneys' fees expended on this case.^[36]

27. Monetary damages, including attorneys' fees, are not available to the United States in this case. This is a government civil action for injunctive relief, and monetary damages are not available in such actions. See 15 U.S.C. 4 (authorizing the United States “to institute proceedings in equity to prevent and restrain such violations”) (emphasis added). Cf. 15 U.S.C. 15(a) (damages available to United States when it is “injured in its business or property”). Moreover, the goals of the remedy in this case are to enjoin the unlawful conduct, prevent its recurrence, and restore competitive conditions in the market affected by Microsoft's unlawful conduct. See Nat'l Soc'y of Prof'l Eng'rs v. United States, 435 U.S. 679, 697 (1978); United States v. E.I. du Pont de Nemours Co., 366 U.S. 316, 326 (1961). The RPFJ accomplishes these goals. By contrast, punishment is not a valid goal.^[37]

F. Senate Hearing

28. The Senate Judiciary Committee submitted a comment consisting of the record from its hearing on December 12, 2001, “The Microsoft Settlement: A Look to the Future.” The hearing record consists of the following items: (1) A list of witnesses at the hearing; (2) a transcript of the hearing; (3) written statements of Senators Leahy, Hatch, Kohl, Durbin and Sessions; (4) written statements of Charles A. James (Assistant Attorney General—Antitrust Division, U.S. Department of Justice), Jay L. Himes (New York Attorney General's Office), Charles F. Rule (counsel to Microsoft), Professor Lawrence Lessig (Stanford Law School), Dr. Mark N. Cooper (Consumer Federation of America), Jonathan Zuck (Association for Competitive Technology), Matthew Szulick (Red Hat, Inc.), and Mitchell E. Kertzman (Liberate Technologies); (5) written statements submitted for the record of Ralph Nader and James Love (Consumer Project on Technology), Mark Havlicek (Digital Data Resources, Inc.), Jerry Hilburn (Catfish Software, Inc.), Lars H. Liebeler (Computing Technology Industry Association), and Dave Baker (EarthLink, Inc.); (6) the RPFJ; (7) News Statement of Citizens Against Government Waste; (8) letter from Senator Hatch to Assistant Attorney General James; (9) letter from Assistant Attorney General James to Senator Hatch; (10) letter from Robert H. Bork to Senators Leahy and Hatch; (11) letter from James L. Barksdale to Senators Leahy and Hatch; (12) letter from Vermont Attorney General William H. Sorrell to Steven A. Ballmer; (13) written questions of Senators Leahy, Hatch, Kohl, DeWine, Durbin, and McConnell; and (14) answers to written questions from Assistant Attorney General James, Professor Lawrence Lessig, Mitchell Kertzman, Matthew Szulik, Charles F. Rule, Jonathan Zuck, and Jay L. Himes.

29. The materials submitted by the Senate Judiciary Committee constitute a self-contained record of the Committee's comments on the settlement (in the form of both questions and written and oral statements) submitted to the Department of Justice, and the Department's responses to those comments. As such, the United States does not respond again here to those comments specifically. The United States notes, however, that many of the Committee's comments on the settlement are identical to or overlap with other comments (including an individual comment from Senator Kohl), to which the United States does respond.

II. Tunney Act Issues

A. Adequacy Of The United States' Competitive Impact Statement

30. Several commentors claim that the CIS fails to comply with the Tunney Act.^[38] Thus, one commentor contends that the CIS is deficient for failing to include substantive economic analysis.^[39] Another contends that the CIS is too terse, and therefore does not meet the requirements of the statute, the standard set by the CIS filed by the United States in ATT (47 FR 7170-01), or requirements of agency rulemakings.^[40] Other commentors assert that the CIS is inadequate for failing to provide a detailed explanation for rejection of alternative remedies.^[41] Still other commentors fault the CIS for allegedly misstating or adding terms to the RPFJ.^[42] One commentor specifically criticizes the CIS’ lack of explanation of (1) the use of a definition of “Middleware” in the RPFJ that differs from that used by the Court of Appeals; (2) the lack of a Java-related remedy; (3) the failure of the RPFJ to prohibit all forms of retaliation; and (4) the failure of the RPFJ to address all of the harms identified by the Court of Appeals.^[43] Another comment also contends that the United States has failed to produce “determinative documents,” as required by 15 U.S.C. 16(b).^[44]

31. As this recitation shows, while the commentors couch their objections in terms of an alleged failure by the United States to comply with the Tunney Act, for the most part the objections are in substance comments on the RPFJ itself. Because the CIS fully complies with the Tunney Act requirements, none of the objections is well taken.

1. The CIS Complies With the Requirements of the Tunney Act

32. Congress enacted the Tunney Act, among other reasons, “to encourage additional comment and response by providing more adequate notice [concerning a proposed consent judgment] to the public,” S. Rep. No. 93-298, at 5 (1973) (“Senate Report”); H.R. Rep. No. 93-1463, at 7 (1974) (“House Report”), reprinted in 1974 U.S.C.C.A.N. 6535, 6538. The CIS is the primary means by which Congress sought to provide more adequate notice to the public. The Tunney Act requires that the CIS “recite':

(1) The nature and purpose of the proceeding;

(2) A description of the practices or events giving rise to the alleged violation of the antitrust laws;

(3) An explanation of the proposal for a consent judgment, including an explanation of any unusual circumstances giving rise to such proposal or any provision contained therein, relief to be obtained thereby, and the anticipated effects on competition of such relief;

(4) The remedies available to potential private plaintiffs damaged by the alleged violation in the event that such proposal for the consent judgment is entered in such proceeding;

(5) A description of the procedures available for modification of such proposal; and

(6) A description and evaluation of alternatives to such proposal actually considered by the United States.

15 U.S.C. 16(b).

33. When Senator Tunney introduced the bill that became the Act, he explained that a purpose of the six items of information required in a CIS was to “explain to the public[,] particularly those members of the public with a direct interest in the proceeding, the basic data about the decree to enable such persons to understand what is happening and make informed comments o[r] objections to the proposed decree during the 60-day period.” 119 Cong. Rec. 3452 (1973) (Remarks of Sen. Tunney) (“Tunney Remarks”).^[45] The purpose could be achieved, Senator Tunney suggested, without adding greatly to the United States' workload: the six prescribed items “do not require considerably more information than the complaint, answer and consent decree themselves would provide and, therefore, would not be burdensome requirements.” The Antitrust Procedures and Penalties Act: Hearings on S. 782 and S. 1088 Before the Subcomm. on Antitrust and Monopoly of the Senate Comm. on the Judiciary, 93d Cong. 3 (1973) (“Senate Hearings”) (statement of Sen. Tunney) (“Tunney Statement”). In light of the more than 30,000 public comments concerning the RPFJ submitted to the United States, there can be little debate that the CIS contained sufficient information for the public to make “informed comments o[r] objections” relating to the RPFJ.

34. There is no serious dispute that the CIS satisfies the requirements of the Tunney Act with respect to items 1, 2, 4, and 5 listed above. Also as discussed above, most of the comments purporting to address item 3 (explanation of the proposed judgment) in fact are complaints about the substance of the RPFJ and not the sufficiency of the CIS. These comments are addressed in this Response according to the provision of the RPFJ to which they apply. To the extent that any comments intend to suggest that the explanation in the CIS itself is deficient, the United States believes that the CIS is more than adequate to its intended purpose of describing the proposed decree's provisions and eliciting public comments.

2. The CIS Recites “A Description And Evaluation Of Alternatives To Such Proposal Actually Considered By The United States”

35. Section V of the CIS (CIS at 60-63) describes alternatives the United States considered and rejected,^[46] and describes the reasons why they were rejected. It explains why the United States viewed the RPFJ as a superior alternative to continued litigation; why the United States decided not to continue to seek a break-up of Microsoft; and the reasons for differences between the interim conduct provisions of the Initial Final Judgment (IFJ), United States v. Microsoft Corp., 97 F. Supp. 2d 59, 66-69 (D.D.C. 2000),vacated, 253 F.3d 34, 46 (D.C. Cir. 2001) (en banc) (per curiam), and the provisions of the RPFJ. It also lists a number of other remedy proposals, the criteria used to evaluate them, and the results of that evaluation. The recitations contained in the CIS are fully consistent with providing “basic data about the decree to enable [members of the public with a direct interest] to understand what is happening and make informed comments o[r] objections to the proposed decree,” 119 Cong. Rec. 3452 (1973) (Tunney Remarks), and with Senator Tunney's view that the statutory requirements should not be burdensome. See Tunney Statement. The number and nature of the comments themselves suggest that the level of analysis in the CIS was more than adequate to stimulate informed public comment about the proposed remedy and about the relative merits of alternative remedies. As the United States described recently in its response to AAI's lawsuit,^[47] the recital complied with the statutory requirement and fulfilled its purpose.

B. The United States Fully Complied With All Tunney Act Requirements Regarding Determinative Documents

36. The Tunney Act requires the United States to make available to the public copies of “any other materials and documents which the United States considered determinative in formulating [the proposed final judgment].” 16(b). The CIS explained that the United States is not filing any determinative documents in this case because there are none within the meaning of the statute. One comment says that this disclosure is deficient,^[48] but it is mistaken.

37. The United States did not file any determinative documents with the Court or disclose any in the CIS for the simple reason that there are no such documents in this case. The Court of Appeals has addressed the definition of “determinative documents” in a Tunney Act case. Mass. Sch. of Law at Andover, Inc. v. United States, 118 F.3d 776 (D.C. Cir. 1997) (“MSL”). In MSL, the court held that a third party was not entitled a wide range of documents from the government's files.^[49] The United States there said the statute referred to documents “that individually had a significant impact on the government's formulation of relief—i.e., on its decision to propose or accept a particular settlement.”Id. at 784 (quoting brief of the United States). The court concluded that the statutory language “seems to point toward the government's view . . . and confines § 16(b) at the most to documents that are either ‘smoking guns’ or the exculpatory opposite.”Id. The court added that “[t]he legislative history in fact supports the government's still narrower reading.”Id.; see also United States v. Bleznak, 153 F.3d 16, 20-21 (2d Cir. 1998) (only documents that were a “substantial inducement to the government to enter into the consent decree” need be disclosed). No court of appeals has said otherwise.^[50]

38. Thus, the commentor who asserts that the United States must have failed to comply with the statute because it “cannot be accurate” that no determinative documents exist,^[51] misapprehends the meaning of “determinative documents.” The United States simply did not consider any document in this case to be a “smoking gun or its exculpatory opposite” with a significant impact on the formulation of its decision regarding the RPFJ.

C. Timing and Process of Hearing

39. Several comments say that an evidentiary hearing with third party participation is necessary and that the hearing should be held in conjunction with—or even after—the remedy hearing in New York. We disagree.

1. The Court Has Discretion To Determine the Nature and Format of the Tunney Act Proceedings

40. A court in a Tunney Act proceeding is vested with great discretion concerning the nature of any proceedings to review a proposed consent decree. Congress clearly intended that “the trial judge will adduce the necessary information through the least time-consuming means possible,”see S. Rep. No. 298, 93d Cong. 6 (1973) (“Senate Antitrust Report”); H.R. Rep No. 93-1463, 93d Cong. Sess. 8 (1974), reprinted in 1974 U.S.C.C.A.N. 6535, 6539 (“House Antitrust Report”), even though the court may take other steps as it may deem appropriate. 15 U.S.C. 16(f). The procedural devices enumerated in Section 16(f) are discretionary—the legislative history characterizes them as “tools available to the district court or [sic] its use, but use of a particular procedure is not required.” 119 Cong. Rec. 3453 (Feb. 6, 1973) (Remarks of Sen. Tunney). Such procedures were made discretionary “to avoid needlessly complicating the consent decree process.”Id.

41. The legislative history further indicates that Congress did not intend the Tunney Act to produce lengthy hearings on the merits and thereby undermine the incentives for the United States and defendants to reach settlements in civil antitrust cases. See Senate Antitrust Report at 3. Rather, Congress meant to retain the consent decree as a viable settlement option, calling it “a substantial antitrust enforcement tool.” See Senate Antitrust Report at 6-7; House Antitrust Report at 8; United States v. Microsoft Corp., 56 F.3d 1448, 1456 (D.C. Cir. 1995) (“Microsoft I”).

2. An Evidentiary Hearing Is Not Required in This Case

42. Several commentors argue that the Court should conduct an evidentiary hearing given the complexity and importance of this case.^[52] But the Tunney Act does not mandate a hearing or trial. See United States v. Airline Tariff Publ'g Co., 836 F. Supp. 9, 11 n.2 (D.D.C. 1993); United States v. NBC, 449 F. Supp. 1127 (C.D. Cal. 1978). Indeed, such a hearing could largely defeat the principal considerations behind the RPFJ: to avoid the uncertainty of a trial and to obtain “prompt relief in a case in which illegal conduct has long gone unremedied.” CIS at 60. The legislative history “clearly and expressly establishes that ‘[i]t [was] not the intent of the committee to compel a hearing or trial on the public interest issue.’ ”NBC, 449 F. Supp. at 1143-44 (quoting Senate Antitrust Report, quoted with approval in House Antitrust Report at 8-9).Instead, the “Tunney Act expressly allows the court to make its public interest determination on the basis of the competitive impact statement and response to comments alone.”United States v. Enova Corp., 107 F. Supp. 2d 10, 17 (D.D.C. 2000).

43. The court may, in its discretion, invoke additional procedures when it determines that such proceedings may assist in the resolution of issues raised by the comments. See id. But the legislative history indicates that “[w]here the public interest can be meaningfully evaluated simply on the basis of briefs and oral argument, this is the approach that should be utilized.” House Antitrust Report at 8. “Only where it is imperative that the court should resort to calling witnesses for the purpose of eliciting additional facts should it do so.”Id. Even in ATT, which at the time was considered “the largest and most complex antitrust action brought since the enactment of the Tunney Act,” the court concluded that “none of the issues before it require[d] an evidentiary hearing,” and instead invited briefing from interested individuals and allowed participation through oral argument at the two-day hearing on the proposed modifications to the final judgment that were at issue. ATT, 552 F. Supp. at 145, 219.

44. It is not imperative to hold an evidentiary hearing in this case because the Court has sufficient information to determine whether to approve a consent decree. United States v. Associated Milk Producers, 394 F. Supp. 29, 45 (W.D. Mo.), aff'd, 534 F.2d 113 (8th Cir. 1976); United States v. G. Heileman Brewing Co., 563 F. Supp. 642, 650 (D. Del. 1983). In this case, the Court already has the benefit of a broad array of materials to assist in making the public interest determination. Over 30,000 public comments were submitted, including detailed comments from, among others, some of Microsoft's primary competitors and most vociferous critics (such as Sun Microsystems, AOL/Time Warner, and RealNetworks) as well as computer and software industry trade groups representing the interests of such firms (such as ProComp, CCIA, and SIIA). The Court also has this Response, as well as additional briefing submitted by the United States, Microsoft, and the Settling States. The Court has scheduled a two-day hearing on the RPFJ, during which the Court has indicated it will hear oral argument from the United States, Microsoft, and the Settling States, as well as pose questions to the parties. The Court has further indicated that it may hear brief oral argument from third parties during the hearing, although the precise nature of third-party participation, if any, is still under consideration. The Court will have access to a sufficient body of materials to determine whether the RPFJ is in the public interest without resorting to an evidentiary hearing that would both delay and unnecessarily complicate the evaluation of the RPFJ.

3. The Court Is Not Required To Permit any Third-Party Participation

45. Whether and to what extent to allow third parties to participate is left to the Court's discretion; the Tunney Act permits, but does not require, the Court to authorize third-party participation. 15 U.S.C. 16(f)(3). Courts usually deny third-party participation in Tunney Act proceedings both because the potential for delay outweighs the benefit from intervention (see, e.g., United States v. IBM Corp., 1995 WL 366383 (S.D.N.Y. June 19, 1995)) and because interested third parties are heard through the comments process. United States v. G. Heileman Brewing Co., 563 F. Supp. 642, 652 (D. Del. 1983); United States v. Carrols Devel. Corp., 454 F. Supp. 1215, 1221-22 (N.D.N.Y. 1978). That is particularly true in this case, where a large number of highly interested and motivated third parties have taken full advantage of the opportunity to submit extensive comments that set forth their views of the RPFJ and whether the Court should enter it. As a result, although the Court ultimately may choose to hear from third parties,^[53] they have already had a full and effective mechanism to present to the Court any arguments or concerns they believe it should address in its public interest determination.

4. Allowing Third-Party Participation Through an Evidentiary Hearing Would Unnecessarily Delay and Complicate These Proceedings

46. Insofar as commentors claim that third parties should be allowed to participate in an evidentiary hearing, doing so would serve only to complicate and delay these proceedings. Allowing third-party participation in an evidentiary hearing would delay the much-needed relief the United States seeks in the public interest. As the court in IBM wisely observed, “ ‘[a]dditional parties always take additional time. Even if they have no witnesses of their own, they are a source of additional questions, objections, briefs, arguments, motions and the like which tend to make the proceedings a Donnybrook Fair.’ ”IBM, 1995 WL 366383, at *5 (quoting Crosby Steam Gage Valve Co. v. Manning, Maxwell Moore, Inc., 51 F. Supp. 972, 973 (D. Mass. 1943)).

47. Much of the “evidence” that such commentors seek to present during an evidentiary hearing consists of materials that have been, or could have been, included in their public comment submissions^[54] or that could be addressed through briefing and oral argument, should the Court choose to allow such third-party participation. Resubmitting such materials through the form of testimony would result only in delay and a waste of judicial resources. The commentors—who already have been given an opportunity fully to be heard—have not demonstrated that an evidentiary hearing would in any way advance the public interest or permit them to improve materially on the points made in the extensive comments already submitted.

5. The Tunney Act Proceedings Should Not Be Held in Conjunction With, or Rely Upon Evidence From, the Litigating States' Remedy Hearing

48. Finally, a number of comments propose that the Court consider the RPFJ either in conjunction with, or after, consideration of the Litigating States' proposed remedy in New York. Some argue that the Court should not make its determination regarding the RPFJ until after the Litigating States have presented their case, claiming that such an approach is necessary to avoid prejudicing the Litigating States' case.^[55] Others assert that the Court should hold a hearing on the RPFJ, if at all, only after the Litigating States' hearing.^[56] Finally, at least one commentor proposes that the Court hold a single hearing to evaluate all possible remedial options, including the Litigating States' proposal, the RPFJ, and major structural remedies.^[57]

49. These proposals are ill-advised and unworkable for a number of reasons. First, the RPFJ and the Litigating States' proposed remedy are to be evaluated separately and under different standards. See U.S. Memorandum at 35-46. Second, it would be inappropriate to introduce evidence relating to New York in this Tunney Act proceeding. The United States is not a party to New York, has not participated in the discovery or other aspects of that case, has played no role in the development of the evidence related to that case, and will not participate in that hearing. Consideration of evidence from thatcase in this proceeding, therefore, would be inappropriate. Cf. Fed. R. Evid. 804(b)(1) (testimony given in another hearing in a different proceeding can be admitted against a party only “if the party against whom the testimony is now offered or . . . a predecessor in interest, had an opportunity and similar motive to develop the testimony by direct, cross, or redirect examination”).

50. Finally, proposals to have the two cases considered concurrently, or to postpone consideration of the RPFJ until after the remedial hearing in New York, unnecessarily would delay the Court's public interest determination regarding the RPFJ. See U.S. Memorandum at 74-78. The Litigating States' hearing is scheduled to begin on March 11, 2002. The parties there have proposed between 170 and 300 hours of total testimony in that case. See Joint Status Report 2, No. 98-CV-1233 (Feb. 13, 2002). Although the Court has indicated that the proposed length is far longer than it expected or believes is reasonably necessary, the Court has not yet determined the precise format or length of that hearing. See Tr. 2/15/02 at 26-27, No. 98-CV-1233. In all likelihood, the hearing could last several weeks.

51. All of these proposals stand to delay consideration, and entry of, the RPFJ by the Court. Delay of this nature, which will not result in the Court hearing more or better information about the settlement, is not only unnecessary but also subverts one of the primary goals of both the RPFJ and the Tunney Act—prompt relief.^[58] The Court therefore should not postpone entry of the RPFJ.

D. Standard of Review Under The Tunney Act^[59]

52. Numerous comments address the standard of review applicable under the Tunney Act to the RPFJ.^[60] These comments range from brief references to the language of the Tunney Act^[61] to lengthy discourses on the correct standard citing legislative history, case law, and treatises.^[62]

53. These comments have at least three overriding themes. First, most agree, citing Microsoft, that the correct standard for relief is to unfetter a market from anticompetitive conduct, terminate the illegal monopoly, deny to the defendant the fruits of its illegal conduct, and ensure that no practices remain likely to result in monopolization in the future.^[63] Second, most argue that, because of the procedural posture of the case, the judgment of the United States in agreeing to the RPFJ as an appropriate resolution of the charges it brought and the case it proved is due little or no deference.^[64] And finally, many argue, again because of the procedural posture of the case, that the District Court is required to apply a more stringent review, and even entitled to fashion its own relief based upon an independent review of the record.^[65] Although the commentors correctly identify the relevant standard of relief set forth by the Court of Appeals, they are incorrect in concluding that the procedural posture of the case eliminates any need for deference to the judgment of the United States or justifies a court-created remedy. In essence, these commentors argue that the Court of Appeals' mandate precluded the possibility of a negotiated settlement. It did not. The Court of Appeals recognized that even a litigated remedy should be “tailored to fit the . . . drastically altered scope of Microsoft's liability . . . .”Microsoft, 253 F.3d at 107. As explained in the U.S. Memorandum, and below in Sections IV through XII, the RPFJ fits that altered scope of liability.

1. The Tunney Act Requires That Entry of the RPFJ Be “In the Public Interest”

54. As noted by the United States in its CIS and by virtually all commentors remarking on the issue, the Tunney Act requires that the Court determine whether entry of the RPFJ is “in the public interest.” 15 U.S.C. 16(e). In making that determination, the Court may consider:

(1) the competitive impact of such judgment, including termination of alleged violations, provisions for enforcement and modification, duration or relief sought, anticipated effects of alternative remedies actually considered, and any other considerations bearing upon the adequacy of such judgment;

(2) the impact of entry of such judgment upon the public generally and individuals alleging specific injury from the violations set forth in the complaint including consideration of the public benefit, if any, to be derived from a determination of the issues at trial.

Id. (emphasis added). As is apparent from the permissive language of the statute, these factors for consideration are discretionary.^[66]

55. In determining whether the RPFJ is in the public interest, the Court may properly consider whether “the remedies [are] so inconsonant with the allegations charged as to fall outside of the ‘reaches of the public interest.’ ”United States v. Microsoft Corp., 56 F.3d 1448, 1461 (D.C. Cir. 1995) (“Microsoft I”) (internal citations omitted). In Microsoft I, and again in Massachusetts School of Law at Andover, Inc. v. United States, 118 F.3d 776 (D.C. Cir. 1997) (“MSL”), the D.C. Circuit explained that this inquiry entails consideration of four specific factors:

The district court must examine the decree in light of the violations charged in the complaint and should withhold approval only [1] if any of the terms appear ambiguous, [2] if the enforcement mechanism is inadequate, [3] if third parties will be positively injured, or [4] if the decree otherwise makes “a mockery of judicial power.” See [Microsoft I, 56 F.3d] at 1462.

MSL, 118 F.3d at 783.^[67]

56. The requirements of an antitrust remedy are familiar. As the Court of Appeals noted in remanding this case:

A remedies decree in an antitrust case must seek to “unfetter a market from anticompetitive conduct,”Ford Motor Co.[ v. United States], 405 U.S. [562, ] 577 [(1972)], to “terminate the illegal monopoly, deny to the defendant the fruits of its statutory violation, and ensure that there remain no practices likely to result in monopolization in the future,”United States v. United Shoe Mach. Corp., 391 U.S. 244, 250 . . . (1968); see also United States v. Grinnell Corp., 384 U.S. 563, 577 . . . (1966).

253 F.3d at 103.

57. The Court of Appeals also emphasized, however, that the “ ‘[m]ere existence of an exclusionary act does not itself justify full feasible relief against the monopolist to create maximum competition.’ ”Id. at 103 (quoting 3 Antitrust Law¶ 650a, at 67). The scope of the remedy must be clearly related to the anticompetitive effects of the illegal conduct. Microsoft I, 56 F.3d at 1460 (quoting International Salt Co.v. United States, 332 U.S. 392, 401 (1947)). Although an antitrust conduct remedy is not limited to enjoining precisely the conduct found to be unlawful, e.g., United States v. Hartford-Empire Co. v. United States, 323 U.S. 386, 409 (1945); ATT, 522 F. Supp. at 150 n.80, nevertheless “the remedies must be of the “same type or class” as the violations, and the court is not at liberty to enjoin “all future violations of the antitrust laws, however unrelated to the violations found by the court.’ ”Microsoft I, 56 F.3d at 1460.^[68]

2. The Court Should Grant Deference to the Judgment of the United States

58. Commentors assert that the current procedural posture of the case, after trial and affirmance on appeal, eliminates any need for deference to the judgment of the United States. Commentors urge the Court to undertake an independent review of the record, and even substitute a litigated remedy for that of the RPFJ. Such a result is inconsistent with the purposes and intent of the Tunney Act.

59. As explained in the U.S. Memorandum, the Court's assessment of the adequacy of the RPFJ must take into account the risks and uncertainties of further litigation that would be required before there could be an adjudicated final judgment, safe from further challenge on appeal, that would remedy the anticompetitive harm attributable to conduct found to violate the Sherman Act. See U.S. Memorandum at 45-46. The Court of Appeals explained in Microsoft I that it is “inappropriate for the judge to measure the remedies in the decree as if they were fashioned after trial. Remedies which appear less than vigorous may well reflect an underlying weakness in the government's case, and for the district court to assume that the allegations in the complaint have been formally made out is quite unwarranted.”Id. at 1461.^[69]

60. This case does differ from Microsoft I in that there have been both findings of fact and conclusions of liability affirmed on appeal. But the difference is one of degree, not kind. Although the Court of Appeals in this case affirmed the District Court's judgment of liability for monopoly maintenance, it emphasized that neither it, nor the District Court, had so far found “a causal connection between Microsoft's exclusionary conduct and its continuing position in the operating systems market,” 253 F.3d at 106-07, sufficient to justify structural relief (although it did not rule out the possibility that the District Court would find such a connection on remand).^[70] Moreover, the Court of Appeals vacated the District Court's judgment of liability with respect to tying, id. at 84 (leaving open the possibility of further litigation on remand), and reversed as to attempted monopolization, id. at 80-84; it also limited the scope of the conduct found to constitute illegal monopolization, reversing on 8 of the 20 acts found by the District Court. The remedy ultimately imposed on remand, the Court of Appeals directed, “should be tailored to fit the wrong creating the occasion for the remedy.”Id. at 107.

61. In the absence of a settlement, therefore, the United States would face the prospect of extended litigation with respect to the numerous issues related to relief in this case. An appeal likely would follow the conclusion of the proceedings in the District Court. Microsoft also might choose to seek Supreme Court review of the Court of Appeals' decision affirming its liability for monopolization. See Petition for a Writ of Certiorari, No. 01-236 (listing issues for future petition). Despite the Findings of Fact and Conclusions of Law, and despite the Court of Appeals' affirmance of a number of the holdings, including liability for monopolization, the ultimate outcome of continued litigation is uncertain, and the path of litigation would be both risky and costly in terms of resources that might otherwise be devoted to other antitrust enforcement concerns.^[71]

62. Thus, although the litigation risks the United States faces here are not identical to the litigation risks it faces when it negotiates a settlement prior to trial, the teaching of Microsoft I remains applicable. The District Court's evaluation of the RPFJ is properly informed by the public interest in a certain and timely remedy for Microsoft's unlawful conduct and must take account of the uncertainties and risks of further litigation, an inquiry that properly respects the realistic choices the United States faced in deciding to settle the case on the negotiated terms of the RPFJ.

63. Moreover, in making its determination, the District Court properly accords significant weight to the United States' predictive judgments as to the efficacy of remedial provisions. Indeed, such deference is proper even outside the consent decree context. See Ford Motor Co, v. United States, 405 U.S. 562, 575 (1972) (“once the Government has successfully borne the considerable burden of establishing a violation of law, all doubts as to the remedy are to be resolved in its favor”) (quoting United States v. E.I. du Pont de Nemours Co., 366 U.S. 316, 334 (1961)). Similarly, it is proper to defer to the United States as representative of the public interest when the parties are requesting entry of an agreed-upon judgment.^[72]

64. As the Court of Appeals has explained, the degree of deference the trial court gives to “the government's predictions as to the effect of the proposed remedies” in a Tunney Act proceeding may vary with the extent of the court's familiarity with the market and other factors. Microsoft I, 56 F.3d at 1461. But, as the Court of Appeals also emphasized, even a court that has extensive relevant expertise should not lightly reject the government's predictions. For example, in the case of the ATT decree—“a decree the oversight of which had been the business of a district judge for several years,”Microsoft I at 1460—the Court of Appeals instructed that the district court should not reject an agreed-upon modification of the decree unless the court had “ ‘exceptional confidence that adverse antitrust consequences [would] result—perhaps akin to the confidence that would justify a court in overturning the predictive judgments of an administrative agency.’ ”Id. (quoting United States v. Western Elec. Co., 993 F.2d 1572, 1577 (D.C. Cir. 1993)). Indeed, if courts do not give appropriate deference to the United States' views,Tunney Act proceedings will become equivalent to the proceedings that lead to adjudicated judgments with adjudicated remedies.

65. Commentors are also incorrect in their assertion that the procedural posture of the case requires the District Court to fashion and impose an adjudicated judgment. The District Court's role in making this public interest determination differs from its role in formulating an adjudicated judgment. Because the District Court “is evaluating a settlement, it is not as free to exercise its discretion in fashioning a remedy,”ATT, 552 F. Supp. at 151, as it would be in a case litigated to an adjudicated judgment. The District Court is not “empowered to reject [the remedies sought] merely because [it] believe[s] other remedies [are] preferable.”Microsoft I, 56 F.3d at 1460. In this procedural setting, the District Court's “function is not to determine whether the resulting array of rights and liabilities “is the one that will best serve society,” but only to confirm that the resulting settlement is “ ‘within the reaches of the public interest.’ ”Id. (quoting United States v. Western Elec. Co., 990 F.2d 283, 309 (D.C. Cir. 1990) (“Triennial Review Opinion”) (emphasis in original), in turn quoting United States v. Bechtel Corp., 648 F.2d 660, 666 (9th Cir. 1981), in turn quoting United States v. Gillette Co., 406 F. Supp. 713, 716 (D. Mass. 1975)).

66. This standard reflects not only the proper role of a court of equity asked to lend its authority to the parties' agreement, but also the critical role that consent decrees play in effective public antitrust enforcement. See Senate Report at 5 (“the consent decree is of crucial importance as an enforcement tool, since it permits the allocation of resources elsewhere”); 119 Cong. Rec. 24,600 (1973) (Statement of Sen. Gurney) (Tunney Act “is designed to enhance the value and effectiveness of the consent decree as a tool of public policy”). A consent decree, such as the RPFJ, is the product of negotiation. The parties weigh the benefits of prompt and certain resolution of the case against the possibility that continued litigation might improve their respective positions. Settlements potentially offer the public the benefits of more timely and certain relief, as well as significant savings in judicial and prosecutorial resources. But if courts refused to enter any consent decree that did not match precisely the relief the court would have imposed in the absence of a settlement, “defendants would have no incentive to consent to judgment and this element of compromise would be destroyed. The consent decree would thus as a practical matter be eliminated as an antitrust enforcement tool, despite Congress' directive that it be preserved.”ATT, 552 F. Supp. at 151.

67. Thus, even in the ATT case, a case of unparalleled public importance in which the trial court had unusual familiarity with both the evidence and the legal arguments of the parties, see id., the court determined to approve the parties' settlement “[i]f the [proposed] decree meets the requirements for an antitrust remedy.”Id. at 153. The court made clear that it intended to follow that standard whether or not the proposed decree corresponded to the decree the court itself would have imposed had the parties pushed forward to an adjudicated judgment. See id. at 166 n.147 (noting that if the case “were to proceed to final judgment and liability were found, the Court might determine that [certain measures not part of the proposed decree] are appropriate remedies, either as alternatives to the divestiture of the Operating Companies or in addition to such divestiture”).

E. Microsoft's Compliance With Section 16(g)

68. Several comments question whether Microsoft made adequate disclosures under 15 U.S.C. 16(g).^[73] At the February 8, 2002, Status Conference, the Court directed Microsoft to brief the issue of its compliance with Section 16(g), and expressed its assumption that this issue was one that “the government isn't necessarily going to be commenting on, but it is something that is [Microsoft's] responsibility.”^[74] The United States therefore supplies the following information concerning the purpose of the disclosures required pursuant to Section 16(g), but does not respond to the substance of the comments that question Microsoft's compliance with the requirements of Section 16(g).

69. The Tunney Act treats disclosure requirements intended to inform public comment regarding a proposed consent judgment entirely separately from the other disclosure requirements set forth in the Act. To facilitate public comment on a proposed consent judgment in a government civil antitrust case, the Tunney Act provides, in a single subsection, that the proposed decree itself must be published in the Federal Register, along with a CIS, which the United States must furnish to any person requesting it. 15 U.S.C. 16(b). In addition, that same subsection requires the United States to file in the Tunney Act district court, and any other district court the Tunney Act court designates, copies of the proposed decree and “any other materials and documents which the United States considered determinative in formulating such proposal.”Id. But the Tunney Act does not depend solely on the Federal Register to inform the public. The next subsection, 15 U.S.C. 16(c), requires the United States to publish, repeatedly, summaries of the proposal and the CIS, together with a list of the determinative documents made available for “meaningful public comment,” in general circulation newspapers.

70. By contrast, the lobbying provision at issue here, Section 16(g), merely requires defendants in antitrust cases to file their disclosure statements with the Tunney Act court—there are no requirements of public notice, Federal Register publication, newspaper summaries, or distribution to other district courts. Moreover, the statutory provisions addressing disclosure of information supporting informed public comment (Sections 16(b), (c)), appear immediately before the provisions dealing with consideration of, and response to, public comment (Section 16(d)) and the court's public interest determination (Sections 16(e), (f)). The lobbying provision comes after all of those Sections. The statutory structure thus makes clear the different purposes of the two different kinds of disclosure provisions.^[75] Thus, even if Microsoft failed to satisfy the requirements of Section 16(g), that would not provide any basis to begin the comment period anew and further delay entry of the RPFJ.^[76]

III. Definitions

A. Definition of “ISV” (RPFJ § VI.I)

71. Several comments address Section VI.I, which defines “ISV” as “an entity other than Microsoft that is engaged in the development or marketing of software products.” All of the comments concern the breadth of the definition.

72. Several commentors misread the definition, contending that “ISV” inappropriately covers only companies creating software that runs on Windows Operating System Products.^[77] The definition shows on its face that this concern is misplaced: any “software product” is covered, whether or not it runs on Windows.

73. Several commentors suggest expanding the definition of “ISV” explicitly to include developers of particular categories of products. One commentor worries that Microsoft could construe the definition to exclude developers or marketers of non-Microsoft operating systems, and suggests that the definition be modified to include them explicitly.^[78] Another worries that the definition does not clearly encompass developers of software products designed to run on new versions of Windows or on other next-generation devices, and that it excludes vendors of competing servers.^[79] These concerns are misplaced and, therefore, the proposed modifications are unnecessary. The RPFJ defines “ISV” to include developers or marketers of “software products,” and that very broad category of products unambiguously includes operating systems (including server operating systems), operating system products (including server operating system products), and software designed to run on any platform on any device.

74. Other commentors express concern that individuals, particularly individual developers writing and trading code within the “open source” community, might not qualify as “entities” and so might not qualify as “ISVs” under Definition VI.I.^[80] The RPFJ, however, sets no minimum size or organizational standard for an “entity.” Any individual or group of individuals, whether incorporated or not, that otherwise meets the definition of “ISV” is considered to be an ISV within the meaning of the RPFJ.

B. “Microsoft Middleware” (RPFJ § VI.J)

75. Many commentors criticize the RPFJ definition of Microsoft Middleware. Occasionally, a commentor simply fails to realize which middleware definition, Microsoft Middleware Product or Microsoft Middleware, is used in a given section.^[81] To review, Microsoft Middleware Product describes functionality and products, as an end user might perceive them. This definition is used in Sections III.C and III.H, as well as indirectly, via the Microsoft Platform Software definition, in Sections III.A, III.F and III.G.

76. In contrast, the Microsoft Middleware definition describes software code, and is only used in Sections III.D and III.G. Most commentors focus on its use in Section III.D concerning API disclosure. The reason Microsoft Middleware is directed at software code and not functionality is that it is difficult to take any given piece of functionality and identify exactly which pieces of software code correspond to that functionality. For instance, a word processor displays text on a screen, and that is a functionality that the end user associates with the word processor. The software code that draws characters on the screen, however, is driven largely by code that many would consider part of the operating system. The word processor uses some of its own software code and some of the operating systems services to make the functionality appear to the user. Therefore, to avoid confusion and disagreements over which software code corresponded to which functionality, the United States designed a software code-based definition for use in Section III.D.

77. In response to comments, two of the specific requirements of the Microsoft Middleware definition have been changed in the SRPFJ to more clearly reflect the parties' intent. Each requirement and any associated modifications are discussed individually below. For reference, the complete revised definition is as follows:

RPFJ Section VI.J. “Microsoft Middleware” means software code that

1. Microsoft distributes separately from a Windows Operating 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 defined in Section VI.K.1; and

3. provides the same or substantially similar functionality as a Microsoft Middleware Product.

Microsoft Middleware shall include at least the software code that controls most or all of the user interface elements of that Microsoft Middleware.

Software code described as part of, and distributed separately to update, a Microsoft Middleware Product shall not be deemed Microsoft Middleware unless identified as a new major version of the Microsoft Middleware Product. A major version shall be identified by a whole number or by a number with just a single digit to the right of the decimal point.

1. Distributed Separately To Update a Windows Operating System Product

78. Some commentors argue that it is inappropriate for Microsoft Middleware to depend on separate distribution from a Windows Operating System Product.^[82] They argue that there is no logical reason for such a distinction and that requiring separate distribution merely provides another way for Microsoft to avoid its disclosure requirements.

79. The definition requires separate distribution for two reasons. First, there must be a straightforward and enforceable way to determine which software code is implicated. Separate distribution provides a clear line between two segments of code. Moreover, interfaces between pieces of code that have never been distributed separately are more likely to be internal interfaces that are not tested or durable. In contrast, interfaces between separately distributed pieces of code are more often tested and durable, because there is always the risk that the other side of the interface will be a different version than expected. Interfaces that are not tested and durable may be unreliable, potentially resulting in malfunctions.

80. Second, the competitive significance of middleware products such as browsers and media players will be relatively small if they are never distributed in any form separate from a Windows Operating System Product. If Microsoft chooses only to distribute its programs by including them in Windows, then it will not be able to reach the large installed base of Windows machines. Instead, Microsoft will only be able to offer new versions when users choose to upgrade their operating system or buy new computers. Competing middleware products, in contrast, would not be limited to such methods of distribution and might offer many new versions over the course of the two to three year hardware upgrade cycle. Thus, while a competitor might offer three new versions of its program every year, Microsoft only would be able to offer a single version every two to three years. In the past, with programs such as Internet Explorer, Windows Media Player, and Windows Messenger, Microsoft always has offered separate versions available for download.

81. Commentors point to specific products that have never been distributed separately and argue thatthey should be included. Several commentors point out that Windows Media Player 8, sometimes referred to as Windows Media Player for Windows XP, is only included in Windows XP and that the interfaces between this player and the operating system will not be disclosed.^[83] This is correct. However, the interfaces between Windows Media Player 7.1, the latest version available for download or redistribution, will be disclosed. While there may be some unique interfaces that Windows Media Player 8 uses to call on services in Windows XP, the United States is not aware of any such interfaces that are not also in Windows Media Player 7.1. Thus, for example, the API for a digital rights management technology called Secure Audio Path is a key interface used by Windows Media Player 7.1 and thus will be disclosed. Moreover, if Windows Media Player 8 is ever distributed separately in the future, then its interfaces would be disclosed.

82. Other commentors argue that Active Directory, a Microsoft directory service, should be Microsoft Middleware, but it does not qualify because it has never been distributed separately from a Windows Operating System Product.^[84] As this commentor notes, however, directory services “have become competitively critical links between the desktop and network computing.”^[85] Accordingly, directory services are most protected under Section III.E, which addresses the licensing of Communications Protocols used natively by Windows Operating System Products to interoperate with Microsoft server operating system products. For instance, if Active Directory software is included natively in Windows XP and that software uses a Communications Protocol to communicate with a Windows 2000 server, then the Communications Protocol must be available for license. Thus, a competing active directory service could license and implement the Communications Protocol and communicate with Windows XP using the same method as Active Directory.

2. Trademarked or a Major Version of Any Microsoft Middleware Product

83. The second requirement for Microsoft Middleware is that the software code either be Trademarked or marketed by Microsoft as a major version of any Microsoft Middleware Product as defined in Section VI.K.1. This is a modification reflected in the SRPFJ that differs from the RPFJ version, which required that software satisfy the Trademark requirement in order to be considered Microsoft Middleware. The SRPFJ modification means that software can now satisfy this element of the definition by being either (1) Trademarked, or (2) marketed as a major version of any of the named Microsoft Middleware Products as defined in Section VI.K.1 (i.e., Internet Explorer, Microsoft's Java Virtual Machine, etc.).

84. Many commentors argue that the Trademarked requirement is inappropriate, or that at a minimum, many existing Microsoft Middleware Products would not have any corresponding Microsoft Middleware code.^[86] Turning to the latter, several argue that products such as Internet Explorer, Windows Media Player, Microsoft's Java Virtual Machine, and Window Messenger arguably were not Trademarked as that term is defined in the RPFJ, or argue that the Trademarked requirement was not appropriate. The United States does not necessarily agree with any or all of these arguments concerning whether these particular products satisfied the definition of Trademarked. To clarify any issues surrounding the status of these products, however, the Microsoft Middleware definition was modified to include explicitly the software code that is marketed by Microsoft as a major version of any Microsoft Middleware Product under VI.K.1. The limitation in the modified language to a major version of a Microsoft Middleware Product is simply a restatement of the limitation in the last paragraph of the definition, discussed further below, which limits the covered software code to that identified as a major version of a Microsoft Middleware Product. This change should resolve many of the concerns raised. Under the revised definition, each Microsoft Middleware Product discussed by commentors has corresponding Microsoft Middleware.

85. Other commentors argue that inclusion of the Trademarked requirement has no relation to the function of the software code and should not be part of the Microsoft Middleware definition. The requirement that the software code satisfy the Trademarked definition is based on the business reality that Microsoft develops logos and names for marketing the technologies that it wishes developers and consumers to adopt. Software code that is not marketed under a distinctive logo or a name that satisfies the definition of Trademarked is unlikely to achieve the widespread usage needed for competitive significance. Additionally, this definition was not intended to capture security patches, minor “bug” fixes, or other small downloads that Microsoft makes available via Windows Update. Limiting the covered software code to that which is Trademarked or marketed as a major version of a Microsoft Middleware Product under Section VI.K.1 ensures that code not comprising a “product,” as that term is generally understood by the public, will not be included.

3. Same or Substantially Similar Functionality

86. Some commentors opine that Microsoft Middleware should not be required to have the same or substantially similar functionality as a Microsoft Middleware Product. Microsoft Middleware Products, as defined, include only products distributed with a Windows Operating System Product. Commentors argue that software that comes under some concept of middleware should be included, regardless of whether it is the same or substantially similar to a Microsoft Middleware Product. For instance, some commentors argue that Microsoft Office should be Microsoft Middleware, and the interfaces between Office and a Windows Operating System Product should be disclosed.^[87]

87. The focus of the plaintiffs' case was never Internet Explorer or middleware technologies that were only distributed separately; the focus was always on applications that were both integrated into Windows and distributed separately. One of the reasons that Microsoft's anticompetitive actions were able to have the effect that they did was that they covered multiple distribution channels. Internet Explorer and Microsoft's Java Virtual Machine were bundled with Windows, and they were included in the “First Wave” contracts with ISVs covering separately distributed products, and they were available for separate download.

88. The disclosure of interfaces between software that is not the same or substantially similar to functionality distributed with a Windows Operating System Product is beyond the scope of the case as it emerged from the Court of Appeals. For example, even assuming arguendo that Office has some characteristics that make it middleware, Office has never been integrated into Windows or referred to by Microsoft asbeing part of a Windows Operating System Product. Office is a separate product that is purchased separately.

89. Finally, some commentors argue incorrectly that requiring Microsoft Middleware to have the same or substantially similar functionality as a Microsoft Middleware Product encourages commingling of software code.^[88] Commingling of code, as discussed by the Court of Appeals and the District Court, is “placing code specific to Web browsing in the same files as code that provided operating system functions.”Microsoft, 253 F.3d at 65. Products can be distributed with Windows and not have their code commingled with operating system functions. To the contrary, requiring software to be both distributed separately and substantially similar to software distributed with Windows encourages the opposite: because the code must be distributed separately, there must be a clear distinction between code that belongs to the Microsoft Middleware and code that belongs to the operating system. If all the code for a Microsoft Middleware Product is commingled into operating system files, then the separately distributed Microsoft Middleware version will be enormous and constitute a redistribution of the operating system. Clearly, such a separate distribution would be unworkable.

4. Includes at Least the Software Code That Controls Most or all of the User Interface

90. The RPFJ included a fourth requirement, that Microsoft Middleware must include at least the software code that controls most or all of the user interface elements of that Microsoft Middleware. This provision now has been clarified in the SRPFJ such that it is no longer the fourth required element, but is a separate paragraph at the end of the definition. This change reflects the fact that the first three requirements are sufficient to define Microsoft Middleware. The now-separate sentence always was intended to be a minimum size or “floor” as to the collection of software code that is included in a particular piece of Microsoft Middleware. This “floor” prevents Microsoft from arbitrarily breaking up into separate pieces the software code of what would otherwise be Microsoft Middleware, thereby omitting from the Microsoft Middleware definition certain critical or significant pieces of code that constitute the Microsoft Middleware. Some commentors read this provision to mean that Microsoft could create artificially small subsets of code containing only the user interface elements of Microsoft Middleware Products.^[89] Commentors point out that the interfaces between user interface elements and the Windows Operating System Product are unlikely to be competitively significant.^[90] This modification does not substantively change this definition, but instead makes clear that this provision governs the scope of what code must be included in the Microsoft Middleware.

5. Major Updates

91. The last paragraph of Microsoft Middleware discusses software code described as part of, and distributed separately to update, a Microsoft Middleware Product. That code shall be deemed Microsoft Middleware if it is identified by a new major version number, i.e., a whole number (“6.0”) or a by a number with a single digit to the right of the decimal point (“7.1”). Several commentors argue that Microsoft can withhold interfaces simply by updating its products with version numbers such as “7.11” that do not qualify as major versions, and that the major version limitation is inappropriate.^[91]

92. It was necessary to draw a line to include some code updates as Microsoft Middleware and exclude others. Per standard software engineering practices, Microsoft assigns every change to the code a new version number, and the importance of the change is designated by how far to the right the number is. For instance, a tiny change may be designated by an increase from 5.011 to 5.012; a slightly larger change is designated as going from 5.01 to 5.02, and a major version is designated as 5.1 to 5.2. Although Microsoft maintains these version numbers, they are not always advertised to the public because small changes are not advertised as new, improved, or updated products. Rather, products that are significant upgrades that will be promoted to the public are designated with new major version numbers.

93. The United States does not believe that requiring Microsoft continuously to review small changes to its Microsoft Middleware would yield significant competitive effects that would outweigh the costs to Microsoft. Significantly improved features, including those based on better APIs, are most likely to be designated by new major version numbers. Microsoft has little reason to develop a new feature based on improved services from the operating system, such as improved speed or better coordination with other operating system functions, and then not promote that feature to developers or consumers. Moreover, should Microsoft Middleware use a new API in an update that is not a new major version, then that API still will be disclosed, at a minimum, when the next new major version is released. The only way for Microsoft to hide an API indefinitely is to never release a new major version, which historically has not happened and is not likely to happen in the future.

C. “Microsoft Middleware Product” (RPFJ § VI.K)

94. A number of commentors address Section VI.K, which defines “Microsoft Middleware Product.” This definition is referenced in Sections III.C (prohibiting Microsoft from imposing certain restrictions on OEM licensees) and III.H (ensuring OEM flexibility in product offerings) and, as subsumed by Section VI.L's definition of “Microsoft Platform Software,” is also referenced in Sections III.A (prohibiting retaliation against OEMs), III.F (constraining Microsoft's relationships with ISVs), and III.G (prohibiting certain exclusionary contracts). “Microsoft Middleware Product” means either the functionality provided by one of a set of existing, named products (e.g., Internet Explorer) and their successors or, for products that do not now exist, the functionality that meets several specific conditions.

95. Contrary to the views of several commentors, the definition does not limit Microsoft Middleware Products to a set of products that now exist, and so does not fail to account for future development.^[92] This critique ignores the second part of the definition, which explains what future technology will be considered Microsoft Middleware Products. Similarly, there are no limits in the definition on the kinds of products (in the commentor's words, “categories of applications”) that may, in the future, be considered Microsoft Middleware Products.^[93] It thus is inaccurate to state that the Litigating States' proposed definition (Provision 22(x)) of Microsoft Middleware Product applies to products to be developed in the future and the RPFJ does not.^[94]

96. Although the Litigating States' proposed definition of Microsoft Middleware Product is somewhatbroader than the definition in the RPFJ, the United States believes that its definition is clearer and therefore more enforceable. Unlike the Litigating States' list of current products, for example, the RPFJ's list (Section VI.K.1) consists solely of known named products; there is no room to debate, for instance, exactly what “systems and enterprise management software” (Litigating States Provision 22(c)i) is and is not covered.

97. Similarly, the RPFJ's restriction on future products to those that are Trademarked helps clearly to define the set of covered products and reflects the business reality that Microsoft often names and markets the technologies that it wishes developers and consumers to adopt. Microsoft has little incentive to bury its new products inside other applications in order to avoid having it meet the Trademark standard, as one commentor worries.^[95] Some commentors claim that the Trademarked requirement would leave out many Microsoft products currently in the market, but the commentors do not identify any particular product.^[96]

98. The Litigating States object that the definition of Microsoft Middleware Product, as it pertains to future products, excludes software that has not been distributed separately from a Windows Operating System Product or that is not similar to a competitor's product.^[97] The nature of their concern is unclear, however, given that the Litigating States' own definition of Microsoft Middleware Product in their own Proposed Final Judgment contains very similar exclusions.^[98]

99. Some commentors object to the omission of Microsoft Office from the list of existing products that are Microsoft Middleware Products within the meaning of the RPFJ, pointing to Office's status as middleware and its large market share among office suites.^[99] Others object to the omission of other specific products or technologies, e.g., Microsoft Outlook, MSN Messenger, MSN RunTime, MSN Explorer, the MSN client software, Passport, Microsoft Exchange, Microsoft Visual Studio, Microsoft, Net, and software that synchronizes handheld devices with PCs.^[100] The reasons for the omission of these products from the definition vary. Some of these products have never been part of a Windows Operating System Product, but only are installed separately and so logically should not be included in the list of Microsoft Middleware Products (e.g., Microsoft Office, Outlook, handheld synchronization software, Microsoft Visual Studio, Microsoft Exchange). Others, such as Microsoft .Net, are in fact covered as to the elements that products marketed under the .Net label are among the products named in the definition of Microsoft Middleware Product.^[101] And some lack the competitive significance of the products that are included in the list of existing Microsoft Middleware Products (e.g., MSN Explorer, MSN Messenger).

100. The definition of Microsoft Middleware Product goes well beyond the Internet browser and Java technologies that, as threats to the Windows operating system against which Microsoft took anticompetitive actions, were at issue in this case. Further, this definition balances the desire to include future middleware products—the character of which no one can accurately predict—with the need for certainty in compliance and enforcement.

D. “Non-Microsoft Middleware” (RPFJ § VI.M)

101. The definition of Non-Microsoft Middleware is one of the most important definitions in the RPFJ, but it received very little criticism by commentors. Non-Microsoft Middleware is the term used most often to describe the products that the decree is intended to protect. Toward that end, it is one of the broadest definitions in the decree.

102. One criticism, which while serious was based on an inadvertent error, points out that due to the definition of API, on which Non-Microsoft Middleware depends, it might be impossible for any Non-Microsoft software to satisfy the definition.^[102] These commentors point out that the API definition only includes Microsoft APIs, rendering the other definitions that use the term API nonsensical. This was an inadvertent error in the RPFJ, and it has been corrected in the SRPFJ. The previous definition of API has been inserted directly in Section III.D, which was the only section it was designed to address. A generic definition of API, which is intended to invoke the common usage of the term API, and not to be tied to Microsoft products, has been inserted as definition VI.A. The definition now reads: “'API” means application programming interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.”See also Section VII.(A)(2) below.

103. One commentor argues that certain important software categories such as web-based software and digital imaging software are not present in any of the middleware definitions.^[103] This assertion is incorrect, because neither of the Non-Microsoft Middleware definitions use any categories at all; both cover any software functionality that otherwise meets the requirements. Given that these definitions provide the substance of what the decree protects, it would be inappropriate to place any category restrictions, such as digital imaging software, in the definition. In a somewhat similar fashion, one commentor argues that there is no longer any demand for Non-Microsoft Middleware, but bases his argument on browsers, failing to realize that Non-Microsoft Middleware can have any functionality.^[104]

104. One commentor argues that the definition proposed by the Litigating States or the definition from the IFJ would be preferable, but offers no specific criticisms of Non-Microsoft Middleware.^[105] Another commentor suggests that “non-Microsoft software product” be replaced with “non-Microsoft technology” but also states that the definition seems appropriate to define middleware.^[106]

105. One commentor argues that the definition should not be limited to software that runs on Windows Operating System Products, because that limitation leaves Microsoft free to retaliate against middleware software that runs on other devices, such as servers and handhelds.^[107] The intended meaning of this comment is unclear, because the retaliation section of the decree applicable to ISVs and IHVs, Section III.F, does not use the term Non-Microsoft Middleware.

106. Finally, the Non-Microsoft Middleware definition is criticized on the ground that Netscape 1.0 would not have satisfied it, because the earliest version of Netscape did not expose a range of functionality to ISVs through published APIs.^[108] Nevertheless, the United States finds this definition completely appropriate, because it is the presence of APIs that allows middleware to threaten the applications barrier to entry. To remove the requirement for APIs from the definition would be to ignore the theory of thecase.^[109] Moreover, whether or not software has published APIs is completely within the control of the software developer.

E. “Non-Microsoft Middleware Product” (RPFJ § VI.N)

107. Several comments raise issues relating to the definition of Non-Microsoft Middleware Product.^[110] The majority of these comments relate to subsection (ii) of the definition, which requires that “at least one million copies” of the product have been distributed in the United States within the previous year.^[111] Other commentors complain that the definition does not include web-based software.^[112] Finally, one commentor questions whether Netscape Navigator would have satisfied the definition of Non-Microsoft Middleware Product because it does not expose Microsoft APIs.^[113]

108. The RPFJ's provisions apply generally not only to a wide range of currently marketed middleware products, but also to products that have not yet been developed. Certain of these provisions, of course, impose affirmative obligations on Microsoft to take actions vis-a-vis middleware products. To ensure that Microsoft can undertake these obligations in compliance with the RPFJ's provisions (and that the United State can enforce them), the characteristics of what products will be considered middleware in the future must be defined today according to objective criteria. The definition of Non-Microsoft Middleware Product relates and is incorporated into the portion of the definition of Microsoft Middleware Product that sets forth the characteristics that future products must meet to be considered Microsoft Middleware Products.

109. The one-million-copy limitation applies only to the affirmative obligations that Microsoft make public the APIs used in its own middleware products (as set forth in Section III.D), and redesign the operating system to provide a competing middleware product “default” status, i.e., the ability to override automatically Microsoft middleware functions integrated into the operating system (as set forth in Section H). The limitation strikes the proper balance between (1) the substantial costs associated with such documentation and redesign efforts, which these obligations require and (2) the competitive potential of products with fewer than one million copies distributed. In a nutshell, it prevents Microsoft from having to undertake documentation and redesign work any time an ISV has a concept for a product it decides to call “middleware.” In a world of about 625 million PC users and software distribution via downloads and direct mail, distribution of only one million copies, rather than sales, installation or usage, is a relatively minor threshold in the software industry today. Indeed, almost ten years ago the Mosaic browser achieved distribution to over 2 million people in “just a year.” Gina Smith, Inside Silicon Valley, A High-Tech Top 10 Computers Technology, San Francisco Examiner, 1995 WL 4901748 (Jan. 1, 1995).

110. Web-based software and web-based services are not explicitly excluded from the definition of Non-Microsoft Middleware Product. Any portion of web-based software or services that runs on a Windows Operating System Product and otherwise meets the requirements of the definition could qualify as a Non-Microsoft Middleware Product. To the extent that any Microsoft software natively implemented in a Windows Operating System Product communicates natively with a Microsoft server operating system product, the Communications Protocols must be available for license pursuant to Section III.E.

111. Finally, the suggestion that Netscape Navigator could not satisfy the definition of Non-Microsoft Middleware Product in the RPFJ, because Navigator does not expose Microsoft APIs, is correct where the erroneous definition of API contained in the RPFJ is applied. Based on comments that correctly identified a flaw in the definition of API, however, the United States and Microsoft have agreed to modify the definition. See Section VII(A)(2) below. Under the new definition of API in the SRPFJ,^[114] Netscape Navigator would qualify as a Non-Microsoft Middleware Product.

F. “Personal Computer” (RPFJ § VI.Q)

112. A few commentors raise concerns about the RPFJ's definition of “Personal Computer.”^[115] See RPFJ § VI.Q. This definition is referenced in RPFJ Sections III.A (prohibiting retaliation against OEMs) and III.H (ensuring OEM flexibility in product offerings), and in Definitions VI.H (“IHV”), VI.O (“OEM”), VI.P (“Operating System”), and VI.U (“Windows Operating System Product”).

113. One commentor argues that the definitions of “Personal Computer” and “Windows Operating System Product” might, when read together, unintentionally exclude future Microsoft operating systems from the RPFJ's provisions. The commentor expresses concern that the restriction of “Personal Computer” to a computer “configured so that its primary purpose is for use by one person at a time” would, in combination with the restriction of “Windows Operating System Product” to software distributed “for use with Personal Computers,” cause future Microsoft operating systems not to be covered by the RPFJ if Microsoft continues its evolution toward operating systems—like Windows XP—that facilitate shared or multiple-person use or that facilitate home networking.^[116] This concern is unwarranted. What Windows XP allows is for different users of the same computer (e.g., members of the same family) to store individualized settings in the computer and access them through personal passwords. Whether or not a computer is configured primarily to facilitate use by different people at different moments in time is immaterial to whether it is configured primarily to be used by one person at a given moment in time—the relevant criterion for its designation as a Personal Computer in the RPFJ.

114. Several commentors question the exclusion of machines made by Apple Computer from the definition of “Personal Computer.”^[117] Apple's machines do not contain “Intel x86 compatible (or successor) microprocessors,” and so do not fall within the meaning of the definition. Indeed, Apple computers were expressly excluded from the relevant market in which Microsoft was found to be a monopolist. See Microsoft, 253 F.3d at 52. The sole conduct that the United States alleged, and the Court of Appeals found, to be unlawful relating to Apple computers was the exclusive dealing arrangement that Microsoft imposed on Apple. See id. at 74. Section III.G.1 ofthe RPFJ fully addresses this conduct by prohibiting such exclusive arrangements with certain entities, including ISVs—a category that unquestionably includes Apple. Modifying the definition of Personal Computer to include Apple computers would improperly expand the scope of the RPFJ beyond the liability findings in this case.

115. Other commentors raise concern about the final sentence in Section VI.Q,^[118] which reads: “Servers, television set top boxes, handheld computers, game consoles, telephones, pagers, and personal digital assistants are examples of products that are not Personal Computers within the meaning of this definition.” One commentor appears to suggest that any such devices for which Microsoft eventually offers a version of a Windows Operating System Product should be considered Personal Computers for purposes of the RPFJ.^[119] The United States disagrees with the commentors' views that any change to expand application of the RPFJ to software written for, for example, telephones and pagers, is justified by the Court of Appeals' decision in this case, which is limited to the illegal maintenance by Microsoft of its monopoly in operating systems for Intel-compatible PCs.^[120] Moreover, such a change would be inconsistent with the intent of the RPFJ to identify Personal Computers with clarity because it would create unmanageable circularity: a Personal Computer would be a machine for which a Windows Operating System Product is available, and a Windows Operating System Product would be a product designed for use with a Personal Computer.

G. “Trademarked” (RPFJ § VI.T)

116. A number of commentors address the scope of the definition of “Trademarked” in the RPFJ.^[121] Most of these commentors suggest that the definition is too broad and would permit Microsoft to evade its disclosure obligations under the RPFJ by manipulating its use of trademarks.^[122] Several commentors complain that basing the determination of whether a product is either Microsoft Middleware or a Microsoft Middleware Product on whether the product has been Trademarked is inappropriate because it permits Microsoft to manipulate the application of the middleware definitions to its products.^[123]

117. The definition of Trademarked is designed to ensure that the Microsoft Middleware and Microsoft Middleware Products that Microsoft distributes (either for free or for sale) to the market as commercial products are covered by the RPFJ. Thus, the definition of Trademarked correctly describes the manner in which businesses typically identify the source of the products that they distribute in commerce, while seeking to carve out from the definition products, such as “bug” fixes, that might be distributed under the Microsoft® or the Windows® names but that are not of commercial significance.

118. Several commentors argue that the exception for generic or descriptive terms contained in the Trademarked definition is a significant loophole that will permit Microsoft to exempt many products from coverage by the RPFJ.^[124] The exception for generic and descriptive terms, however, simply reflects the reality that products distributed in commerce under such names may not be trademarked unless the names develop secondary meaning. Under the Trademarked definition, Microsoft simply announces in advance that it will not claim such terms as trademarks and, therefore, that such terms never will gain secondary meaning. It is for precisely this reason that any product distributed in commerce under, or identified by, marks that consist of any combination of generic or descriptive terms and a distinctive logo or other stylized presentation are not exempted from coverage as Trademarked, because such marks are inherently distinctive.

119. At least one commentor suggests that the portion of this definition relating to Microsoft's disclaimer of certain trademarks or service marks, and its abandonment of any rights to such trademarks or service marks in the future, conceivably operates to remove automatically trademark protection from marks that Microsoft already has registered but that also fall within this description.^[125] But this portion of the definition of Trademarked does not operate in that manner. Instead, this clause is designed to ensure that, to the extent that Microsoft distributes a product in commerce under generic or descriptive terms or generic or descriptive terms in combination with either the Microsoft® or the Windows® name and claims on that basis that such product does not fall within the definition of Microsoft Middleware or Microsoft Middleware Product, it will be unable to claim trademark protection for such marks in perpetuity.

H. “Windows Operating System Product” (RPFJ§ VI.U)

120. Definition U defines “Windows Operating System Product” to mean “the software code . . . distributed commercially by Microsoft for use with Personal Computers as Windows 2000 Professional, Windows XP Home, Windows XP Professional, and successors to the foregoing. . . .” In general terms, the term refers to Microsoft's line of “desktop” operating systems, as opposed to its server or other operating systems. Windows Operating System Product applies to software marketed under the listed names and anything marketed as their successors, regardless of how that software code is distributed, whether the software code is installed all at once or in pieces, or whether different license(s) apply.

1. Microsoft's Discretion

121. Various comments address the final sentence of Definition U, which reads: “The software code that comprises a Windows Operating System Product shall be determined by Microsoft in its sole discretion.” Some of the comments assert, incorrectly, that permitting Microsoft the discretion to determine what package of software is labeled as a “Windows Operating System Product” for purposes of the RPFJ will allow Microsoft to re-label as part of the “Windows Operating System Product” code that would otherwise be middleware and thereby avoid having that code constitute “Microsoft Middleware” or provide the functionality of a “Microsoft Middleware Product” under the RPFJ.^[126] Microsoft could, these commentors hypothesize, essentially “decide for purposes of the decree obligations where the OS stops and where middleware begins,”^[127] and thereby evade the decree's technicalprovisions, including the disclosure provisions of Section III.D^[128] or the removal provisions of Section III.H.

122. These comments are incorrect. Microsoft's discretion under Definition U as to its packaging decisions (i.e., what it chooses to ship labeled as “Windows”) does not give it the ability to exclude software code from the application of any other relevant definition of the RPFJ. Thus, nothing in Definition U alters the fact that, under the RPFJ, software code that Microsoft ships labeled as “Windows” can also constitute “Microsoft Middleware” or a “Microsoft Middleware Product.” So long as software code or the functionality it provides meets the requirements of any other definition(s) in the RPFJ, Microsoft's “discretion” under Definition U to call it part of a Windows Operating System Product will not change the result.^[129] Thus, for example, Internet Explorer is both a Microsoft Middleware Product and part of a Windows Operating System Product.

123. A number of commentors also assert that the final sentence of Definition U might be read to transform what otherwise would be two separate products for antitrust purposes into one, or somehow to immunize Microsoft from potential liability for illegal tying.^[130] Such a reading is untenable. Nothing in this provision, or in the RPFJ as a whole, purports to, or could, alter the application of the antitrust laws to Microsoft's conduct or its products. In particular, the RPFJ does not grant Microsoft any new rights or any immunity under the antitrust laws with respect to otherwise illegal tying or product integration. Similarly, Microsoft's decision to distribute certain software code as part of a Windows Operating System Product for purposes of this definition does not in any way affect the status or characterization of such code under the antitrust laws or the application of those laws to such code—e.g., whether software Microsoft says is part of the package it distributes as its “Windows Operating System Product” is or is not a separate “product” for antitrust purposes.

2. Prior Windows Versions

124. A few commentors^[131] suggest that Definition U. also should include—in addition to the software code Microsoft distributes as Windows 2000 Professional, Windows XP Home and Professional, and their successors—prior versions of Windows, including Windows 9x (Windows 95, Windows 98, Windows 98 Second Edition, and Windows ME) and Windows NT 4.0. These Microsoft operating systems were not included in the RPFJ's definition of Windows Operating System Product because their current commercial and competitive significance is significantly more limited than the operating systems included in the definition. For example, Windows 95, as its name suggests, was first shipped by Microsoft some seven years ago and is no longer actively distributed by Microsoft, while Windows 98 and 98 Second Edition will soon enter a phase of restricted availability.^[132] Windows Millennium Edition (ME), though much more recent, has enjoyed only limited success and already has been supplanted as Microsoft's primary OS by Windows 2000 and Windows XP, both of which are covered by Definition U.

125. The OEM-related provisions of the RPFJ, including Sections III.A, III.B, III.C, and III.H, apply primarily to OEMs' ongoing shipments of Microsoft operating systems with their new PCs, not to the installed base, and the great majority of those shipments today and going forward will be Windows 2000, Windows XP, and successors. Further, the provisions of Sections III.D and III.H, which require certain technical or design changes by Microsoft to its Windows Operating System Products, are relevant largely to OEM and consumer choices regarding operating systems that will be shipped under the RPFJ, rather than the installed base of operating systems that have already been distributed. Finally, the disclosure provisions of Section III.D are likely to have the greatest competitive significance for Windows 2000 and Windows XP and their successors, because those operating systems represent the versions of Windows to which the great majority of developers are likely to write middleware or applications. Going forward, developers are unlikely to write middleware or applications to any significant degree to the older, 9x operating systems, because those versions are built on a different code base than that underlying Windows 2000, Windows XP, and future versions of Windows.

3. Operating Systems for Other Devices

126. Finally, a few commentors suggest that Definition U should be broadened to include operating systems for non-desktop PCs and non-PC devices, such as tablet PCs and handheld devices,^[133] and even operating systems used in “an extensive set of devices,” most with little or no similarity to PCs, including, among others, smart phones, digital cameras, retail point of sale devices, automobile computing systems, industrial control devices, and smart cards.^[134]

127. There is no basis in the Court of Appeals' opinion for such a sweeping definition and the sweeping scope of coverage of the RPFJ that would follow from it. Plaintiffs' case focused on Microsoft's anticompetitive use of its PC operating system monopoly to thwart emerging middleware threats to the applications barrier to entry into the PC OS market that protected that monopoly. The Court of Appeals affirmed the District Court's finding that Microsoft possessed a monopoly in a market for PC operating systems, and that it engaged in a variety of illegal actions to maintain that monopoly. Extending, as these commentors urge, each of the provisions of the RPFJ to a wide variety of non-PC devices—all of them outside of the relevant market proved at trial and upheld on appeal—is unwarranted and unrelated to any proper remedial goal in this case.

IV. OEM Provisions

A. Overreliance on OEMs

128. Several commentors suggest that the RPFJ burdens OEMs with the responsibility of injecting competition into the operating system market, a burden that, in the view of these commentors, the OEMs are not financially or technically capable of bearing. Under this view, the low margins and fierce price competition in the OEM business will deter OEMs from undertaking the costs and risks of exercising their new flexibility, guaranteed by RPFJ Section III.H, to replace access to Microsoft Middleware Products with access to Non-MicrosoftMiddleware Products.^[135] To correct this perceived problem in the RPFJ, one commentor proposes to require Microsoft to license the binary code of its Windows Operating Systems Products to ISVs and system integrators at the lowest license fee that Microsoft charges to any OEM or other customer; the ISVs or system integrators would be allowed to repackage Windows with non-Microsoft middleware and applications and license the new package to interested OEMs or other consumers.^[136]

129. The argument that competitive pressures constrain OEMs, and so will make them unwilling to load non-Microsoft middleware, ignores the fact that the OEMs will respond to competitive pressures in choosing what software to offer consumers. The low margins and fierce competition in the OEM industry make OEMs more sensitive to consumer preferences, not less. If an OEM believes it can attract more customers by replacing a Microsoft product with a non-Microsoft product, it will do so; if not, it will not. And, indeed, this is precisely the way that a market should work. Thus, the success of the RPFJ in ensuring competitive conditions should not be judged by which choices OEMs make; rather it should be judged by whether OEMs have the opportunity to make those choices, free from contractual restrictions and fear of retaliation.

130. Similarly, the likely competitive impact of the RPFJ cannot be evaluated by looking at how OEMs have responded to the limited freedom to replace Microsoft's desktop icons in Windows XP that Microsoft voluntarily offered to OEMs in a letter dated July 11, 2001. Several commentors leap from the observation that no OEM has so far chosen to remove Internet Explorer from the desktop to the assertion that therefore the RPFJ's provisions permitting the removal of end-user access to Microsoft Middleware Products will have no competitive effect.^[137]

131. Such a leap is unwarranted for several reasons. First, the RPFJ will grant OEMs significantly greater flexibility to customize Windows compared to Microsoft's voluntary offer. An OEM's “experience” under Microsoft's July 11 letter does not equate to experience under the RPFJ. The United States believes that it is quite possible that OEMs will choose to take advantage of the RPFJ's flexibility even if they have not taken advantage of the very limited flexibility Microsoft has offered them so far. In fact, at least one OEM recently showed that it will replace Microsoft middleware when it believes other options are more profitable: Compaq announced, on December 12, 2001, that its main consumer line of PCs will ship with RealNetworks' RealOne Player, rather than Microsoft's Windows Media Player, set as the default media player.^[138] Second, other OEMs may have been reluctant to start customizing their systems until a final judgment is in place and they know the precise contours of their options. Third, as explained above, even if an OEM chooses not to replace Microsoft products with non-Microsoft products, that does not detract from the value of providing the OEM with the flexibility to do so. The RPFJ is intended to protect the competitive process, not to impose particular competitive outcomes.

132. More broadly, the emphasis in the RPFJ on provisions to free OEMs' choices is entirely appropriate, given their importance in the case. The Court of Appeals found that OEM preinstallation was “one of the two most cost-effective methods by far” of distributing browsers, and that Microsoft used various license restrictions on OEMs to “prevent[] OEMs from taking actions that could increase rivals' share of usage.”Microsoft, 253 F.3d at 60, 62. The RPFJ's provisions reflect that preventing Microsoft from defeating future middleware threats through restrictions and pressure on the OEM channel is essential to ensuring that there are no practices likely to result in monopolization in the future.

B. Non-Retaliation (RPFJ § III.A)

133. Section III.A of the RPFJ prohibits a broad range of retaliatory conduct by Microsoft. Specifically, Microsoft may not retaliate against an OEM based upon the OEM's contemplated or actual decision to support certain non-Microsoft software. This section assures OEMs the freedom to make decisions about middleware or other operating systems without fear of reprisal.

134. Commentors express several concerns about Section III.A.^[139] Although some commentors congratulate the United States for provisions that are procompetitive, represent real benefits to consumers, and take the club out of Microsoft's hand,^[140] others believe that this section is not broad enough. Some commentors propose, for example, that the section be expanded to cover: (1) all software, including Microsoft Office;^[141] (2) entities other than OEMs;^[142] (3) threats of retaliation;^[143] (4) all forms of retaliation;^[144] (5) retaliation for any lawful acts undertaken by an OEM;^[145] (6) existing forms of non-monetary consideration and all monetary consideration;^[146] and (7) shipping PCs without an operating system.^[147] One commentor seeks to eliminate from Section III.A Microsoft's ability to enforce its intellectual property rights through patent infringement suits.^[148] Commentors also believe that the Section does not protect OEMs from arbitrary termination of their Windows licenses.^[149] Commentors further claim that the standard contained in Section III.A. of subjective, actual knowledge is too hard to meet,^[150] and that Microsoft's ability to offer Consideration is too broad.^[151] Finally, some commentors object to the RPFJ's failure to define “retaliation.”^[152]

1. Section III.A Is Sufficiently Broad

135. Section III.A is designed to prevent Microsoft from undertaking actions against OEMs that have the purpose and effect of impairing an OEM's ability freely to choose to distribute and support middleware that may threaten Microsoft's operating system monopoly.^[153] See also CIS at 25.The Section is logically limited to retaliation against OEMs,^[154] as no evidence was presented at trial to show that entities other than OEMs, ISVs, and IHVs have been subject to retaliation in the past, or that other entities are so dependent upon commercial relations with Microsoft (or Microsoft's Consideration) that they are susceptible to retaliation.

136. Comments suggesting that Section III.A is deficient because it fails to address threats of retaliation similarly are misplaced. Section III.A ensures that Microsoft cannot retaliate based upon the OEM's contemplated or actual decision to support certain non-Microsoft software. Threats of retaliation are empty when Microsoft cannot follow through on them.

137. Some commentors contend that Microsoft should be prohibited from all forms of retaliation, noting that Section III.A does not prohibit retaliation that is unrelated to middleware. Commentors urge the Court to expand Section III.A. to prohibit retaliation for any lawful act by an OEM. This position, however, misapprehends the case. This case dealt with Microsoft's actions with respect to middleware threats to Microsoft's operating system. The RPFJ prohibits Microsoft both from repeating those actions found to be illegal, and from undertaking other, similar acts that may protect its operating system monopoly from middleware threats.

138. The provision of Section III.A covering non-monetary Consideration^[155] also drew comments. Commentors suggest that the provision be re-written to include monetary Consideration. In fact, Section III.A. already covers existing and successor forms of monetary Consideration, as Microsoft is expressly prohibited from retaliating by “altering . . . commercial relations with [an] OEM . . .” Dropping or changing monetary Consideration would alter commercial relations. Section III.A, however, does not prohibit Microsoft from competing by, for example, offering to pay OEMs for desktop placement. But Section III.A would prohibit Microsoft, in this example, from retaliating by altering its commercial relations with, or withholding non-monetary Consideration from, OEMs that choose to accept a third party's offer in lieu of Microsoft's.

139. Certain commentors also argue that limiting retaliation to withholding “newly introduced” forms of non-monetary Consideration somehow exempts existing forms of such Consideration from the reach of Section III.A. This is incorrect. As noted in the CIS (at 26), this clause specifically applies to “successor versions of existing forms of Consideration.”

140. Finally, certain comments recommend that this Section expressly permit shipping a computer without a Microsoft operating system or no operating system at all. The United States notes, however, that such machines are already available in the market^[156] and sees no reason for the RPFJ to address the question.^[157]

2. Section III.A Properly Allows Microsoft To Enforce Intellectual Property Rights

141. Section III.A provides that nothing in the provision prohibits Microsoft from enforcing its intellectual property rights where doing so is not inconsistent with the RPFJ. A commentor suggests that Section III.A should, in fact, prohibit Microsoft from bringing or threatening lawsuits to enforce such rights. This suggestion is meritless. The commentor would force Microsoft to dedicate its intellectual property, effectively putting all of its patented and copyrighted material into the public domain. Although Microsoft's competitors would appreciate an ability to free-ride on Microsoft's investment in research and development, the antitrust laws do not require such a draconian remedy with its attendant destruction of incentives for innovation. The RPFJ seeks to draw a balance between preventing Microsoft from engaging in anticompetitive acts to protect its operating system monopoly while still encouraging it to compete and to innovate. Prohibiting Microsoft from enforcing its intellectual property rights would deter innovation unduly and encourage infringement without barring conduct found by the District Court and Court of Appeals to violate the antitrust laws.

3. Section III.A Protects OEMs From Arbitrary Termination of Their Licenses

142. Commentors are simply incorrect in their assertions that the terms of the RPFJ permit arbitrary termination of Covered OEMs' Windows licenses.^[158] The RPFJ states expressly that Microsoft may not terminate a Covered OEM's license without first providing a written notice and opportunity to cure. It is only if the OEM has failed to cure the violation after the two letters that Microsoft then may terminate the OEM's license. If the OEM cures the violation, Microsoft cannot terminate for that violation. Microsoft cannot reasonably be barred from ever terminating an OEM's license, because there may be legitimate reasons for doing so (e.g., an OEM's failure to pay).

143. Section III.A.3 also protects OEMs from losing their Windows license in retaliation for exercising any option provided for in the RPFJ. Pursuant to those provisions, for example, Microsoft may not terminate a Windows license because an OEM has removed end-user access to any Microsoft Middleware Product.

4. Requiring Proof of Knowledge Is Necessary and Can Be Met

144. Certain commentors allege that requiring proof that Microsoft knew that an OEM was or was contemplating undertaking any of the enumerated actions before finding retaliation sets an impossible standard. In fact, such a requirement is reasonable because an inference of retaliation would be inappropriate unless Microsoft knows of the action that it is seeking to punish or prevent.

5. Microsoft's Permitted Use of “Consideration” Is Appropriate

145. The RPFJ permits Microsoft to provide Consideration to an OEM with respect to a Microsoft product or service, but only where the level of Consideration is commensurate with the OEM's contribution to the development, distribution, promotion, or licensing that particular product or service. This portion of Section III.A is designed to address permissible collaborations between an OEM and Microsoft to promote Microsoft products and services. In exchange for the OEM's assistance, Microsoft may provide a different level of consideration commensurate with that OEM's contribution—so that, for example, an OEM that collaborates with Microsoft on developing a particular product through extensive testing, or offers advertising or other promotion, may be compensatedfor its greater role through a higher level of Consideration for that product than one that is not developing or supporting that product. Similarly, this provision would permit Microsoft to provide different levels of Consideration to those OEMs buying larger quantities of product. The OEM buying one million copies of a product may be offered greater support than the OEM buying five copies. Microsoft may, however, base the level of Consideration only on the OEM's support for the same Microsoft product or service, and not on an OEM's agreement not to support or develop a competing product or to support or develop other Microsoft products.

6. The RPFJ Uses the Common Language Definition of “Retaliate”

146. Commentors also complain that the RPFJ fails to define “retaliate.” In fact, no separate definition for the term is needed. The RPFJ prohibits Microsoft from retaliating by altering commercial relations with, or withholding newly-introduced forms of non-Monetary Consideration from, an OEM. In this context, “retaliate” does not require further elaboration.

C. Uniform Terms (RPFJ § III.B)

147. To ensure that the twenty Covered OEMs will be free from the threat of Microsoft retaliation or coercion, Section III.B requires that Microsoft's Windows Operating System Product licenses with those OEMs contain uniform terms and conditions, including uniform royalties. These royalties must be established by Microsoft and published on a schedule that is available to Covered OEMs and the Plaintiffs.

148. Windows license royalties and terms are inherently complex and easy for Microsoft to use to affect OEMs' behavior, including what software the OEMs will offer to their customers. Section III.B is intended to eliminate any opportunity for Microsoft to set or modify a particular OEM's royalty, or its other license terms or conditions, in order to induce that OEM not to promote non-Microsoft software or to retaliate against that OEM for promoting competing software.^[159] By removing any mechanism for Microsoft to use such leverage, this provision will further permit OEMs to make their own independent choices without fear of retribution.

1. Top Twenty OEMs

149. Section III.B is limited to the twenty OEMs with the highest worldwide volume of licenses of Windows Operating System Products. Some commentors criticize this limitation, arguing that it leaves Microsoft free to retaliate against smaller OEMs, including regional “white box” OEMs.^[160] The top twenty OEMs, however, together account for a substantial percentage, in excess of 75 percent in fiscal 2001, of all Windows licenses. Consequently, providing those key OEMs with the added guarantees of freedom to distribute and promote particular types of software that could erode Microsoft's monopoly—the purpose of Section III.B—is of extreme competitive significance. In any event, all OEMs are protected from retaliation by Section III.A of the RPFJ. Section III.B is intended to provide an additional layer of protection for these twenty OEMs that are likely to be of great significance.

150. At least one commentor would go much further and seek to require Microsoft to offer uniform terms not only to the top twenty OEMs, but also to all of the hundreds of OEMs, whatever their size, and even further to “all third party licensees.”^[161] There is no rational basis for treating every licensee of Windows, from the largest OEM to the smallest corporation, equally with respect to their Windows royalties and all the terms and conditions of their licenses. Certainly the intent to prevent Microsoft from discriminating or retaliating in response to competitive activities cannot begin to justify such a broad provision. In fact, such a requirement would be enormously inefficient and disruptive and would ignore vast differences between differently situated types or groups of licensees.

151. In any event, neither the antitrust laws generally, nor the Court of Appeals' decision specifically, require that even a monopolist like Microsoft treat all third parties equally. In fact, in many instances “unequal” treatment (e.g., collaboration between two companies that does not include other firms) evidences legitimate competition. Thus, Section III.B was crafted carefully to provide extra protection against improper rewards or retaliation involving the most significant OEMs, without precluding other conduct that could result in potentially procompetitive benefits.

2. MDAs Or Other Discounts

152. A number of commentors argue that Section III.B should forbid all market development allowances (“MDAs”) or other discounts.^[162] This approach would be unnecessarily overbroad and would discourage efficient behavior that has little or no potential to be used by Microsoft for anticompetitive purposes. There are a range of business activities involving Microsoft and OEMs, having nothing to do with operating system or middleware competition, where MDAs or other discounts would be procompetitive.

153. At the same time, Section III.B carefully guards against Microsoft misusing MDAs or other discounts to reward or retaliate against particular OEMs for the choices they make about installing and promoting Non-Microsoft Middleware or Operating Systems or for any other purpose that is inconsistent with the provisions of the RPFJ.^[163] To avoid the risk of Microsoft misusing MDAs or other discounts to reward or retaliate against OEMs for competitive middleware activities, Section III.B provides that, if Microsoft utilizes MDAs or similar discounts, they must be available and awarded uniformly to the ten largest OEMs on one discount scale and separately to the ten next largest on the same or another discount scale. In addition, the discounts must be based on objective, verifiable criteria, and those criteria must be applied uniformly to the relevant OEMs.

154. The RPFJ does prohibit Microsoft from using MDAs or other discounts if they are inconsistent with any other provision in the RPFJ. This would include, for example, retaliation against computer manufacturers for using non-Microsoft middleware that is implemented through incentive payments for faster “boot up.”

3. OEMs Should Be Able To Negotiate

155. Several commentors argue that there should be a limited exception to the requirement of uniform licenseterms and conditions in Section III.B to permit OEMs to continue to negotiate with Microsoft concerning exceptions to certain intellectual property “non assertion covenants” or “non assertion of patents” provisions in their licenses with Microsoft.^[164] In these covenants, which have been part of Windows license agreements with OEMs for years but which historically have been the subject of intense negotiation between Microsoft and OEMs, the OEMs agree not to assert certain patent claims against Microsoft.^[165]

156. According to these commentors, the uniform licensing terms provision of Section III.B of the RPFJ appears to be preventing Microsoft from negotiating with OEMs about the latest non assertion provisions.^[166] One of the commentors, Sony, urges a modification or clarification of the RPFJ that would permit it and other OEMs to negotiate with Microsoft for more favorable non assertion provisions than those contained in Microsoft's uniform terms and conditions, with any new terms obtained then required to be offered to all Covered OEMs on a non-discriminatory basis; individual OEMs could choose to accept or decline.^[167]

157. The United States believes that such a modification is unnecessary. Currently, nothing in the RPFJ prevents Microsoft from negotiating with Covered OEMs prior to establishing its uniform terms and conditions. The RPFJ does not in any way require that Microsoft must unilaterally set those terms, without any advance negotiation with or input from the OEMs. Similarly, nothing in the RPFJ prevents Microsoft from agreeing with an OEM to provisions that depart from the uniform terms and conditions, so long as any term or condition resulting from that agreement then becomes the uniform term or condition, is included on the required schedule, and is offered on a non-discriminatory basis to all Covered OEMs. And certainly nothing in the RPFJ specifies what terms or conditions ultimately will become the uniform terms and conditions. Those terms and conditions may be set at a variety of levels determined either by Microsoft itself or through advance discussion and negotiation with the OEMs; the RPFJ specifies neither the process nor the resulting level.

158. The Litigating States also assert that Microsoft's view is that it is authorized to insist on uniform, and uniformly onerous, non assertion provisions by the terms of Section III.I.5. To the extent that anyone at Microsoft (or elsewhere) ever believed or conveyed to any OEM that Section III.I.5 of the RPFJ authorizes Microsoft to insist on broad patent non-assertion provisions, that belief was inaccurate. The cross-license provision in III.I.5 was extremely narrow and applied only in a particular, limited type of situation. In any event, in part in response to these comments, and to avoid any possibility that Section III.I.5 could be misinterpreted in a way that discourages any third party from taking advantage of options or alternatives offered under the RPFJ, the United States and Microsoft have agreed to delete Section III.I.5 from the SRPFJ. See Section VII(C)(3) below.

4. Volume Discounts

159. One commentor claims that the RPFJ should permit Microsoft to utilize volume discounts only if they are based on an independent determination of the actual volume of shipments, in order to avoid Microsoft manipulation of such discounts.^[168] But such a regulatory mechanism is not necessary under the RPFJ. It requires that any volume discounts must be “reasonable” and based on the “actual volume” of Windows licenses. The RPFJ's enforcement mechanism will ensure that Microsoft does not misuse the calculation of such discounts.

5. Termination—Cause, Materiality, And Notice

160. Some commentors criticize Section III.B for not requiring Microsoft to demonstrate “good cause” before terminating a Covered OEM's license, and for not requiring even more notices and opportunities to cure before termination.^[169] The commentors argue that Microsoft could abuse the notice provision and then terminate a disfavored OEM without any opportunity to cure.

161. First, any abuse of the opportunity to cure or termination provisions by Microsoft—e.g., through sham notices—would be a serious breach of its obligations under the RPFJ. Second, if the process is not misused, two previous notices and opportunities to cure during a single license term should provide ample protection against retaliation for OEMs that are dealing with Microsoft in good faith and ample protection for Microsoft against OEMs that fail to comply with their contractual obligations. Finally, a requirement that any termination be for “good cause” is unnecessary and overly regulatory; once again, any sham termination by Microsoft for anticompetitive purposes would constitute a serious breach of the RPFJ.

6. Servers Or Office

162. Section III.B requires that Microsoft employ uniform license agreements and uniform terms and conditions for the top twenty OEMs only with regard to its licensing of Windows Operating System Products. The provision is limited to Windows licenses because the relevant market in which Microsoft was found to have a monopoly consists of PC operating systems, and because the various illegal actions in which Microsoft engaged were undertaken to protect that monopoly, not other products.

163. Some commentors argue that Microsoft can evade the restrictions of Section III.B simply by shifting its retaliatory price discrimination to other key Microsoft products such as Office or server operating systems.^[170] To the extent the commentors intend to assert that this limitation in Section III.B leaves Microsoft free to use discriminatory licensing terms or conditions for Office or other important Microsoft products in order to reward or punish OEMs for their actions regarding Microsoft and non-Microsoft Middleware, that assertion is wrong. Although Section III.B is limited to Windows Operating System licenses, the general anti-retaliation provisions of Section III.A are not so limited. See Section IV(B) above. Any attempt by Microsoft to alter the terms of any (not just the top twenty) OEM's license for Office or any other product (or any other commercial relationship with that OEM) because that OEM is working with rival Platform Software or any product or service that distributes or promotes non-Microsoft middleware will be prohibited by § III.A.

7. Key License Terms

164. One commentor argues that the RPFJ should require Microsoft to provide OEMs and other licensees with equal access to “licensing terms, discounts, technical, marketing and sales support, product and technical information, information about future plans, developer tools or support, hardware certification and permission to display trademarks or logos.”^[171] Otherwise, the commentor claims, Microsoft can keep such information secret and take advantage of licensees' ignorance about what terms are available.^[172] With respect to the top twenty Covered OEMs, however, Microsoft already is required by Section III.B to offer all license terms and conditions on a uniform and non-discriminatory basis.

8. Prohibition On Enforcing Agreements Inconsistent With The RPFJ

165. One commentor urges that Microsoft should be forbidden from enforcing any contract term or agreement that is inconsistent with the decree.^[173] But such a provision is both unwarranted and unnecessary. To the extent that a contract term or agreement seeks to bar someone from doing something that is required or permitted under the RPFJ, or requires someone to do something that Microsoft is forbidden from offering, the RPFJ already would prevent such action. In certain key areas, the RPFJ does include a provision prohibiting Microsoft from retaliating against an OEM for exercising any of its options or alternatives under the RPFJ (Section III.A.3) or from basing MDAs on any requirements that are inconsistent with the RPFJ (Section III.B.3.c). In the latter case, the provision is necessary to make clear that, by affirmatively authorizing Microsoft to do something (offer MDAs or other discounts), the RPFJ is not authorizing Microsoft to base those discounts on inappropriate criteria.

D. Freedom Of OEMs To Configure Desktop (RPFJ § III.C)

166. Section III.C of the RPFJ prohibits Microsoft from restricting by agreement any OEM licensee from exercising certain options and alternatives. A few comments argue that Microsoft should be prohibited from restricting OEMs by “other means” as well as by agreements.^[174] The United States believes that the limitation to agreements is appropriate in this section.^[175] The most obvious and effective means for Microsoft to restrict an OEM's conduct is by agreement, as reflected in the record in this case. In addition, as explained in the CIS, the RPFJ uses the term “agreement” broadly to include any contract, requirement, or understanding.^[176] Use of other means by Microsoft to influence, limit, or reward the options of OEMs is appropriately covered in other provisions, such as Sections III.A, III.B, and III.G. Technical means of limiting the options of OEMs are addressed by Section III.H.

167. Looking at the products covered by this section, some comments argue that the provision should extend to any application, not just middleware, or at least to Microsoft Office.^[177] The United States believes that the decree correctly focus on middleware, because that was the focus of Plaintiffs' case and of the courts' holdings. Section III.C provides broad protection for non-Microsoft Middleware as it is configured for use with Windows. Because this section focuses on OEM flexibility in configuring Windows Operating System Products, it would be illogical to consider products, such as Office, that are not part of the Windows Operating System Product.

168. It is important to remember that this section pertains to OEM configurations, and not to what users or Non-Microsoft Middleware itself can initiate if selected by a user. These provisions, in essence, control how the configuration will appear the first time the user boots the computer. After that first time, the user may take many actions, such as clicking on icons, rearranging the desktop, or making other program choices, that drastically alter the configuration of the computer. A user launching a program by clicking on an icon may change many of the configuration options of the computer, including whether the program will subsequently launch automatically or be displayed in a certain size or be the default application. Thus, Section III.C governs only OEM configuration, but not any subsequent configurations based on user choices.

1. Section III.C.1

169. Several comments suggest that, under Section III.C.1, OEMs should be given greater flexibility in configuring Windows, extending to such things as taskbars, toolbars, links, and default pages and similar end user features in Internet Explorer; features of Windows XP such as the My Photos, My Music, and similar operating system folders; and elimination or alteration of the Start Menu.^[178]

170. Subsection III.C.1 strikes an appropriate balance between the interests of Microsoft and OEMs in order to allow promotion and installation of Non-Microsoft Middleware. In fact, the provision covers some of the features requested by commentors, such as quick launch bars and the Start Menu. As discussed in the CIS (at 30), “a list of icons, shortcuts or menu entries” includes a wide variety of access points in Windows Operating System Products, including the system tray, “right-click” lists, “open with” lists, lists that appear based on an action or event, such as connecting hardware or inserting an audio CD, and even lists within folders such as MyMusic or MyPhotos. This flexibility must be balanced against Microsoft's interest in presenting a user interface on its Windows products that has been well tested and is simple and intuitive for users. Windows is, after all, Microsoft's product. The United States believes that the provision allows for many opportunities for promotion and installation of Non-Microsoft Middleware without going so far as to allow OEMs to make drastic changes to Microsoft's user interface. Cf. Microsoft, 253 F.3d at 63 (Microsoft's restrictions on OEM reconfiguration of user interface did not violate Section 2).

171. Another commentor argues that the RPFJ merely codifies Microsoft's existing practices regarding flexibility of configuration and serves almost no remedial purpose.^[179] To the contrary, Section III.C gives OEMs much greater flexibility than they have ever had. Even as late as summer 2001, Microsoft still was restricting the placement of icons in Windows. The flexibility OEMs receive under Section III.C, combined with the ability to remove access to Microsoft Middleware Products under Section III.H, will allow OEMs to offer many different configurations and promote Non-Microsoft Middleware in a variety of ways. That Microsoft voluntarily provides certain flexibility does not eliminate the need for relief requiringthat flexibility, as the Court of Appeals' decision mandates.

172. Commentors also note that the term “functionality” (see Section III.C.1) is not defined, that Microsoft is free to decide what categories qualify for display, and that Microsoft could exclude Non-Microsoft Middleware for which no Microsoft counterpart exists or otherwise restrict the meaning of functionality.^[180] As explained in the CIS (at 30), “functionality” is intended to capture broad categories of products, and not to be used to discriminate against Non-Microsoft Middleware. Thus, for example, Microsoft may reserve a particular list for multimedia players, but cannot specify either that the listed player be its own Windows Media Player, or that the player be capable of supporting a particular proprietary Microsoft data format. Such non-generic specification, which would have the effect of restricting the display of competing Non-Microsoft Middleware, would not be non-discriminatory. Microsoft cannot prescribe the functionality so narrowly that it becomes, in effect, discriminatory.

173. Moreover, Microsoft cannot completely forbid the promotion or display of a particular Non-Microsoft Middleware Product on the ground that Microsoft does not have a competing product itself. To do so would be discriminatory; there must always be (and there always has been) a place for applications generally to be listed or their icons displayed. Without this functionality limitation, developers of Non-Microsoft Middleware with media player functionality could insist that it wants to be displayed with instant messaging services, making groupings of supposedly competitive products with the same or similar functionality meaningless and hopelessly chaotic for the user.

2. Section III.C.2

174. A few commentors argue that, under Section III.C.2, Microsoft has control over what non-Microsoft products may be promoted by an OEM because Microsoft could define what “impair[s] the functionality of the user interface.”^[181] Section III.C.2 applies only to shortcuts, but it allows those shortcuts to be of any size and shape. Potentially, these shortcuts could be so large as to cover key portions of the Windows user interface (for example, the Start Menu). As the Court of Appeals found, Microsoft has an interest in preventing unjustified drastic alterations of its copyrighted work. Microsoft, 253 F.3d at 63. The limitation preventing shortcuts from impairing the functionality of the user interface was designed to respect this interest, while still giving OEMs considerable freedom to promote Non-Microsoft Middleware.

3. Section III.C.3

175. There are many comments related to Section III.C.3. Some comments argue that this subsection gives Microsoft design control because Microsoft could set parameters for competition and user interface design via the limitation on “similar size and shape,” which then leaves competing applications to conform to Microsoft's “look and feel.”^[182] This is not the intent or effect of this provision. See CIS at 31-32. For programs that are configured by the OEM to launch automatically, either in place of, or in addition to, Microsoft Middleware Products, the restriction limits whether applications can launch with their full user interface, no interface, or appear in the system tray or similar location. Thus, this provision addresses Microsoft's interest in preventing unjustified drastic alterations to its copyrighted work, as recognized by the Court of Appeals. See 253 F.3d at 63.

176. Some commentors argue that Microsoft retains control of desktop innovation because it can prevent OEMs from installing or displaying icons or other shortcuts to Non-Microsoft software or services if Microsoft does not provide the same software or service.^[183] Others say that the middleware icon provisions of III.C.1 and III.C.3 apply only when Microsoft has a competing product, and Microsoft can limit the OEMs' ability to promote competing programs.^[184] Still others criticize that Section III.C.3 limits automatic launches to the boot-up sequence or when the user connects to the Internet, thus limiting the options of OEMs.^[185]

177. The majority of these comments are misplaced. Section III.C.1 does not prevent OEMs from installing or promoting Non-Microsoft Middleware, regardless of whether Microsoft has a competing product. At a minimum, Section III.C.2 allows for any Non-Microsoft Middleware to be installed and displayed on the desktop with a shortcut, completely independent of the existence or characteristics of any Microsoft product. The only issue is where else in the Windows interface the Non-Microsoft Middleware will be promoted. As discussed above (see Section IV(D)(1)), Microsoft has a valid interest in presenting an orderly user interface such that, for example, lists of what are supposed to be word processors do not clutter lists of media players. If the Windows interface has a space for listing, for example, Internet applications, then any Internet application can go there regardless of whether Microsoft has a competing application. If the Windows interface has no listing for a particular new category of application, then there will be, and always has been, a general place where applications can be listed, such as the desktop.

178. It is correct that, under Section III.C.3, Non-Microsoft Middleware cannot be configured to launch automatically unless a Microsoft Middleware Product would have otherwise launched. However, this governs only the original OEM configuration. If the user clicks on an icon or otherwise runs the Non-Microsoft Middleware, that application can itself set up to launch automatically on subsequent boot sequences, or at any number of other times, including but not limited to connections to the Internet. Section III.C.3's approach is a reasonable compromise with Microsoft's interest in having the computer boot up quickly the first time it is turned on, a characteristic that users value.

179. A few commentors believes it is inappropriate that Microsoft be allowed to decide what forms the user interface, e.g., a desktop with icons, may take.^[186] The United States disagrees. Microsoft has a valid interest in developing its products, which some users actually prefer on the merits, and in preventing unjustified drastic alterations to its copyrighted work. The purpose of the remedy is not to strip Microsoft of the ability to design operating systems or compete on the merits.

4. Section III.C.4

180. Some commentors argue that Section III.C.4 does not prohibit Microsoft from deleting or interfering with competing boot loaders, does not allow OEMs to ship machines without any operating system, and otherwisedoes not assist the OEMs' ability to promote non-Microsoft operating systems.^[187] The United States partially agrees and partially disagrees with these comments. Section III.C.4 provides for the option of launching other operating systems and prohibits Microsoft from attempting to delete or interfere with competing boot loaders that accomplish this task. This subsection does not enable OEMs to sell machines without an operating system, as that would not promote Non-Microsoft Middleware. However, Microsoft would run afoul of Section III.A if it attempted to restrict OEMs from shipping PCs with rival operating systems.

5. Section III.C.5

181. Some comments criticize Section III.C.5 for providing promotional flexibility only for IAP offerings, and even then only for an OEM's “own” IAP offer but not for other products.^[188] At least one commentor notes that the Windows XP initial boot sequence offers a wide range of Microsoft products and services, including Passport, Hotmail, Instant Messenger, and Internet telephony.^[189] Some commentors predict that Microsoft will use the “reasonable technical specifications” to unreasonably exclude competitors.^[190]

182. Section III.C.5 permits OEMs to create and display a customized offer for the user to choose an IAP during the initial boot sequence. A user's IAP can be an important source of choices about a wide variety of Non-Microsoft Middleware. It is the OEM's “own” IAP in the sense that the OEM selects it, not necessarily that the OEM is itself an IAP. Microsoft is not permitted unreasonably to exclude competitors via the technical specifications for IAP offers. Microsoft previously and understandably has given such reasonable technical specifications to OEMs, and the United States does not expect Microsoft to deviate from its prior standards as to what is reasonable. After all, Microsoft has an interest in offering OEMs an operating system that works, and absent reasonable technical standards, performance might be degraded.

183. At least one commentor argues that there should be a provision allowing OEMs to replace the Windows desktop, and sees no explanation in the CIS as to why this provision, which the United States advocated before the District Court and on appeal, has been removed.^[191] The simple answer to this question is that the Court of Appeals reversed the finding of liability on this point (see Microsoft, 253 F.3d at 63), and to provide for such a remedy would be inappropriate in this case.

6. Comparison To Litigating States' Proposal

184. Several commentors argue that the Litigating States' Provision 2.c (“OEM and Third-Party Licensee Flexibility in Product Configuration”) should replace RPFJ Section III.C.^[192] The United States believes that Provision 2.c is overbroad and largely unrelated to middleware competition that could threaten Microsoft's desktop operating system monopoly. Additionally, the Litigating States' Proposal appears to ignore the Court of Appeals' decision that Microsoft is entitled to prevent an unjustified drastic alteration of its copyrighted work, and to prohibit OEMs from substituting a different user interface automatically upon completion of the initial boot sequence. Microsoft, 253 F.3d at 63. Regardless of how broadly one reads this portion of the Court of Appeals decision, Provision 2.c would appear to allow an OEM to make the very “drastic alteration[s] [to] Microsoft's copyrighted work” that the Court of Appeals found Microsoft lawfully could prohibit. See id.

185. Provision 2.c essentially provides that Microsoft cannot restrict by contract, technical, or any other means a licensee from modifying any aspect of a Windows Operating System Product.^[193] The breadth of this provision appears to require that Microsoft allow, and provide the information to accomplish, any modification to any portion of a Windows Operating System Product, no matter how unrelated to middleware. For example, this provision appears to allow licensees to change the manner in which Windows implements disk compression, the TCP/IP protocol, the calculator program, and the Windows Help system. These modifications apparently could be at any level of granularity, including very small segments of code.

186. Although Provision 2.c also identifies specific types of modifications—e.g., the boot sequence, desktop, or start page—these types of modifications are not limiting because the provision clearly allows for modification of any “other aspect of a Windows Operating System Product (including any aspect of any Middleware in that product).” Provision 2.c also provides five examples (¶¶ 2.c.i-v), but these are given “[b]y way of example, and not limitation.” This Proposal thus appears to allow any and all modifications.

187. These types of broad modifications are not necessary to allow for vigorous competition in the middleware market. Indeed, it appears that the vast majority of these modifications have very little, if anything, to do with middleware and therefore are beyond the scope of the liability findings in this case.

E. Microsoft's Obligations To Provide Add/Remove Functionality And Automatic Invocations (RPFJ § III.H)

1. Obligation To Provide Add/Remove Functionality

188. Some commentors argue that Section III.H.1 allows Microsoft to force Non-Microsoft Middleware Products into an Add/Remove utility.^[194] The United States believes that one of the primary goals of the RPFJ is to enable users to make choices on the merits about Microsoft and Non-Microsoft Middleware Products. In the current Add/Remove utilities available in Windows Operating System Products, Microsoft Middleware Products are often not present at all, or are presented as Windows components in a separate window. Non-Microsoft Middleware Products, which currently routinely add themselves into the Add/Remove utility upon installation, are in a different Add/Remove window. Without the RPFJ, there is no easy way for the user to realize that something labeled as a Windows system component can be replaced with a Non-Microsoft Middleware Product. This provision will alter Microsoft's current practice of creating an artificial distinction between these Non-Microsoft Middleware Products and Microsoft Middleware Products.

189. Other commentors point out that exclusivity cannot be provided to Non-Microsoft Middleware Products, that Microsoft does not have to compensate an OEM for the presence of its icons on the desktop, and that every computer shipped represents an expense to the non-Microsoft software and income via the Windows license to Microsoft.^[195] Itis incorrect that exclusivity, at least as to icons and other visible means of end-user access, cannot be provided to Non-Microsoft Middleware Products. Non-Microsoft Middleware Products can have exclusive agreements with OEMs covering all the most significant means of promoting their products—through desktop icons, the Start Menu, and being set as the defaults. The only exception to this exclusivity of visible means of end-user access would be a listing of the non-Microsoft Middleware Products in the Add/Remove utility, which has never been Microsoft's means of promoting usage.

190. Furthermore, should Microsoft wish to promote its Microsoft Middleware Products, it is constrained by other provisions in the decree, particularly provisions regarding exclusive or fixed percentage agreements with OEMs. See discussion of Section III.G. As an example, Microsoft could not reach an agreement with an OEM that required the OEM to set the Microsoft product as the default on 100 percent of the OEM's machines. Non-Microsoft Middleware Products do not face this constraint. Additionally, because OEMs are free to remove Microsoft icons and free to negotiate exclusivity agreements with competitors, Microsoft will have to compensate OEMs for any promotional agreements regarding its icons, in addition to conforming its agreements with the other provisions of the RPFJ.

191. A few commentors raise concerns that “particular types of functionality” and “non-discriminatory” are not defined and could be used by Microsoft to unreasonably exclude competitors.^[196] Functionality is intended only to capture broad categories of products and not to be used to discriminate against Non-Microsoft Middleware Products. Thus, for example, Microsoft may reserve a particular list for multimedia players, but cannot specify either that the listed player be its own Windows Media Player, or that the player be capable of supporting a particular proprietary Microsoft data format. Such a non-generic specification, which would have the effect of restricting the display of competing Non-Microsoft Middleware Products, would not be non-discriminatory and therefore would be prohibited under Section III.H.1.

192. Commentors also suggest that the portion of Section III.H.1 that requires Microsoft to offer “an unbiased choice with respect to enabling or removing access” would nevertheless permit Microsoft to include derogatory comments about competing products when offering such a choice.^[197] This is incorrect. The concept of non-discriminatory includes the concept of non-derogatory; Microsoft cannot present a choice that is derogatory toward the Non-Microsoft Middleware Products without also by definition discriminating against that Product.

2. Obligation To Provide Automatic Invocations and Exceptions

a. Obligations To Provide Automatic Invocations

193. Section III.H.2 addresses situations where Microsoft must create the ability to designate programs for automatic invocation, commonly referred to as default settings. Many commentors point out that there will be few situations where Microsoft is obligated to provide a default setting. They say that Microsoft easily will be able to evade this provision,^[198] simply by embedding its Microsoft Middleware Products in other portions of the Windows Operating System Product or other Microsoft Middleware Products. Similarly, some commentors suggest that Microsoft could engineer its middleware to launch without using all of the “Top-Level Window” components or with making the slightest variation on the user interface, and not have to create any defaults. Commentors further argue that the existence of defaults should not depend on the existence or behavior of Microsoft's Middleware Products.

194. Additionally, some commentors point out that OEMs will be required to support the Microsoft Middleware Products regardless of whether they have end-user access removed, because Microsoft is allowed to hard-wire their products in some cases.^[199] More specifically, these commentors argue that this situation will create an insurmountable disparity between the Microsoft and Non-Microsoft Middleware Products, because the Microsoft product will always be available and will always launch in some situations, whether the end user has selected them or not or is even aware that the product is installed.

195. The Court of Appeals' decision must be the starting point for any discussion of default settings and of the ability of Microsoft to override user choices. There were no instances in which the Court of Appeals found that Microsoft's overriding of user choice was unlawful. Microsoft, 253 F.3d at 67. Thus, the Court of Appeals' decision does not require that Microsoft respect user's default choices in all circumstances. The issue of whether Microsoft simply could have no default settings at all was, however, not before the Court and accordingly the Court did not address it.

196. Section III.H.2 of the RPFJ nevertheless requires Microsoft to implement and respect default settings in some circumstances. These circumstances are limited to situations where the Microsoft Middleware Product would launch in a separate Top-Level Window and display either (i) all of the user interface elements, or (ii) the Trademark of the Microsoft Middleware Product. These limitations are tied to the Court of Appeals' opinion, which supported Microsoft's position that it did not have to respect default settings where Windows functionality enabled users to move seamlessly from one function to another in the same window. Microsoft, 253 F.3d at 67.

197. Moreover, these limitations are designed to ensure that access to defaults exists whenever the alternative Microsoft product would be launched as the full “product” (e.g., Internet Explorer as the Internet browser), rather than when just a portion of the product's underlying functionality is launched to perform functions in Windows itself (such as code also used by Internet Explorer being used to display part of the Windows user interface), or otherwise where the end user might not necessarily be aware that he or she is using a specific Microsoft Middleware Product.

198. One of the most important functions of this Section III.H.2 is to provide certainty and a bright line regarding when Microsoft is obligated to provide and respect a default setting. Previously, Microsoft was under no obligation to provide for automatic invocations of competing products in any circumstances; Microsoft at its option provided for automatic invocations in some circumstances and not in others. Although commentors allege that there are numerous cases where Microsoft will not have to provide a default setting, the RPFJ does provide a clear line and a requirement, that did not exist before, that in some cases defaults must exist and must be respected.

199. Several commentors allege that Non-Microsoft Middleware Products are subject to a requirement that the end-user confirm his/her choice, but the Microsoft Middleware Product is not,making it effectively harder for users to choose Non-Microsoft Middleware Products.^[200] This is incorrect. Section III.H.1 clearly states that Microsoft must give end users “a separate and unbiased choice” with respect to altering default invocations in Section III.H.2. Section III.H.2 of the RPFJ provides that Microsoft shall “[a]llow . . . Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa).” The parenthetical “or vice versa” applies to the entire phrase, meaning any mechanism which requires confirmation when switching in one direction will also require it in the other direction.

200. To respond to the concerns raised by commentors and to clarify that Microsoft must be unbiased with respect to Microsoft and Non-Microsoft products under Section III.H.2, this provision was revised to expressly state that such mechanisms and confirmation messages must be unbiased. The revised language of Section III.H.2 in the SRPFJ provides:

Allow end users (via an unbiased mechanism readily available from the desktop or Start menu), OEMs (via standard OEM preinstallation kits), and Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user in an unbiased manner) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa) . . . [Emphasis added]

This modification makes clear the parties' intention that the mechanism available to end users, as well as any confirmation message to the end user, must be unbiased with respect to Microsoft and non-Microsoft products.

201. This modification also addresses any concern that the phrase “at Microsoft's option” could be read to allow Microsoft to take biased action against competing products. Further, it addresses concerns that Microsoft's presentation of the confirmation message could include derogatory comments about competing products.^[201]

b. Exceptions to the Obligation To Provide Automatic Invocations

202. In addition, the SRPFJ's two exceptions to Section III.H.2, which were previously listed after Section III.H.3 and numbered “1” and “2,” but which by their plain language unmistakably modified Section III.H.2 (“Notwithstanding the foregoing, Section III.H.2 . . .”), have been moved to Section III.H.2 for clarification and have been renumbered (a) and (b).

203. Exception (a) allows a Windows Operating System Product to invoke a Microsoft Middleware Product when it would be invoked solely for use with a server maintained by Microsoft outside the context of general web browsing. Commentors allege that Microsoft can use the exception to communicate directly with its own competing middleware in the form of web based services such as Passport, MSN, .Net and Hotmail and to override the explicit choices made by consumers and OEMs.^[202] At least one commentor misreads this exception to infer that any web server running Microsoft software is covered.^[203]

204. Turning again to the Court of Appeals decision, this exception stems from the holding that the Windows Help system was allowed to override a user's browser choice. Microsoft, 253 F.3d at 67. The current Windows Help system, as well as other parts of the Windows interface, rely on interoperating with servers maintained by Microsoft. The “maintained by Microsoft” language in exception (a) is specifically designed to catch servers actually under Microsoft's control, and not to include servers that are merely running a Microsoft product, such as Internet Information Server (IIS). Microsoft is only allowed to use this exception outside the context of general web browsing, such as the Windows Help system or similar systems, not in situations where a user has knowingly launched a browser to view web pages. This exception is similar to the limitations in the main paragraph of Section III.H.2 that limit automatic invocation to those situations where a user has launched, in essence, the “full product.”

205. Exception (b) allows a Windows Operating System Product to invoke a Microsoft Middleware Product when a designated Non-Microsoft Middleware Product fails to implement a reasonable technical requirement that is necessary for valid technical reasons to supply the end user with functionality consistent with a Windows Operating System Product. Several commentors argue that Microsoft will have exclusive control over when it must respect defaults through manipulation of the “reasonable technical requirement” clause.^[204] Concern also is raised that Microsoft is not required to document the “reasonable technical requirement” in advance in MSDN.^[205] Several commentors predict extreme and drastic results from the example of ActiveX.^[206]

206. Again, this exception appears in the RPFJ because the Court of Appeals held that Microsoft was allowed to override a user's choice when it had “valid technical reasons.”Microsoft, 253 F.3d at 67. The Court of Appeals pointed to three specific examples where features of a Windows Operating System Product depended on functionality not implemented by Navigator, and Microsoft was permitted to override Navigator in those cases. The Court of Appeals did not find any violation associated with these actions, including no violation regarding whether information was disclosed to Navigator to allow it to implement the functionality. Given this holding, the inclusion of an exception that permits Microsoft to override a user's choice when it has “valid technical reasons” was appropriate.

3. Microsoft's Ability To Change Configurations

207. Many commentors have significant concerns about Microsoft's ability to offer to alter a user's or OEM's configuration, as described in Section III.H.3.^[207] Some commentors argue that Microsoft should not be able to “encourage” users to switch back to Microsoft Middleware that has been replaced by a third-party application. Concerns also are raised that Microsoft's presentation of the choice could include derogatory comments about competing products, and that the RPFJ contains no requirement that the request to the user be objective or non-discriminatory, or that the function not delete non-Microsoft code or change user defaults. Commentors express the view that a significant number of users likely would switch just to get rid of the annoying messages. Others suggest that the fact that Microsoft is permitted to seek confirmation from the end user for an automatic alteration of the OEM configuration after 14 days significantly devalues the desktop. At least one commentor argues that OEMs do the “initial boot” before shipping a PC and hence the 14-day period could havelargely expired by the time the user boots the PC for the first time.

208. In response to some of the concerns raised regarding Section III.H.3, the RPFJ has been modified. The following additional sentence now appears in SRPFJ Section III.H.3: “Any such automatic alteration and confirmation shall be unbiased with respect to Microsoft Middleware Products and Non-Microsoft Middleware.” This sentence clarifies the parties' intention in drafting the RPFJ that Microsoft may not alter a configuration based on whether the products are Microsoft or Non-Microsoft products. Nor may Microsoft present a biased confirmation message, for instance a message that is derogatory with respect to Non-Microsoft products. Similarly, automatic alterations may not be based on a trigger or rule that is biased against Non-Microsoft Middleware or in favor of Microsoft Middleware Products.

209. Several commentors were confused regarding the “Clean Desktop Wizard,” referenced in the CIS (at 48), and its relation to Section III.H.3. The “Clean Desktop Wizard” is a utility in Windows XP that offers users the ability to move unused or infrequently-used desktop icons into a folder on the desktop. The “Clean Desktop Wizard” is the only function in Windows XP that performs an automatic alteration of a configuration of icons, shortcuts or menu entries. Furthermore, Section III.H.3 forbids Microsoft from altering how a Windows Operating System Product performs automatic alterations except in a new version of a Windows Operating System Product. Thus, the “Clean Desktop Wizard” is the only functionality that currently falls under Section III.H.3, and it must remain the only such functionality until a new version of a Windows Operating System Product. The “Clean Desktop Wizard” only affects icons on the desktop, is unbiased with respect to Microsoft and Non-Microsoft icons, and is unbiased with regard to the messages presented to the user. It takes no action without confirmation from the user, and it can be turned completely off by the user so that it never runs again.

210. Microsoft designed this utility because it believed some users prefer a less cluttered desktop and would appreciate a utility that would monitor which icons have been recently used, and offer to move the unused icons into a folder. The United States agrees that some users would appreciate this utility. The United States also believes, however, that some users would not. To offer choices to users and to remove the potential for significant anticompetitive effects, Section III.H.3 was designed always to require confirmation from the user, and to be unbiased with regard to Microsoft and Non-Microsoft products. The United States does not agree with the commentors who argue that Microsoft should be prohibited from ever offering this kind of utility as part of its operating system.^[208]

211. A number of comments criticize the 14-day delay.^[209] The 14-day delay, after a new personal computer is booted up before any automatic alternation may occur, was determined to be a reasonable compromise between the need to use desktop icons to promote Non-Microsoft Middleware, and the needs of users who would prefer to be presented with the choice of moving unused icons to a folder. A significant factor in this analysis is that there are many ways of promoting Non-Microsoft Middleware, of which the desktop is only one. Non-Microsoft Middleware may be installed in the Start Menu, for instance, or in the quick launch bar or system tray. It may also be set as a default and automatically invoked in certain instances. It may be promoted in the initial boot sequence or set to launch automatically on connection or disconnection to the Internet. And, of course, should the user click on the desktop icon, the “Clean Desktop Wizard” would not consider it an unused icon and it would not be affected. Or, should the user respond that it does not want the “Clean Desktop Wizard” to move unused icons into a folder, they will not be moved. Finally, even if the user responds affirmatively to the “Clean Desktop Wizard” ’s prompt, the icons merely will be moved into a folder, not removed.

212. One commentor argues that Microsoft frequently could create “new versions” of its Windows Operating System Products for the sole purpose of creating new mechanisms to remove competing icons.^[210] The United States finds it unlikely that Microsoft would go to the lengths required to release a new version of its operating system just to remove icons, given that any such mechanism must be unbiased with regard to Microsoft and Non-Microsoft products. Historically, Microsoft has released versions of its operating systems on the order of years apart, and at much longer intervals than its releases of middleware.

4. Timing Issues

213. Some commentors argue that the 12-month delay before Microsoft has to implement Section III.H simply allows Microsoft more time to cement its control over the operating system.^[211] Some commentors compare the 12-month delay to the less than 2 months it took Microsoft to remove the icons for Internet Explorer after the Court of Appeals' decision.^[212]

214. Section III.H takes effect with the earlier of the release of Service Pack 1 for Windows XP, currently scheduled for August 2002, or November 6, 2002. The reason for this delay was to allow Microsoft sufficient time to modify its Windows Operating System Products to be in compliance with the specific provisions of Section III.H. Section III.H requires Microsoft to make numerous changes to Windows 2000 and Windows XP. For instance, a mechanism must be created that allows end users and OEMs to enable and remove end-user access to Microsoft and Non-Microsoft Middleware Products that is non-discriminatory with regard to those products and that presents a separate and unbiased choice. As noted above, the current Add/Remove utility in Windows XP is biased: it lists the Microsoft Middleware Products in a separate window labeled as system components. Moreover, the current Add/Remove utility includes only a subset of the Microsoft Middleware Products and does not remove all of the required means of end-user access, but only some limited subset of icons.

215. Additionally, in accordance with Section III.H.2, Microsoft must evaluate every invocation of a Microsoft Middleware Product and determine if it falls under Section III.H.2, whether it falls under exception (a) or (b), and whether there is already a default setting. If there is not a default setting, or if in some cases the Windows Operating System Product does not respect the default, then the Windows Operating System Product must be altered.

216. Commentors who point to the relatively small amount of time between the Court of Appeals' decision and Microsoft's limited allowance of flexibility as evidence that the delay in Section III.H is excessive are comparing very different situations. Microsoft made an extremely limited offer to OEMs to alter end-user access to Internet Explorer in the summer of 2001. Similarly, Microsoft's addition of Internet Explorer to the Add/Remove utility was not complete and did not remove many of the means of end-user access. To comply with the RPFJ, bothin terms of the required means of end-user access and the number of Microsoft Middleware Products at issue, requires considerably more effort. In addition, Microsoft's offer in the summer of 2001 did not contain any changes regarding automatic invocations, which can require considerably more work than the creation of a revised Add/Remove utility.

217. Another commentor argues that Microsoft has no incentive to offer the Windows XP Service Pack until December 2002, that the 12-month delay renders the provision meaningless for a fifth of the lifespan of the decree, and that the provision is therefore meaningless as a vehicle for restoring competition.^[213] The same commentor argues that, in contrast, the interim conduct provisions in the IFJ were superior because they required the removal of end-user access within six months of the entry of the Final Judgment.^[214]

218. Many aspects of this comment are erroneous. First, the deadline for compliance is November 6, 2002, not December. Moreover, Microsoft has a strong incentive to release Service Pack 1 for Windows XP, because it is well-known in the industry that the first Service Pack to an operating system release fixes many of the bugs in the original release. More specifically, many corporations do not consider upgrading until the first Service Pack is released. Windows XP, based on the NT code base and being the upgrade to Windows 2000, is aimed directly at corporations as well as consumers, unlike releases such as Windows Millennium and other operating systems based on the “9x” code. In order to serve the corporate audience at which Windows XP is at least partially directed, release of the first Service Pack is critical. Thus, the United States remains convinced that Microsoft has a strong incentive to release the first Service Pack for XP as quickly as possible. The United States is aware, however, that the Service Pack has slipped from a planned late spring release to an August 2002 release.

219. Additionally, it is important to realize that the 12-month period started on November 6, 2001, and the five-year life span of the decree begins when the decree is entered, which will be at some point after March 6, 2002. Thus, even if the Court enters the decree on March 6, 2002, the maximum amount of time the delay can “cut into the life of the decree” is eight months, not twelve. If the Court waits to enter the decree, the overlap decreases. For example, should the Court enter the decree on May 6, 2002, then the provision will become effective no later than six months after the entry of the decree (precisely the same time period contained in the IFJ).

220. The possibility that the provision will become effective six months after the decree is entered is identical to the timing in the IFJ, which required that the removal of end-user access would occur six months after entry. Moreover, the IFJ had no provisions at all regarding the creation and respect for default settings. Thus, the IFJ would have possibly required less with the same amount of delay.

221. Finally, to argue that the timing of the Litigating States' proposals is superior is to ignore the reality of the litigation schedule. Even assuming the shorter of the two proposed litigation schedules, the Litigating States' trial will not end before June 2002. Assuming that the Court issues its ruling immediately, which is highly unlikely given the complexities of the case, the earliest the Litigating States' provision on removing end-user access would be applicable is December 2002. To argue that the RPFJ is “meaningless as a vehicle for restoring competition” because of the timing of Section III.H when, in fact, the RPFJ will with absolute certainty be in effect before the Litigating States' remedy, is to argue that there is no possibility of an effective remedy. That argument simply is wrong.

222. Other commentors allege that the requirement that the Microsoft Middleware Products must exist seven months before the last beta test version of a Windows Operating System Product is a loophole easily exploited by Microsoft.^[215] These commentors suggest that specific products, such as Windows Media Player 8, were not in existence at the requisite time and therefore are not subject to Section III.H. At least one commentor proposes that the whole timing paragraph be deleted.^[216]

223. The timing paragraph is necessary to give Microsoft sufficient time to design, implement and test the Windows Operating System Product, particularly the requirement for automatic invocations, in order to comply with the decree. Without the timing requirement, Microsoft conceivably could be required to redesign its products constantly. Moreover, it is important to understand how the requirement for automatic invocations will work in practice. Seven months before the last beta test release of a Windows Operating System Product, in every place where a Microsoft Middleware Product is invoked so as to require a default setting under Section III.H.2, the Windows Operating System Product will be modified so as to create and respect the default setting. However, once that setting is created, for instance for a default browser or a default media player, any competing product may register itself for the default. Moreover, if any version of a Microsoft Middleware Product can be invoked, then the setting must be created and respected. To be specific, if seven months prior to the last beta test release of Windows XP, Windows Media Player 8 does not exist, but Windows Media Player 7 exists, and the Windows Operating System Product can invoke version 7 as well as version 8, then the default must be created. Thus as a practical matter, when a default setting is created for media player, it is created for the whole category of media players, not just specific versions.

224. One commentor maintains that Section III.H.3 requires vendors of competing middleware to meet “reasonable technical requirements” seven months prior to new releases of Windows, yet it does not require Microsoft to disclose those requirements in advance.^[217] This comment incorrectly commingles the seven-month timing requirement with exception (b) to Section III.H.2. The seven-month timing requirement relates solely to the issue of which Microsoft Middleware Products exist at a certain time; it does not have anything to do with whether any Non-Microsoft Middleware Products meet certain technical requirements. The seven-month timing requirement determines when a default setting is required to exist; exception (b) concerns the limited circumstances where, given that the default setting exists, the Windows Operating System Product may nevertheless ignore a designated Non-Microsoft Middleware Product.

F. Commingling of Operating System Code and Middleware Code

225. Sections III.C and III.H of the RPFJ remedy Microsoft's anticompetitive commingling of browser and Windows operating system code by requiring Microsoft to redesign its Windows Operating System Products to permit OEMs and end users effectively to remove access to Microsoft Middleware Products (Section III.H.1) and to allow competing middleware to be featured in its place (Section III.C).Section III.H also requires Microsoft to create a mechanism that permits rival middleware products to take on a default status that will, if the consumer chooses, override middleware functions Microsoft has included in the operating system in many cases (Section III.H.2).

226. A number of commentors assert that, in spite of these provisions, the RPFJ is deficient because it does not contain an express prohibition on Microsoft “commingling” the code of Middleware Products in the same files as the code for the operating system.^[218] They note that the Court of Appeals upheld the District Court's liability determinations regarding both Microsoft's elimination of the Add/Remove capability for its browser and its commingling of browser code and operating system code. But the Court of Appeals did not hold that commingling of code alone, without regard to any anticompetitive effects it might have in a particular case, is anticompetitive or illegal. In fact, the United States challenged, and the Court condemned, Microsoft's practice of commingling operating system and Internet Explorer browser code for a specific reason: because the commingling in that instance had the purpose and effect of preventing OEMs and end users from removing access to the browser from Windows.

227. Some comments suggest that the lack of a ban on commingling in the RPFJ retreats from the position on commingling that the United States took in the prior remedy proceeding and that the District Court adopted in the IFJ. These commentors assert that the IFJ actually prohibited Microsoft from commingling code for middleware with code for the operating system.^[219] In fact, however, the IFJ's anti-binding provision, Section 3.g, only required that Microsoft make available a version of Windows in which “all means of end-user access” to Microsoft Middleware Products could be removed by OEMs or end users. IFJ § 3.g.i (emphasis added).^[220]

228. The United States has, throughout the remedy phases of this case (including before the District Court in June 2000), stated consistently that it did not seek to require Microsoft to remove commingled code from Windows. The United States' remedy briefs in the June, 2000 proceeding made clear our view that the competitive problems created by Microsoft's bundling of middleware would be addressed adequately by ensuring the ability to remove end-user access, and not the ability actually to remove code:

Microsoft suggests that Section 3.g.'s requirement of removal of “end user access” dramatically increases the scope of what is a “Middleware Product.” But only if a product first meets the definition of “Middleware Product” is Microsoft required to provide the means of removing access to it. . . . Similarly, Microsoft's statement that features like the user interface, HTML Help, and Windows Update would be “precluded” because they “are dependent on Internet Explorer” is erroneous. Section 3.g. requires that OEMs and end users be able to remove access only to the middleware product—in this case the browser—not to APIs or code. See Felten Declaration ¶¶ 92, 94; Findings ¶¶ 183-185.”^[221]

Plaintiffs' Reply Memorandum In Support of Proposed Final Judgment at 62 (filed May 17, 2000) (emphasis added).^[222]

229. The reason for the United States' consistent position is that, under the facts proven at trial in this case, the competitive significance of Microsoft's commingling is the exclusion of competing middleware products caused by the visible presence and usage of Microsoft's Middleware Product, not by the mere presence of the underlying code. The Court of Appeals concluded that Microsoft's commingling had an anticompetitive effect and constituted exclusionary conduct because commingling “deters OEMs from pre-installing rival browsers, thereby reducing the rivals' usage share and, hence, developers' interest in rivals' APIs as an alternative to the API set exposed by Microsoft's operating system.” Microsoft, 253 F.3d at 66. The Court of Appeals relied upon and upheld the District Court's findings, which reflect a concern primarily with the confusion and exclusion caused by the visible presence of Microsoft's middleware and rival middleware.^[223] For example, in describing Microsoft's initial commingling in Windows 95, the District Court found:

Although users were not able to remove all of the routines that provided Web browsing from OSR 2 and successive versions of Windows 95, Microsoft still provided them with the ability to uninstall Internet Explorer by using the “Add/Remove” panel, which was accessible from the Windows 95 desktop. The Add/Remove function did not delete all of the files that contain browsing specific code, nor did it remove browsing-specific code that is used by other programs. The Add/Remove function did, however, remove the functionalities that were provided to the user by Internet Explorer, including the means of launching the Web browser. Accordingly, from the user's perspective, uninstalling Internet Explorer in this way was equivalent to removing the Internet Explorer program from Windows 95.

Findings of Fact,¶ 159 (emphasis added). The District Court went on to find that, even with commingling of code, “[i]f OEMs removed the most visible means of invoking Internet Explorer, and preinstalled Navigator with facile methods of access, Microsoft's purpose in forcing OEMs to take Internet Explorer—capturing browser usage share from Netscape—would be subverted.”Id.¶ 203.

230. In spite of this clear basis for the District Court's and Court of Appeals' conclusions, some commentors assert that the mere fact of commingling itself deters OEMs from installing rival middleware.^[224] Other commentors ignore the basis of the courts' commingling analyses and argue that the competitively significant component of Microsoft's integration is the resulting presence of middleware APIs on every PC on which Windows is installed, whether or not end-user access to the middleware product has been removed and, from the user's standpoint, that product is no longer present.^[225] They argue that Microsoft's ability to obtain, through integration of middleware into Windows, ubiquitous distribution of its APIs without regard to the presence or absence of access to the product, will be competitively determinative, and that no rival middleware producer can overcome Microsoft's advantage and persuade developers to write to its products.^[226] Usage is only a means to an end, they argue, with the end being the widespread presence of APIs on PCs.

231. These theories of competitive harm advanced by the commentors are not based on the facts proven by plaintiffs at trial, reflected in the District Court's findings, and upheld by the Court of Appeals. The basis for commingling liability, and remedy, in this case is the presence, from the user's perspective, of the product, and consequent confusion and other deterrents to installation of additional, rival middleware products; the mere presence of APIs is not enough. Indeed, although Microsoft argued vigorously in its defense during the liability phase that removing end-user access amounted to no more than “hiding” the middleware, an act of no competitive significance, that argument was never accepted.

232. Thus, a ban on commingling without regard to its competitive significance, as many commentors appear to seek, would impose a wholly unnecessary and artificial constraint on software design that could have adverse implications for consumers.^[227] Moreover, changes to the operating system that would be required to implement such a blanket prohibition likely would have adverse effects not only upon Microsoft and its customers but also upon third parties that already have designed software to rely on the present operating system code. A flat prohibition on commingling in this particular case, without due regard to the competitive impact of that commingling, therefore likely would be harmful, not helpful.

233. Some commentors point out that, even if end-user access to a Microsoft Middleware Product has been removed by an OEM or end user pursuant to Section III.H.1, that product may still launch in certain default situations addressed by Section III.H.2 of the RPFJ, and therefore unacceptable end-user confusion will persist even after the access-removal remedy.^[228] But this argument overlooks the Court of Appeals' decision, which held that certain instances of Microsoft's “hard-wiring” its browser so that it would launch in particular situations even where the user had designated another browser as the default were not unjustifiably anticompetitive. Microsoft, 253 F.3d at 67.

234. A number of commentors argue that, even with the ability to remove access to Microsoft Middleware, commingling Middleware code with Windows in a way that is non-removable actually diminishes the value and worsens the performance of Microsoft's products, by causing decreased reliability or increased susceptibility to security risks.^[229] As one commentor correctly notes, however, this impact of commingling on the quality of Microsoft's products was not an apparent basis for the Court of Appeals' sustaining the liability determination for this conduct.^[230] Rather, the exclusionary character of commingling in a non-removable fashion formed the basis for the court's ruling. Microsoft, 253 F.3d at 66.^[231]

235. In arguing for complete removal of middleware code from the operating system, some commentors seek to extend the findings on commingling to a more direct attack upon Microsoft's practice of providing middleware functions in the Windows operating system. That practice was the subject of the tying claim and was part of the attempted monopolization claim, neither of which was sustained by the Court of Appeals. Requiring Microsoft completely to disintegrate middleware functions from the operating system might have been a more appropriate remedy for those claims, had they been sustained, than for the more limited claim of commingling of the browser and operating system code. In that sense, these commentors seek relief that exceeds the bounds of the monopoly maintenance finding that is the sole basis for relief at this stage of the case. Consistent with its position throughout the remedy phase of this litigation, the United States' concern with commingling is appropriately and fully addressed by the remedies proposed in the RPFJ.

236. Finally, at least one commentor complains that the RPFJ is deficient because it does not require Microsoft to license to OEMs versions of Windows from which the means of end-user access have been removed at lower royalty rates than the version of Windows that includes full access to Microsoft Middleware Products.^[232] There is no basis for such a provision under the Court of Appeals' ruling in this particular case. First, the Court of Appeals indicated that the question of whether Microsoft price bundled, that is, charged more for Windows and IE together than it would have charged for Windows alone, has not yet been answered.^[233] Second, the Court of Appeals noted that it had “no warrant to condemn Microsoft for offering either IE or the IEAK [Internet Explorer Administration Kit] free of charge or even at a negative price.”^[234]

V. Retaliation Against ISVs or IHVs (RPFJ § III.F)

237. Section III.F of the RPFJ prohibits Microsoft from retaliating against an ISV or IHV, or entering into agreements that condition the grant of consideration to an ISV, based on the firm's refraining from developing or other involvement with software that competes with Microsoft Platform Software or software that runs on such a competing platform. The provision provides limited exceptions.

A. Comments on Section III.F.1

238. Section III.F.1 prohibits Microsoft from retaliating against any ISV or IHV because of its development, usage, distribution, promotion, orsupport of any software that competes with a Windows Operating System Product or a Microsoft Middleware Product or software that runs on any such competitive software.

239. Some commentors question the appropriateness of any anti-retaliation provision. One expresses skepticism that any injunctive provision can effectively constrain Microsoft's behavior and recommends the imposition instead of a structural remedy.^[235] The United States believes that an injunction against retaliation effectively can deter Microsoft from anticompetitive behavior of the kinds found illegal by the Court of Appeals. The United States continues to believe that its decision not to seek structural relief in the current proceeding is appropriate in light of that appellate ruling.^[236] Injunctive relief cannot turn back the clock, but it can meet the relevant remedial goal of restoring competitive conditions in the market.^[237]

240. One commentor objects to the language used in Section III.F.1. It contends that “retaliate” is left undefined and that the RPFJ addresses only retaliation that occurs “because of” a firm's acts with competing software, leaving Microsoft free to argue in the future that some given act does not qualify as retaliation and was not caused by the other firm's acts.^[238] But retaliation is not an unfamiliar, ambiguous, or technical term. It carries the clear meaning of taking adverse actions that the commentor recommends. Moreover, the commentor's preferred alternative to “because of”—“based directly or indirectly,” the language used in IFJ § 3(d) and in the Litigating States' Proposal § 8—puts the same, appropriate, obligation to show that some adverse action by Microsoft toward an ISV or IHV was spurred by the ISV's or IHV's prior behavior. Indeed, without an obligation to show such adverse action, retaliation could be improperly read to cover withholding any benefit in response to an undesired action. For example, if Microsoft decided for valid business reasons that it no longer wanted to engage in a particular transaction, it could be accused of retaliating.

241. Commentors suggest several increases to the breadth of Section III.F.1's prohibition against retaliation. First, commentors contend that the ban should cover threats of retaliation by Microsoft rather than only acts of retaliation.^[239] But because the RPFJ prohibits retaliation itself, any threat of retaliation is necessarily empty—and, if anything, likely to encourage reporting of perceived and ambiguous “threats.” The United States therefore believes that prohibiting threats is unnecessary. In a related vein, one commentor contends that the ban should cover “coercion short of an agreement,” apparently meaning instances in which firms undertake voluntary actions to prevent Microsoft from becoming displeased.^[240] Such a provision would be inappropriately vague, making the legality of Microsoft's actions dependent in part on the perceptions of the “coerced” ISV or IHV.

242. Second, a commentor suggests that Section III.F.1 should prohibit Microsoft from threatening or bringing suit for infringement of Microsoft's intellectual property portfolio.^[241] The United States disagrees. The purpose of the RPFJ is to allow competitors freedom to develop and market their own software to challenge Windows, not to allow them to appropriate Microsoft's intellectual property.^[242]

243. Third, several commentors suggest Section III.F.1 should ban retaliation against firms other than ISVs and IHVs; Litigating States' Proposal § 8, for instance, additionally would bar acts of retaliation against IAPs, ICPs, OEMs, or Third-Party Licensees.^[243] Such additions are unnecessary. The RPFJ already does ban retaliation by Microsoft against OEMs, in Section III.A. And Section III.G bans the kinds of pressure that Microsoft actually used against IAPs and ICPs in the past, and would be most likely to use again in the future absent the RPFJ. In covering ICPs, the RPFJ in fact goes beyond the Court of Appeals' ruling, which found that “the District Court's findings [with respect to the deals with ICPs] do not support liability.”Microsoft, 253 F.3d at 71. The District Court did make factual findings about what Microsoft did to the ICPs, and nothing that the District Court or the Court of Appeals said about the lack of competitive effect of those actions negates the truth of their factual findings on them.

244. Fourth, commentors suggest the prohibition should ban retaliation related to a broader class of software than that contemplated in Section III.F.1.^[244] They argue that Microsoft should be prohibited from retaliating against ISVs' and IHVs' actions with regard to any products or services that compete with any Microsoft products or services. This expansion is unnecessary to achieve the goal of the RPFJ, which is to ensure that firms can freely choose to promote the popularization of operating systems or middleware that might ultimately threaten Microsoft's operating system monopoly by lowering the applications barrier to entry. The RPFJ does so by protecting ISVs' and IHVs' right to distribute or otherwise promote “any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software.” ISVs' and IHVs' activities with respect to Windows applications or Microsoft hardware, to take two examples raised by the commentors, are unlikely to affect the barrier to entry that protects Windows and so are outside the appropriate scope of the RPFJ.

245. Fifth, a commentor suggests that the RPFJ should prohibit Microsoft from retaliating against firms that make a good faith complaint against Microsoft for violating the RPFJ but whose complaint is ultimately either not brought forward to the court for action or is ruled by the court not to be a violation.^[245] The RPFJ does, in fact, give firms such protection: Section III.A.3 (OEMs) and Section III.F.1.b (ISVs and IHVs) explicitly prohibit Microsoft from retaliating against firms for “exercising any of the options of alternatives provided for under this Final Judgment,” including the right of complaint guaranteed by Section IV.D.1.

246. Finally, several commentors suggest that Section III.F.1 should explicitly prohibit Microsoft from retaliating against firms that have participated or cooperated with the Government in this litigation.^[246] For a discussion of the merits of including a provision that prohibits retaliation for participation in this litigation, see Section XI(G) below.

B. Comments On Section III.F.2

247. Section III.F.2 prohibits agreements relating to Windows Operating System Products that condition the grant of Consideration (a defined term in the RPFJ that encompasses both monetary and nonmonetary benefits) on an ISV's refraining from developing, using, distributing, or promoting the same kinds of software addressed in Section III.F.1—software that competes with a Windows Operating System Product or a Microsoft Middleware Product or software that runs on any such competitive software. A limited exception permits Microsoft to enter such agreements if they are “reasonably necessary to and of reasonable scope and duration in relation to a bona fide contractual obligation of the ISV to use, distribute or promote any Microsoft software or to develop software for, or in conjunction with, Microsoft.”

248. Several commentors argue that the language of this exception is vague and subject to abuse by Microsoft, allowing it to prevent ISVs from entering partnership and other agreements with rival firms.^[247] Microsoft, however, may only enter agreements that limit the ISV's activities with rival software to the extent that those limitations are reasonably related to a bona fide contractual relationship between Microsoft and the ISV. It is important to protect ISVs' opportunity to engage in legitimate, procompetitive arrangements with Microsoft. For example, Microsoft could enter into an agreement that provides an ISV with funds for the promotion of Microsoft software and prohibits the ISV from spending those funds to promote rival software. In contrast, contrary to the concerns of one commentor, Microsoft could not enter into an agreement that provides an ISV with assistance in promoting a Microsoft product on condition that the ISV not also distribute, use, or promote a rival product, because such a limitation would not be reasonably related to the ISV's obligation to promote the Microsoft product.^[248]

249. One commentor argues that the language of the exception in Section III.F.2 is no more precise than a simple statement of the antitrust rule of reason, and, because it offers no guidance to the Court about how to distinguish between a “bona fide contractual obligation” and an anticompetitive exclusionary requirement, may establish a rule even more permissive than the rule of reason.^[249] There is a necessary trade-off in an injunctive provision, and in exemptions from such a provision, between specificity and generality. The more specific the provision about the behavior that is permitted or prohibited, the greater the opportunity for the affected firm to tailor anticompetitive activities to avoid court supervision. The exemption in Section III.F.2, with its reliance on general but established legal terms such as “reasonable,” “reasonably necessary,” and “bona fide,” allows the United States and the court to consider the substance and not the mere form of Microsoft's future agreements with ISVs. Absent this limited exception, Section III.F.2 would prohibit otherwise lawful collaborations, with no legal basis in the findings of this case.

250. One commentor objects that Section III.F.2, which begins with the words “Microsoft shall not enter into any agreement,” grandfathers any existing agreements that would otherwise be impermissible.^[250] It is correct that Section III.F.2 only applies to agreements signed after the date of entry of the RPFJ. This limitation should have little impact, however, because Microsoft must regularly rewrite its agreements with ISVs in order to encourage them to write to and redistribute Microsoft's newest APIs and technologies.

251. Finally, at least one commentor expresses concern that Section III.G does not contain language similar to Provision 3.h (“Agreements Limiting Competition”) of the IFJ, and so would permit Microsoft to seek to enter market allocation agreements like those it proposed to Netscape and Intel.^[251] The commentor's concern is addressed not in Section III.G, but here in Section III.F.2, which does in fact substantially prohibit agreements that limit competition. Under its terms, Microsoft may not “enter into any agreement relating to a Windows Operating System Product that conditions the grant of any Consideration” on an ISV's refraining from various forms of involvement with software that runs on, or itself is, software that competes with Microsoft Platform Software. To the extent that any agreements that limit competition are not covered by Section III.F.2, they can of course be addressed by other means: Microsoft could be prosecuted, at minimum under Sherman Act § 1, for any market allocation agreement that it reached with a competitor or competitors.

C. Comments On Section III.F.3

252. Section III.F.3 simply states that nothing in Section III.F shall prohibit Microsoft from enforcing any property right or any provision of an agreement with an ISV or IHV that is not inconsistent with the RPFJ.

253. Several commentors apparently misread Section III.F.3 as introducing a loophole or somehow granting Microsoft rights and powers that it does not now have.^[252] Section III.F.3 merely states with clarity the intended limits of the remainder of Section III.F.

VI. Exclusionary Agreements (RPFJ § III.G)

254. Commentors raise a variety of concerns about Section III.G, which prohibits Microsoft from entering into a variety of exclusionary agreements. The objections generally fall into two categories: concerns about omissions from Section III.G, and concerns about Section III.G's exceptions.

A. Omissions

255. At least one commentor expresses concern that Section III.G does not contain language similar to Section 3.h (“Agreements Limiting Competition”) of the Initial Final Judgment, and so would permit Microsoft to seek to enter market allocation agreements like those Microsoft proposed to Netscape and Intel.^[253] Although Section III.G does not cover such agreements, Section III.F.2 does.

256. Some commentors object that the RPFJ does not contain a provision prohibiting Microsoft from granting consideration to a third party for agreeing not to use or distribute non-Microsoft products or services, a provision that the United States argued for in the earlier remedy proceeding and which was included in the IFJ (§ 3.e.i).^[254] In a similar vein, one of the same commentors objects that RPFJ Section III.G.2, which prohibits Microsoft from granting placement in Windows to an IAP or ICP on condition that it refrain from distributing certain competing software, reflects phrasing supported by Microsoft and opposed by the United States in the previous proceeding.^[255] Since the time of the June 2000 IFJ, of course, the Court of Appeals has ruled on liability—narrowing the District Court's ruling and vacating the IFJ itself. The language of RPFJ Section III.G does prohibit the kinds of agreements—e.g., between Microsoft and IAPs—that the Court of Appeals found to be unlawful.^[256]

257. Several commentors contend that, unlike the Litigating States' Proposal (§ 6), RPFJ Section III.G covers Microsoft's contracts with only named categories of trading partners and may omit others who are important, e.g., large corporate end-user purchasers.^[257] Section III.G.1 does, however, cover contracts between Microsoft and any IAP, ICP, ISV, IHV, or OEM. Section III.G.1 thus achieves its desired goal of ensuring that Microsoft cannot use exclusive agreements to tie up key channels of distribution for competing middleware and operating systems—indeed all channels of distribution that were discussed at trial.^[258] End users, including corporate end users, will be able freely to choose the software products they wish to use.

B. Exemptions

258. Commentors raise several issues regarding two exemptions in Section III.G. The first concerns the “commercially practicable” exemption to Section III.G.1; the second concerns the joint venture exception that applies to all of Section III.G.

259. Section III.G.1 does not apply to agreements if Microsoft obtains in good faith a representation from the contracting third party that it is “commercially practicable” for it to provide equal or greater distribution for competing non-Microsoft software, whether or not it actually distributes that non-Microsoft software.^[259]

260. At least one commentor misreads the language of Section III.G.1, asserting that the provision permits Microsoft to demand distribution of its own software at what Microsoft deems to be a commercially practicable level.^[260] The representation of “commercial practicability” by a third party contained in Section III.G.1 does not, however, refer to its distribution of Microsoft software, but of non-Microsoft software.

261. Nor does Section III.G.1 give Microsoft an affirmative right to demand that third parties carry its products, as another commentor claims.^[261] The provision merely describes the terms that Microsoft is permitted to offer to a third party. Moreover, the provision does not give Microsoft any power to affect the circumstances that determine the acceptable terms: Microsoft cannot force or require a third party to make a representation about the commercial practicalities that it faces.

262. Some commentors contend that third parties are likely to make empty representations to Microsoft in exchange for preferential treatment. That is, a third party like an OEM is more likely to say that it could carry competing products than actually carry those products, because it would not want to distribute two similar products on a particular computer that it sells.^[262] But this criticism misses the fact that the OEM may well choose to offer the non-Microsoft product on, for example, 50% of its product line, and the Microsoft product on the other 50%, thus allowing the consumer to choose freely among differentiated computer/software bundles. The United States believes that, contrary to the concern raised by at least one commentor, this provision will prevent Microsoft from guaranteeing that rival technology will not become broadly available.^[263] Further, the “good faith” requirement ensures both that Microsoft cannot make a representation of commercial practicability a standard part of its license agreements and that Microsoft could not rely on this exemption where it knows that a representation of commercial practicability is not legitimate.

263. A number of commentors contend that Microsoft will be able to obtain representations of commercial practicability from third parties simply by paying them sufficiently.^[264] Section III.G.1, however, makes it logically impossible for Microsoft to seek—much less get—any form of exclusive distribution, promotion, use, or support on all of a third party's products, no matter how much Microsoft is willing to pay. Microsoft cannot, for instance, pay an ICP to make its content available in a format readable only by Windows Media Player, because it is logically impossible for that ICP to represent that it could also simultaneously make that content available only in a format readable only by some non-Microsoft media software.

264. Commentors also raise issues about Section III.G's exemption for certain joint venture and joint development or services arrangements, under which a third party can be prohibited from competing with the object of the joint arrangement for a reasonable period of time.

265. One commentor in this group complains that the standard enunciated in Section III.G for an agreement to qualify for this exemption is nothing more than a restatement of the traditional antitrust rule of reason.^[265] This contention, however, overlooks the exemption's careful limitations. The exemption applies only to bona fide joint ventures and to other joint agreements for certain specific productive activities, and only those in which both Microsoft and the other party contribute significant resources. Further, these commentors overlook that nothing in the Court of Appeals' decision warrants denying Microsoft the ability to enter into joint arrangements, which may have procompetitive benefits for the market.

266. The requirement that a joint development or services agreement must create either a new product, service, or technology, or a material value-add to one that already exists addresses the concerns raised by several commentors that Microsoft could use Section III.G to block competition with joint activities that create nothing more than routine alterations to Microsoft or non-Microsoft products.^[266]

267. Some commentors question whether Microsoft could manipulate its interpretation of, for instance, “significant developer or other resources” in order to invoke the exemption to cover activities that are not truly joint.^[267] What constitutes a “significant” resource is not spelled out in the RPFJ because it is a familiar term and concept in antitrust enforcement. For example, the Antitrust Guidelinesfor Collaborations Among Competitors issued jointly by the Federal Trade Commission and Department of Justice in April 2000 describe the contribution of “significant capital, technology, or other complementary assets” as a hallmark of efficiency-enhancing collaborations between firms. (FTC/DOJ Antitrust Guidelines for Collaborations Among Competitors, 8).

268. The United States, of course, retains power to evaluate and seek enforcement of the RPFJ against sham joint arrangements. Microsoft cannot, as some commentors suggest, take the identical distribution agreements found unlawful at trial and exempt them from Section III.G merely by characterizing the agreements as “joint” activities.^[268] As the Court of Appeals found (Microsoft, 253 F.3d at 72), Microsoft's exclusionary agreements with ISVs, to take just one example, had no procompetitive justification; they cannot be considered legitimate joint activities to produce new or improved products, technologies, or services, and so would not be exempted from Section III.G.

269. Another commentor notes^[269] that the United States objected in June 2000 to Microsoft's proposal for a joint-venture exception to Section 3.h of the Initial Final Judgment(“Ban on Agreements Limiting Competition”). The exception in RPFJ Section III.G, however, is narrower than the broad exception Microsoft proposed, and it is tailored to permit only joint activities that are genuinely procompetitive, those that are not mere shams for market allocation agreements but require firms legitimately to share significant resources to create new or improved opportunities for consumers. A non-compete clause with a legitimate joint venture is not, contrary to one commentor's view, necessarily inappropriate merely because Microsoft is one of the parties to the joint venture.^[270] Both the United States and the courts consistently have noted that such procompetitive joint ventures do exist and that Microsoft should be permitted to engage in them, see, e.g., IFJ § 3.a.ii (exception for “bona fide joint development efforts”).

270. Finally, some commentors raise similar concerns about whether Microsoft could abuse the exception in Section III.G for agreements “in which Microsoft licenses intellectual property in from a third party.”^[271] The exception permits Microsoft, in licensing new technology from an ISV for incorporation into a Microsoft product, to ensure that the ISV will not also license the same technology to a competitor who hopes to “free ride” on Microsoft's popularization of the technology. It therefore provides Microsoft with appropriate incentives to invest in such popularization. If Microsoft entered into an agreement with an ISV, or other third party, in which the licensing-in of such intellectual property is nothing more than a pretext for otherwise impermissible exclusionary terms, the United States would review the legitimacy of such an agreement under Section III.G.

VII. Disclosure Provisions (RPFJ §§ III.D, III.E)

A. Disclosure of APIs (RPFJ § III.D)

271. Many commentors raise issues concerning the disclosure of APIs in RPFJ Section III.D. The issues will be discussed in the following categories: First, issues concerning the products between which the APIs are disclosed will be discussed. Next, API issues, focusing on the substance of the disclosure, and the definitions of “API” and “Documentation,” will be discussed. Third, timing issues, including analysis of the definition of “Timely Manner,” will be addressed.

1. Product Issues

272. Section III.D calls for certain disclosures between Microsoft Middleware and a Windows Operating System Product. Many commentors argue that the definitions of Microsoft Middleware and Windows Operating System Product can be evaded easily; that products other than Microsoft Middleware should be included; or that products other than Windows Operating System Product should be included. Each of these will be addressed in turn. For a discussion of Microsoft Middleware itself, see Section III(B) above.

c. Microsoft's Ability To Manipulate the Definitions To Avoid Disclosure

273. Several commentors state that the API disclosure provisions are completely within Microsoft's control and that Microsoft can evade the provisions simply by labeling Microsoft Middleware as part of a Windows Operating System Product.^[272] Some misunderstand the interaction between the Windows Operating System Product and Microsoft Middleware definitions, arguing, for example, that interfaces between Internet Explorer and a Windows Operating System Product are not covered if Microsoft chooses to label Internet Explorer as part of Windows. This is incorrect. These comments fail to realize that a product can be both included in a Windows Operating System Product and still have code that qualifies as Microsoft Middleware. It does not matter if Microsoft labels Internet Explorer as part of Windows; what matters is that there is a separate distribution of Internet Explorer, and that the interfaces between this separate distribution and a Windows Operating System Product must be disclosed. For example, Internet Explorer 6.0 is distributed separately and included in Windows XP. Under the RPFJ, the code that is distributed separately is Microsoft Middleware regardless of whether Microsoft also calls Internet Explorer a part of Windows. Concerns that Microsoft can relabel code as being part of Windows and thus evade the disclosure provisions are unfounded; it is the separate distribution that matters, not the Windows label.

274. Another commentor argues that Microsoft can evade disclosure by removing the APIs from a Windows Operating System Product.^[273] This is illogical. If the APIs are not in Windows, then they cannot be used by any software, whether that software be Microsoft Middleware or competing products. At a basic level, it is important to remember that Microsoft chooses which APIs to develop and make part of Windows in the first instance. Microsoft controls which software products it develops and which it does not, and Section III.D is about disclosure of certain APIs within those products.

b. Products Other Than Microsoft Middleware

275. Some commentors argue that Section III.D should require Microsoft to disclose interfaces between Windows Operating System Products and products other than Microsoft Middleware.^[274] Some argue that all Microsoft applications that run on Windows, for instance, Office, shouldbe covered.^[275] Others argue that software that never has been distributed separately should be covered. Still others phrase the argument in terms of disclosing “all Windows APIs.”^[276] Others find the limitation to Microsoft Middleware to be appropriate.^[277]

276. Disclosure of the interfaces between all Microsoft applications that run on Windows Operating System Products is considerably broader than the violations found by the Court of Appeals would justify, for several reasons. First, the word “applications” does not have a specific meaning, and could refer to almost any software code. The term is not limited to software of any particular size or purpose and could be interpreted to include the smallest pieces of software. Nor does the term have any relation to whether the software exposes any APIs or could ever be used as Platform Software itself. Thus, for instance, a clock, a solitaire program, and Microsoft's Flight Simulator and Age of Empires games all would be included. The cost to Microsoft of hardening and documenting the interfaces between all these pieces of software would be substantial, and the United States does not see how it would increase materially the ability of competing middleware to threaten Microsoft's operating system monopoly.

277. As phrased by one commentor, the goal is to “allow competitive products to interoperate with Microsoft software on an equal basis as Microsoft's own products.”^[278] The United States views Non-Microsoft Middleware as competing for usage with Microsoft Middleware, and thus this provision seeks to ensure that Non-Microsoft Middleware will not be disadvantaged. The United States believes that the most competitively significant APIs are those used by the competing products, not those used by completely different types of software, such as games.

278. Moreover, as some commentors recognize, Microsoft already discloses thousands of APIs and has a strong incentive to disclose APIs.^[279] Microsoft's disclosure of APIs is what allows applications to be written to the Windows platform, and creates and sustains the applications barrier to entry. Section III.D is designed to require disclosure of APIs in those cases where Microsoft may have a strategic interest in withholding APIs that outweighs Microsoft's natural incentive to disclose them—namely, where Microsoft's own middleware is competing with rival middleware that threatens the applications barrier to entry.

279. Commentors who posit that “Windows APIs” should be disclosed fail to recognize the need for a clear line between which facets of Windows are disclosed and which are not. Windows, like most software, is comprised of modular blocks of code that “interface” to one another. Disclosing every interface in Windows is to disclose most of the source code. “Windows APIs” is simply not a defined set of APIs that appropriately can be subject to disclosure.

280. Some commentors argue that limiting disclosure to APIs used by Microsoft Middleware forces other applications merely to follow in the footsteps of Microsoft products and discourages new products.^[280] To the contrary, there is no requirement that any Non-Microsoft Middleware use the same APIs as the Microsoft Middleware; nor is there any indication that the only way to accomplish a particular function will be to use the Microsoft Middleware APIs. For instance, early web browsers such as Mosaic in 1994 clearly did not have to use the same APIs as Internet Explorer, because Internet Explorer did not exist. Yet Mosaic was developed and gained widespread popularity, all by using the thousands of Windows APIs that were already published.

c. Products Other Than Windows Operating System Products

281. Some commentors argue that Section III.D should require Microsoft to disclose the interfaces between Microsoft Middleware and products other than Windows Operating System Products.^[281] Specifically, some opine that interfaces to other devices, such as handhelds or set-top boxes, should be covered. These comments are addressed under Section III.E.

282. Other commentors argue that the disclosure should be to the benefit of competing operating system vendors.^[282] For instance, some commentors argue that the disclosure should be for any purpose, and not just “for the sole purpose of interoperating with a Windows Operating System Product.”^[283] Some focus on the potential use of these APIs by other operating system developers. Several commentors go farther and propose that Microsoft be required to define the APIs that a competing operating system must provide to run Windows applications, or to implement a “Windows Application Environment” on other operating systems.^[284]

283. The violations proven and upheld in this case focused on middleware as the mechanism that threatened to lower the applications barrier to entry and therefore make other operating systems better substitutes for Windows. The intent of Section III.D is to ensure that future middleware threats will have the information about Windows they need in order not to be disadvantaged relative to Microsoft's own middleware. That is, the disclosure is not intended to permit misappropriation of Microsoft's intellectual property for other uses. Rather, the focus of the remedy, as of the Court of Appeals' ruling, remains restoring the competitive conditions to permit nascent threats to emerge.

2. API Issues

a. Definition of “API”

284. Several commentors criticize the definition of “API.” Significantly, one commentor points out that the definition only includes Microsoft APIs, rendering the other definitions that use the term API potentially meaningless.^[285] Specifically, the definitions of Non-Microsoft Middleware, Non-Microsoft Middleware Product and Operating System arguably fail to function as intended if the definition of “APIs” is limited to Microsoft APIs. This definition, as originally drafted, was intended to apply to Section III.D, and the definition of API has been modified in the SRPFJ to reflect the intention of the parties in drafting this definition. The RPFJ's definition of API has thus been inserted directly in Section III.D. A generic definition of API that is not tied to Microsoft products has been inserted as definition VI.A in the SRPFJ. The meaning of API in the definitions of Non-Microsoft Middleware, Non-Microsoft Middleware Product and Operating System is now defined according to this generic definition, thereby resolving any concerns about their reliance on an API definition that is specifically tied to Microsoft products. In the SRPFJ, the revised sections are as follows (new language underlined):

Section III.D. Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this FinalJudgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network (“MSDN”) or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. For purposes of this Section III.D., the term APIs means the interfaces, including any associated callback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new ver sion of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner.

Section VI.A. “API” means application programming interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.

285. Commentors argue that the definition of API (now as contained in Section III.D) is too narrow.^[286] In particular, several argue that it should include file and document formats. As the CIS explained, “interfaces” is used broadly to include any interface, protocol or other method of information exchange used when Microsoft Middleware calls upon a Windows Operating System Product. CIS at 33-34. One commentor argues that this means that APIs simply are the interfaces between two products.^[287] In general, this is correct “ the definition was designed to be read broadly to include any way in which Microsoft Middleware calls upon the services of a Windows Operating System Product. Thus, whatever Microsoft Middleware uses to request services from a Windows Operating System Product, whether it includes something that could arguably be called a “file format” or not, is the subject of disclosure. To the extent that these comments actually relate to whether applications such as Office should be considered Microsoft Middleware, those concerns are addressed above in the discussion of Products Other than Microsoft Middleware. See also Section VII(E) below.

286. Some commentors believe that APIs should include calls from a Windows Operating System Product to Microsoft Middleware, instead of the other way around.^[288] For instance, one commentor argues that the “Play All” and “Burn CD” interfaces in Windows XP should be disclosed.^[289] These concerns are more appropriately addressed under the default provisions in Section III.H. The disclosure provisions in Section III.D and the default provisions in Section III.H address different aspects of the relationship between Microsoft Middleware and a Windows Operating System Product. In simple terms, when Microsoft Middleware calls upon functionality in a Windows Operating System Product for services, that interface is subject to analysis under Section III.D (one can think of this as middleware “calling down” into the operating system for functionality). On the other hand, when a Windows Operating System Product invokes a Microsoft Middleware Product or a Non-Microsoft Middleware Product to perform a function, those invocations are analyzed under Section III.H (one can think of this as an operating system “calling up” to the middleware for functionality). The specific functions of “Play All” and “Burn CD” in Windows XP are examples of the latter, not the former. Similarly, issues of “hardwiring” are more appropriately addressed under Section III.H.^[290]

b. Definition of “Documentation”

287. Some commentors note that, in contrast to the IFJ, there is no definition of “technical information” and that instead the RPFJ uses the term “Documentation.” The commentors believe that the IFJ's definition of technical information was superior or that Documentation should be broader.^[291] Despite the many comments on this issue, the United States believes the definitions are very similar and produce largely similar results. To the extent there are differences, the United States believes they are due largely to problems and ambiguity in the IFJ's technical information definition.

288. The IFJ's definition of technical information was “all information regarding the identification and means of using APIs and Communications Interfaces that competent software developers require to make their products running on any computer interoperate effectively with Microsoft Platform Software running on a Personal Computer.” There then followed a list of examples of the type of information that might be provided in different circumstances. Some interpret the list as requiring the specified information in all circumstances; for instance, that for every interface a reference implementation and algorithms must be disclosed. This was never the intent of the definition, as any quick review will show, because some of the listed items only make sense for certain types of interfaces. The ambiguity and lack of clarity on this point was one of the reasons the definition was changed.

289. The controlling parts of the IFJ's technical information definition were intended to be “all information regarding the identification and means of using APIs . . . that competent software developers require.” The intent behind the previous definition was to ensure that if a competent software developer required it, it had to be provided, whether that be a reference implementation, an algorithm, or any other facet of the interface.

290. In the RPFJ, the first sentence of the definition of Documentation reads “all information regarding the identification and means of using APIs that a person of ordinary skill in the art requires to make effective use of those APIs.” The phrase “competent software developer” from the IFJ definition has been replaced with “a person of ordinary skill in the art” because the latter is clearer and more easily enforced, but the general intent is the same: if the information is needed by a person of the requisite skill, it must be provided.

291. The Documentation term also was defined to accommodate the RPFJ's separation of API disclosure and Communications Protocol licensing into two separate provisions and the greater specificity given to the API definition (now as used in Section III.D). Additionally, the second sentence of Documentation was added to clarify the level of specificity, precision and detail to be provided. However, the second sentence does not change the meaning of the first sentence; “all information . . . that a person of ordinary skill in the art requires to make effective use” of the APIs must be disclosed.

292. One commentor argues that Microsoft should not be allowed to disclose via MSDN because Microsoft allegedly has made its websites incompatible with non-Microsoft web browsers.^[292] Taking the opposite approach, another commentor argues that Microsoft only should be allowed todisclose via MSDN.^[293] MSDN at present is widely used by developers who wish to develop for Microsoft platforms, and it is an efficient mechanism for distributing disclosures to developers, although other efficient mechanisms could also be developed.

293. A few commentors raise concerns regarding completeness—either that there is no incentive for the Documentation to be complete or accurate, or that there is no way to tell whether it is sufficient.^[294] The United States believes that the enforcement mechanisms of the RPFJ are sufficient to address this issue. In particular, as discussed below, the Technical Committee will have full access to the source code and any other necessary information to resolve disputes concerning sufficiency of Documentation.

294. Finally, some commentors argue that the Litigating States' definition of technical information is superior. The Litigating States' definition contains one striking change from the IFJ definition: it requires information on implementing the APIs as well as on using them. The addition of this word appears to require Microsoft to provide information on how to implement functions in third-party products, such as how to implement the APIs, not so they can be used by the middleware, but so that those interfaces can be offered to others. This appears to be aimed at allowing competing operating system vendors to clone Windows APIs. The Litigating States' definition extends well beyond remedying the violations that the Court of Appeals sustained.

c. Source Code Access

295. Commentors raise several issues regarding disclosure of source code. First, the United States does not agree that an appropriate remedy in this case requires Microsoft to disclose and publish all of its source code for Windows Operating System Products, because that would be a disproportionate appropriation of Microsoft's intellectual property.^[295] Several other commentors complain that the RPFJ provides no access to source code for competitors, as was previously contained in the interim conduct remedies in the form of a “secure facility” provision.^[296] Instead, source code access is granted to the Technical Committee, accomplishing the same enforcement purpose without the same security concerns. When technical issues, such as whether Microsoft has disclosed all required APIs, are brought to the attention of the Technical Committee it is expected that they will consult the source code as necessary to resolve any issues. Additionally, unlike the secure facility, the Technical Committee supports anonymous complaints and can work with an industry participant without their identity being disclosed to Microsoft. Under the prior provision only “qualified representatives” had access, and the process of becoming a “qualified representative” could have required disclosure of the representatives” identity to Microsoft.

296. Moreover, it is important to note that the stated purpose of the “secure facility” provision was to facilitate compliance and monitoring. The United States believes that compliance and monitoring assessments are best performed by the United States, with assistance from the Technical Committee. To allow competitors source code access to facilitate compliance and monitoring is to place an inappropriate responsibility on competitors, who might have reasons to place their own interests above those of the U.S. public generally. Accordingly, the RPFJ calls for source code access to be available to the Technical Committee and the United States and puts the responsibility for compliance and monitoring on the United States.

297. Additionally, the removal of the secure facility provision does not change the amount of required disclosure under Section III.D. Disclosure still must be sufficient to provide “all the information . . . that a person of ordinary skill in the art requires to make effective use of those [disclosed] APIs.” This can include reference implementations or any other disclosure required to meet the requirement. If the documentation provided by Microsoft is not sufficient, then it must be revised until it satisfies the requirement. The United States maintains that it, with assistance from the Technical Committee, remains best suited to address these issues, for instance through RPFJ's voluntary dispute resolution procedures.

d. Intellectual Property Issues

298. A few commentors raise concerns that Microsoft is permitted to retain certain intellectual property rights over its interfaces.^[297] These commentors argue, for instance, that Microsoft still can patent or have other exclusive legal rights that prevent competing software developers from developing on other platforms. Another suggestion is that Microsoft be required to announce the subject matter of its patents, such that developers can tell which interfaces can be used without risk of patent infringement. These issues are addressed in Section XII(E) below.

3. Timing Issues

299. Several commentors raise issues concerning the timing of the API disclosures. These issues can be divided into three categories: when the first disclosures shall occur; when disclosures will be triggered by a new version of Microsoft Middleware; and when disclosures will be triggered by a new version of a Windows Operating System Product.

a. First Disclosures: Windows XP Service Pack 1 or No Later Than November 2002

300. The RPFJ calls for API disclosure to occur first at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of the RPFJ to the court, i.e., November 6, 2002. Currently, Service Pack 1 is scheduled to be released in August 2002. Several commentors argue that there is no reason for this delay, and that the APIs should be released immediately, or at any rate sooner than November 2002.^[298]

301. This delay was necessary to allow Microsoft time to stabilize, modify as needed, test and document the disclosed interfaces. This is not a trivial task. Interfaces that were designed to be used by only a certain small number of other pieces of code are not designed, tested, or documented to the level that Microsoft customarily provides for published interfaces. Interfaces must be stabilized, in that they must be fixed at a configuration that can be maintained. The interfaces will need to be modified to add error correction or other functions to handle unexpected behavior. The interfaces must be tested to work with a great many other applications and system configurations. Finally, the interfaces must be documented to accurately describe what the interfaces do and how to use them. If any of these steps are not performed, or not performed well, then third-party products might find the interfaces to be unreliable and therefore unusable.

302. In general, there is a trade-off between immediate publication of interfaces and delayed publication of interfaces with a higher degree ofcertainty that the interfaces will be well-tested and documented. The United States believes that the appropriate balance is to publish the interfaces with Windows XP Service Pack 1. One of the rationales for choosing Service Pack 1 is that a majority of corporate users, and even some consumers, prefer to wait to purchase until the first Service Pack of a new operating system is released. This is because the first Service Pack fixes many of the “bugs” or unintended behavior of a new operating system. In addition, many more applications are updated or modified to be compatible with a new operating system after its initial release. For corporate users, there is often a significant lag time of at least a year between when they begin testing and working with a new operating system and when it is deployed or “rolled out” to corporate users. All of these factors contributed to the decision to focus on Service Pack 1 as striking the correct balance for timing of the interface disclosure.

303. Commentors raise concerns that the delay allows Microsoft time to modify the interfaces and put “key interfaces” into the operating system. Part of this concern stems from a misreading of the Windows Operating System Product and Microsoft Middleware definitions. This confusion is addressed in discussion of those definitions. See Section III(H) above. Because Microsoft Middleware must be distributed separately, by definition there will be a set of interfaces between the Microsoft Middleware code and the Windows Operating System Product—the interfaces are between the bits of code that are distributed separately and what comes in the box labeled Windows. It is possible that Microsoft could move code around between the operating system and the Microsoft Middleware. But it is important to keep in mind that one of the main reasons the code is distributed separately is to provide more frequent updates of the Microsoft Middleware than the operating system, and to distribute the Microsoft Middleware to the large installed base of existing Windows users. To start hiding interfaces would involve a large backward compatibility problem, involving changes to the operating system as well as Microsoft Middleware code.

304. Finally, it is worthwhile to examine the timing of the expected first disclosure under the Litigating States' proposed remedy. The Litigating States' proposed remedy does not have any delay before the first disclosures, which means they could occur potentially as soon as a Litigating State's judgment was entered, giving Microsoft no time to harden, test, and document the APIs. The Litigating States' remedy hearing is expected to take a minimum of 12 weeks from the beginning of trial on March 11, 2002 through closing arguments. Even assuming the Court rules within 30 days, the decree would not be entered until July 2002. Microsoft undoubtedly would argue for a stay pending appeal and possibly appeal all the way to the Supreme Court. In light of such unavoidable litigation risks and delays, the United States believes the certainty of disclosure occurring between August and November 2002 is acceptable and indeed preferable.

b. Triggered by New Version of Microsoft Middleware: Last Major Beta Test Release

305. The meaning of “new major version” is covered above in the discussion of Microsoft Middleware. Section III.D calls for disclosures to occur no later than the last major beta test release of the new major version of the Microsoft Middleware. Based on data available to the United States, the last major beta test release for various Microsoft Middleware Products has occurred anywhere from two to seven months prior to the commercial release of the product, with the majority being three to four months prior. While some commentors are unfamiliar with the term,^[299] the phrase “last major beta test” has a specific meaning to Microsoft in terms of its testing and release schedule.

306. Commentors argue that this is insufficient notice for new APIs, and some argue that disclosure should be provided as soon as Microsoft developers receive the information.^[300] As a practical matter, such early disclosure is not feasible. The time when a Microsoft developer first receives information about a new API may be considerably before the API is finalized, tested and documented. Such information may be in the form of an informal e-mail or a hallway conversation. In fact, the Microsoft developer may have to make numerous changes to her own product as the API is changed. Alternatively, the Microsoft developer may be part of the testing cycle and may be required to work extensively with the Windows Operating System Product developer to write the interface. To release APIs before they are finalized will not be efficient. The United States believes that requiring the API to be fully published and documented at the last beta test release provides a reasonable trade-off between timely disclosure to ISVs and the need for Microsoft to finish the development of the APIs.

c. Triggered by New Version of Windows Operating System Product: Timely Manner (RPFJ § VI.R)

307. A number of commentors question Section VI.R's definition of “Timely Manner,” the term that defines when Microsoft must meet its disclosure obligations under Section III.D. See RPFJ § VI.R. In the RPFJ, “Timely Manner” is defined as “the time that Microsoft first releases a beta test version of a Windows Operating System Product that is distributed to 150,000 or more beta testers.” Some comments address the numerical threshold of “150,000 . . . beta testers.” Other comments address timing—Microsoft's ability to control when it reaches this threshold.

308. Several commentors contend that 150,000 beta testers is too high a threshold to trigger Section III.D's disclosure requirement, arguing that for past Windows Operating System Products, Microsoft may have distributed 150,000 beta copies but probably did not ever distribute them to 150,000 individual beta testers. These commentors therefore are concerned that the threshold will never be reached, resulting in no required disclosure before a new Windows Operating System Product is released.^[301]

309. The parties' intention in drafting this definition was not to distinguish between beta copies and beta testers with respect to the 150,000 requirement. The parties originally chose the 150,000 beta tester distribution level based on the approximate current MSDN subscription base. In response to the foregoing concerns about the definition of Timely Manner, however, the United States has proposed, and Microsoft and the Settling States have agreed, to modify the definition in Section VI.R of the SRPFJ to read:

“Timely Manner” means at the time Microsoft first releases a beta test version of a Windows Operating System Product that is made available via an MSDN subscription offering or of which 150,000 or more beta copies are distributed.

This modification clarifies the parties' intention that Timely Manner should be triggered by the distribution of 150,000 or more beta copies, regardless of whether those copies are distributed to individuals who are considered “beta testers.” Moreover, the inclusion of distribution via an MSDN subscriptionoffering as a trigger for this definition ensures that, even if the level of MSDN subscribers decreases substantially, it will still trigger Microsoft's disclosure obligations under Section III.D. Therefore, although this modification clarifies, and in fact may slightly broaden, Microsoft's disclosure obligations, it does not substantively differ from the RPFJ's definition of Timely Manner.

310. A number of commentors contend that Microsoft may in the future choose to distribute to fewer beta testers and thereby evade its disclosure obligations.^[302] Microsoft, however, continues to have a strong incentive to beta-test extensively any forthcoming Windows Operating System Product to ensure favorable consumer reaction, and the United States believes it is not realistic to suggest that Microsoft will diminish its beta-testing to avoid the RPFJ's disclosure requirements. If Microsoft's beta-testing practices change materially after imposition of the RPFJ, the United States would consider whether the change warrants a possible contempt action.

311. Several commentors express concern that triggering disclosure under Section III.D pursuant to the Timely Manner definition will permit Microsoft's own applications and middleware developers to continue receiving access to APIs and related Documentation before third-party developers receive access, thereby giving Microsoft's developers a head start in writing new applications and middleware.^[303] Some note that the slow release of Windows 95 APIs to Netscape is precisely how the district court found that Microsoft retaliated against Netscape for refusing Microsoft's market division proposal in 1995.^[304] In the extreme, at least one commentor contends that Microsoft could delay disclosure until after the deadline for third-party developers to demonstrate to Microsoft that their own products are compatible with the operating system and so qualify for a logo or other certification of compatibility.^[305]

312. Several factors should mitigate these concerns. Microsoft simply cannot delay the disclosure of information to an ISV until well after the release of a new Windows Operating System Product, as it did against Netscape in 1995 (Findings of Fact,¶ 91), because disclosure in a “Timely Manner” would have to occur when the Windows Operating System Product is released. And, as discussed above, Microsoft cannot put third-party developers at a substantial disadvantage without impairing the attractiveness of its new Operating System Product to consumers by reducing the range of available applications and middleware. Microsoft certainly has no incentive to send a new operating system into a market in which there are no applications available that are certified as compatible with it. On the other hand, premature disclosure of APIs—before Microsoft has had adequate opportunity to test and finalize an API—actually could hurt ISVs that wrongly rely on an interface that ultimately is not implemented.

B. Disclosure Of Communications Protocols (RPFJ § III.E)

313. Section III.E requires Microsoft on a continuing basis to make available to third parties, through licensing on reasonable and non-discriminatory terms, the Communications Protocols that are implemented natively, without additional software, in a Windows Operating System Product and are used by a Microsoft server operating system product to interoperate or communicate with the Windows Operating System Product, without the addition of other software to the client computer. In general, the comments raise questions about which software products or features are covered by this provision, what protocols are covered, the meaning of “interoperate,” and timing issues.

1. Product Issues

314. Several comments raise concerns about which software products on the client or server are covered. These comments suggest that the terms used in Section III.E are undefined and insufficient, and that the licensing should apply to a broader range of products on both the client and server.

a. Windows Operating System Product

315. Many comments argue that the term “Windows Operating System Product” does not encompass Microsoft Middleware Products such as Internet Explorer, and thus there is no required licensing of Communications Protocols between IE and Microsoft server operating system products.^[306] This is incorrect. Section III.E encompasses Communications Protocols used natively by any portion of a Windows Operating System Product, including any software that can also be considered Microsoft Middleware or a Microsoft Middleware Product. As explained in more detail elsewhere, see Section III(H) above, software code can be both Microsoft Middleware and part of a Windows Operating System Product.

316. Moreover, Windows Operating System Products such as Windows XP also contain functionality often associated with Microsoft server operating system products, such as Internet Information Services (IIS). As long as these functionalities are included natively in a Windows Operating System Product, any Communications Protocols used by these functionalities to communicate to a Microsoft server operating system product must be licensed. Some of these Communications Protocols will capture peer-to-peer communications, a concern raised by one commentor.^[307]

317. Another commentor argues that licensing should be provided for products that are not part of a Windows Operating System Product, particularly Microsoft Office.^[308] Such licensing is outside the scope of this case and the Court of Appeals' ruling. The ability of Office, which is not part of the desktop PC monopoly, to communicate with Microsoft server products, which are also not part of the client PC monopoly, is not an appropriate subject for injunctive relief, given that Microsoft's liability was based solely on maintenance of the desktop PC monopoly.

d. Microsoft Server Operating System Product

318. Many comments observe that the phrase “Microsoft server operating system product” is undefined, and therefore might be narrowly interpreted to exclude many Microsoft server products.^[309] The RPFJ's phrase “Microsoft server operating system product” was a change from the November 2, 2001 Proposed Final Judgment (“November 2 PFJ”), which read “Windows 2000 Server or products marketed as its successors installed on a server computer.” The intent and effect of this change was to broaden the coverage of this provision. The previous language referred only to a specific Microsoft product, Windows 2000 Server,^[310] and its successors. And although it was intended to encompass all software functionality that was shipped within the Windows 2000 Server product, including such software as IIS and Active Directory, arguably itmight not have extended to other products in the Windows 2000 Server product family, such as Windows 2000 Datacenter Server or Windows 2000 Advanced Server. The November 2 language also appeared not to cover any new server products that Microsoft may develop that were not successors to Windows 2000 Server.

319. By contrast, the RPFJ covers every Microsoft product that is now or in the future could be a server operating system product. It still includes Windows 2000 Server, but now also indisputably includes Windows 2000 Datacenter Server and Windows 2000 Advanced Server. Moreover, the decree now includes the .Net Servers,^[311] a much broader class of server products. By using the terms in their common and normal sense, rather than tying them to specific products, the phrase intentionally was given a broader meaning.

320. Furthermore, “Microsoft server operating system product” still includes all software code that is identified as being incorporated within the product and/or is distributed with the product, whether or not its installation is optional or is subject to supplemental license agreements. This includes, for instance, functionality such as Internet Information Services (a “web server”) and Active Directory (a “directory server”).

e. Non-Microsoft Client Operating Systems

321. Some comments argue that Section III.E should also cover licensing of communications protocols for use with non-Microsoft client operating systems, for example in enabling interoperability between a Microsoft server and a Linux desktop operating system.^[312] Interoperability and communications between a Microsoft server and non-Microsoft client platforms, however, was an issue outside the scope of the litigated case. There has been no proof in this case that Microsoft has a monopoly in server operating system products, or that communications difficulties between non-Microsoft platforms and Microsoft servers somehow played a role in the maintenance of Microsoft's desktop monopoly. Thus, the RPFJ properly does not reach questions of interoperability between Microsoft servers and non-Microsoft platforms.

322. Nor is it appropriate for the remedy to focus on competing operating systems vendors, given that the focus of the case was on middleware threats, not direct threats from operating system competitors. The licensing in Section III.E is limited to being “for the sole purpose of interoperating with a Windows Operating System Product” because the purpose is to enable server-based middleware threats to interoperate with Windows Operating System Products. Several commentors argue that the licensing should be unrestricted and not for any particular purpose, but this would not be consistent with the theory of the case and the rationale behind client-server disclosures.^[313]

323. Rather, the intent of Section III.E is to ensure that ISVs and others will have full access to the communications protocols that a Microsoft Windows Operating System Products uses to interoperate or communicate natively with its own server operating system products. Much Non-Microsoft Middleware, including the Netscape browser and Java Virtual Machines, depend on content, data, and applications residing on servers and passing over networks such as the Internet or corporate networks. Under Section III.E, this Non-Microsoft Middleware will have the opportunity to interoperate with a Microsoft server operating system product in the same way as Microsoft Middleware.

f. Server-to-Server Communications

324. Some commentors argue that Section III.E should be extended to cover communications solely between one server and another server.^[314] Pure server-to-server interoperability issues, however, are well beyond the scope of the case. As noted above, there is no record proof in this case that Microsoft has monopoly power in server markets. Inter-computer communications that do not implicate Microsoft's desktop operating system monopoly are properly outside the scope of the RPFJ.

g. Other Devices

325. Some commentors argue that communications between a Windows Operating System Product and other devices, such as handheld devices, should be included in Section III.E.^[315] For all of the reasons discussed above concerning server-to-server communications, and communications to non-Microsoft client operating systems, communications to devices such as handhelds are outside the scope of the case.

2. Communications Protocols, Disclosure And Licensing

326. Several comments raise issues regarding “Communications Protocols” as used in Section III.E, as well as related issues concerning the substance of the licensing. These comments include questions about the definition of Communications Protocols, the “natively” requirement, the meaning of “interoperate,” and whether Microsoft can evade the provision by moving Communications Protocols to other products. These issues concern the substance of what will be licensed for use by third parties, not the server and client software products between which the Communications Protocols operate.

a. Definition of “Communications Protocols” (RPFJ § VI.B)

327. Some comments criticize the definition of “Communications Protocols,” opining that it (1) does not encompass certain types of information transmission, (2) addresses formats but not semantics, and (3) fails to address more than predefined tasks, or does not adequately define sub-elements, such as “formats.”^[316] Several comments appear to focus on the previous definition in the November 2 PFJ, or perhaps even in the June 2000 IFJ, and not the RPFJ definition.^[317]

328. The RPFJ broadly defines Communications Protocols as the set of rules for information exchange to accomplish predefined tasks between a Windows Operating System Product and a Microsoft server operating system product connected through any type of network, including but not limited to, a local area network, wide area network, or the Internet. The definition includes both the rules for information exchange and transmittal (“format, timing, sequencing and error control”) as well as the meaning of the information contained within the protocol (“semantics”). By definition, Communications Protocols must be predefined tasks, because if the tasks were not predefined, the client and server would not know how to perform them or communicate about them. Every protocol at any layer of the communications stack that is implemented natively in a Windows Operating System Product and that is used to interoperate with a Microsoft server operating system product must be made available for license by thirdparties. This definition is sufficiently broad to capture all native communications from a Windows Operating System Product to a Microsoft server operating system product.

b. The Meaning of “Interoperate”

329. Several comments note that the word “interoperate” in Section III.E. is not defined and argue that this will allow Microsoft to evade this provision.^[318] Specifically, one commentor points to Microsoft's definition of “interoperate” proffered in the pending European Union investigation of Microsoft and contend that that definition and associated declarations are different and arguably narrower than the intended definition in Section III.E.^[319]

330. The United States is aware of Microsoft's submissions to the European Union concerning the definition of “interoperate” and has discussed this issue at length with Microsoft with respect to this provision. Microsoft and the United States believe they have a meeting of the minds regarding the meaning of “interoperate” in Section III.E and its effect in that provision. If a communications protocol is implemented in a Windows Operating System Product installed on a client computer and used to “interoperate, or communicate, natively” with a Microsoft server operating system product, then it must be disclosed. Nonetheless, to alleviate concerns stemming from Microsoft's submissions to the European Union, the United States and Microsoft have agreed to a limited modification in Section III.E.

331. The United States believes that, as used in the RPFJ, Section III.E clearly reflects the parties' intention that this provision will allow for the possibility of seamless two-way interoperability between Windows Operating System Products and non-Microsoft servers. Although the United States believes the meaning of “interoperate” is clear, in response to the public comments, the United States has proposed, and Microsoft and the Settling States have agreed, to supplement the term “interoperate” with “or communicate,” so that Section III.E in the SRPFJ now reads:

Starting nine months after the submission of this proposed Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of inter operating or communicating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (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. (New language underlined.)

By adding “or communicate” after “interoperate,” the parties have added further clarity to this provision. This revision clarifies the parties' intent in drafting Section III.E, thus removing any potential for confusion or ambiguity regarding the scope of this provision as it relates to the meaning of “interoperate.”

332. Section III.E will protect opportunities for the development and use of Non-Microsoft Middleware by ensuring that competing, non-Microsoft server products on which such Middleware can be hosted and served will have the same access to and opportunity to interoperate with Windows Operating System Products as do Microsoft's server operating system products. This is not to say that all competing servers will behave exactly identically to Microsoft servers, because the competing implementations will differ. However, as to the Communications Protocols themselves, the competing servers will have the ability via license to appear identical to a Microsoft server operating system product.

c. License for Use

333. Several commentors point out that there is no discussion of disclosure in Section III.E and that lack of disclosure may defeat the purpose of the license.^[320] Because the Communications Protocols must be licensed “for use” by third parties, the licensing necessarily must be accompanied by sufficient disclosure to allow licensees fully to utilize all the functionality of each Communications Protocol. Simply put, Microsoft is not permitted to design interoperability between its server operating system products and its Windows Operating System Products in a way that cannot be replicated under license by third parties whose products replace functionality on either the server or client side of the communication.^[321]

d. The Meaning of “Natively”

334. Section III.E requires Microsoft to license the Communications Protocols “used to interoperate natively (i.e., without the addition of software code to the client operating system product) with a Microsoft server operating system product.” One commentor raises concerns regarding the change in the “natively” requirement from the November 2 PFJ to the November 6 RPFJ, suggesting that the RPFJ no longer covers Communications Protocols implemented on a server.^[322] This is incorrect. The parenthetical expression that begins with “i.e.” is an explanation of the word “natively,” and nothing else.

335. The November 2 PFJ stated “used to interoperate natively (i.e., without the addition of software code to the client or server operating system products).” The parenthetical expression explained that the word “natively” meant the software that is included with the Windows Operating System Product and the Microsoft server operating system product without the addition of any other products or software code.

336. In the November 6 RPFJ, the phrase was changed expressly to remove the requirement for “native” operation on the server. This was done by removing the words “or server.” The RPFJ reads “i.e., without the addition of software code to the client operating system product.” This change means that the native requirement is only on the Windows Operating System Product on the client. In other words, “natively” now simply means all software code implemented in a Windows Operating System Product on the client. For the server side, it no longer matters if software code is added from some other product. When combined with the change to the broader “Microsoft serveroperating system product,” discussed above, the net result is a significant expansion of the disclosure and licensing obligation from the November 2 PFJ to the RPFJ.

337. Currently, the only way Microsoft can avoid licensing under this provision is to implement new protocols (i.e., not in use on November 6, 2001), and then not implement those new protocols in any Windows Operating System Product. These new protocols would have to be distributed with other products or reach the desktop in some fashion other than by inclusion in a Windows Operating System Product. Because these Communications Protocols would in effect be completely separate from the desktop operating system monopoly, they are correctly not encompassed within Section III.E, despite several comments to the contrary.^[323]

e. Licensing On “Reasonable And Non-Discriminatory Terms”

338. Section III.E allows Microsoft to license its Communications Protocols on reasonable and non-discriminatory terms consistent with Section III.I. Several commentors argue that Microsoft should not be able to charge a royalty for its Communications Protocols.^[324] Allowing Microsoft to charge a royalty is appropriate. Historically, Microsoft has been less willing to disclose Communications Protocols than APIs, and when it does license Communications Protocols, it charges a royalty or otherwise receives Consideration. It has designed and developed its Communications Protocols with the expectation that they would not be given away.

3. Timing Issues

339. Comments raise two basic issues with respect to the effective date for implementation of the requirements of Section III.E. A few comments misread Section III.E as excluding Windows 2000 and Windows XP, on the erroneous assumption that only server operating system products or communications protocols that come into existence after November 6, 2001 are covered.^[325] To the contrary, Section III.E covers in part “any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (i) implemented in a Windows Operating System Product installed on a client computer. . . .” In other words, Communications Protocols implemented in any Windows Operating System Product as of November 6, 2001 are expressly covered—including Windows 2000, Windows XP Home, and Windows XP Professional. This language simply ensures that if Microsoft for whatever reason changed the Communications Protocols between the time the RPFJ was submitted to the Court and the effective date of this Section III.E nine months later, the changed Communications Protocols would not be outside the scope of the provision. Thus, all Communications Protocols in existence on November 6, 2001 must still be covered on August 6, 2002, the latest date on which they must be available for use by third parties, regardless of whether Microsoft has changed them in the interim.

340. Several comments also raise concerns about the initial nine-month delay before the Communications Protocols are licensed.^[326] The purpose of this delay is to allow Microsoft to identify the Communications Protocols and define a licensing program so that they can be made available for use by third parties. Unlike its APIs for its Windows Operating System Products, for which Microsoft has always had an extensive disclosure program via the MSDN, Microsoft historically has licensed or disclosed relatively few of its Communications Protocols. And unlike the APIs that must be disclosed if they are used by Microsoft Middleware, which is a relatively finite set of products, Communications Protocols must effectively be available for license by third parties if they are implemented natively in a Windows Operating System Product and they are used to interoperate or communicate with any Microsoft server operating system product, including cases where extra software code is added to the server operating system product. This opens up what is potentially a very broad universe of new disclosure and licensing obligations for Microsoft. Microsoft needs time to set up programs to meet these obligations.

341. One commentor points out that the time to negotiate the required license may provide even further delays.^[327] Although this might be true in some cases, the effect is lessened here because of the requirement that Microsoft license on reasonable and non-discriminatory terms. The license provision is reasonable because Microsoft's protocols are protected intellectual property.

342. Still others argue that the nine-month delay cuts heavily into the five-year term of the RPFJ.^[328] This criticism is largely incorrect in that the nine months began running as of November 6, 2001, meaning that the disclosure and licensing must occur by not later than August 6, 2002. Thus, licensing is in fact likely to begin shortly after the decree's 5-year term begins to run upon entry by the Court.

343. Lastly, at least one commentor points out that there is no timing requirement after the initial licensing begins, and argues that Microsoft is under no obligation to offer Communications Protocols for license in a prompt manner.^[329] To the contrary, the lack of a specific timing trigger requires Microsoft to make continuing and rolling offers to license as new Communications Protocols are implemented in Windows Operating System Products. In many other provisions of the RPFJ there are a variety of specialized triggers; the absence of one here is not accidental.

C. Compulsory Licensing (RPFJ § III.I)

344. Section III.I requires Microsoft to offer necessary licenses for the intellectual property that Microsoft is required to disclose or make available under the RPFJ.^[330] The goal of this Section is to ensure that Microsoft cannot use its intellectual property rights to undermine the competitive value of its obligations in Sections III.D and III.E, while at the same time to permit Microsoft to take legitimate steps to prevent unauthorized use of its intellectual property.

345. Several comments address Section III.I. One group of commentors suggests that permitting Microsoft to charge a “reasonable” royalty for licenses to its intellectual property is inappropriate.^[331] Another group of commentors takes issue with Section III.I.3's restrictions on sublicenses.^[332] Many commentors raise concerns relating to Section III.I.5 and Microsoft's ability to require a cross-license of certain intellectual property rights pursuant to that subsection.^[333] Severalcommentors also argue, to varying degrees, that the scope of Microsoft's intellectual property rights should be limited.^[334]

1. Reasonable And Non-Discriminatory Royalty

346. Subsection III.I.1 requires that any licenses granted pursuant to this Section be made on reasonable and non-discriminatory terms, and then permits Microsoft to charge a reasonable royalty in connection with licenses it grants pursuant to Section III.I. One commentor contends that Microsoft should not be permitted to charge any royalty at all, and that permitting it to do so in effect rewards Microsoft for maintaining illegally its operating system monopoly.^[335]

347. One commentor asserts that royalty-bearing licenses are anticompetitive in the context of this remedy because such licenses give Microsoft the opportunity to use a “royalty charge” to control crucial technical information. This commentor^[336] notes that in June 2000, when litigating the IFJ, the United States rejected Microsoft's contention that it should be permitted to charge a reasonable royalty for the APIs, Communications Interfaces, and Technical Information (as such terms were defined in the IFJ).^[337] See Summary Response to Microsoft's Comments on the Proposed Final Judgment at 14 (June 5, 2000). Under the RPFJ, disclosure of APIs in the manner that Microsoft typically does it (e.g., through MSDN and not via a license) would not implicate Section III.I and would occur at no cost.^[338]

348. The United States does not believe that the scaled-back liability that the Court of Appeals upheld justifies requiring Microsoft to give away its valuable intellectual property. To the extent that Section III.I.1 of the RPFJ permits Microsoft to charge a reasonable royalty for intellectual property rights provided under other provisions of the RPFJ, the United States believes that the terms of the RPFJ strike the appropriate balance between mandating that Microsoft provide certain licenses and not frustrate the interoperability provisions of the RPFJ, while still permitting Microsoft to charge a reasonable and nondiscriminatory royalty for access to its intellectual property.

2. Restriction On Sublicenses

349. Several commentors suggest that the restrictions on sublicenses contained in Section III.I.3 are inappropriate.^[339] These comments suggest that the restriction on sublicenses may have the effect of inhibiting the ability of ISVs, IHVs, IAPs, ICPs, or OEMs to partner with other entities. In particular, two commentors suggest that the restriction on sublicenses could in practice preclude a licensee of Microsoft's technology under the RPFJ from reselling or distributing the products that it develops using Microsoft's licensed technology.^[340] Another commentor suggests that not allowing sublicenses under certain circumstances (e.g., where the licensee is involved in an acquisition) is a form of discrimination.^[341]

350. These comments misconstrue the purpose and effect of the restriction on sublicenses contained in Section III.I.3. First, entities to which a licensee of Microsoft's technology under the RPFJ wishes to sell or distribute products using that licensed technology would not need a sublicense to Microsoft's intellectual property. Similarly, the United States does not believe that a sublicense would be required in the circumstances of an acquisition and, even if one were, that Microsoft would be likely to preclude sublicensing in such circumstances.

351. In general, the United States recognizes that Microsoft has a legitimate interest in limiting its intellectual property licensing to those licenses that are properly related to the terms of the RPFJ. Subsection III.I.3 is designed to address this issue by permitting Microsoft to preclude the assignment, transfer or sublicensing of rights granted by Microsoft pursuant to Section III.I, provided that Microsoft's preclusion is reasonable and non-discriminatory as required by subsection III.I.1. This provision does not permit Microsoft to restrict the right to sublicense where doing so would be unreasonable, discriminatory, or otherwise would be inconsistent with the terms of the RPFJ. See Section III.I.4.

3. Cross-Licenses

352. A number of commentors suggest that Section III.I.5 of the RPFJ, which permitted Microsoft to require cross-licenses from persons or entities who wished to take advantage of the disclosure provisions of the RPFJ if such licenses were necessary for Microsoft to provide the disclosures, was inappropriate.^[342] The United States and Microsoft have agreed to delete this subsection from the RPFJ. See U.S. Memorandum at 10-11; SRPFJ § III.I.5. The purpose of Section III.I.5 was to enable Microsoft to fully comply with the terms of the RPFJ without creating infringement liability based on actions taken in order to comply with those terms.

4. Scope of Intellectual Property Rights

353. Several commentors make suggestions concerning Section III.I that generally relate to the scope of Microsoft's intellectual property rights. One commentor suggests that Microsoft should be required “to clearly announce which of its many software patents protect the Windows APIs . . ..;”^[343] Another commentor objects to the portion of Section III.I.2 that clarifies the scope of any license granted under Section III.I and expressly provides that “the scope of any such license . . . shall not confer any rights to any Microsoft intellectual property rights infringed by” the licensee's technology.^[344] This commentor suggests that Microsoft should be precluded from bringing infringement suits against an entity thatlicenses Microsoft intellectual property under the RPFJ, even when that licensee infringes other Microsoft intellectual property to which the entity does not have a license.^[345] Finally, one commentor expresses skepticism that Microsoft actually would license the intellectual property that is required for interoperation and suggests that Microsoft should be required to license all of its intellectual property rights.^[346]

354. The United States believes that preventing Microsoft from protecting its intellectual property is unwarranted and inappropriate. Allowing competitors to expropriate Microsoft's intellectual property in order to compete with Microsoft would deter Microsoft from investing in innovation and simultaneously deter rival developers from coming up with different, new, potentially better technologies to build into their own products. Nothing in the solutions suggested by these commentors would benefit consumers.

5. Comparison to Litigating States' Proposal

355. Provision 15 of the Litigating States' Proposal is a corollary to—and substantially the same as—Section III.I of the SRPFJ. The major differences between them are (a) Provision 15 provides for a royalty-free license, while the RPFJ permits Microsoft to charge a reasonable and non-discriminatory royalty; and (b) Provision 15(b) provides that licenses granted pursuant to it “shall not be conditional on the use of any Microsoft software, API, Communications Interface, Technical Information or service.”^[347]

356. As set forth above, the United States believes that it would be inappropriate and unwarranted to require Microsoft to license its intellectual property at no cost. In addition, the United States and Microsoft have agreed to delete the cross-license provision of Section III.I. Finally, the Litigating States' Provision 15(b) appears to be an attempt to preclude Microsoft from using the granting of licenses pursuant to the November 2, 2001 Proposed Final Judgment as leverage to induce certain types of entities to use other Microsoft software. Section III.G of the RPFJ similarly prohibits this type of conduct by Microsoft.

D. Security Carve-Outs (RPFJ § III.J)

357. Many commentors argue that the security provisions in RPFJ Section III.J are inappropriate or overbroad. Section III.J has two subsections. The first defines situations in which Microsoft has no obligation under the RPFJ to make disclosures that are otherwise required by the RPFJ. The second permits Microsoft to withhold security-related information from certain persons or entities.

1. Limitation on Obligations to Document, Disclose or License

358. Section III.J.1 identifies two situations in which Microsoft is not obligated to document, disclose or license certain materials to third parties. The first situation is where the disclosure would compromise the security of a particular installation or group of installations of anti-piracy, anti-virus, software licensing, digital rights management, encryption, or authentication systems. These situations include but are not limited to the disclosure of keys, authorization tokens or enforcement criteria.

359. Many commentors complain that this provision is too broad and will allow Microsoft to withhold security-related APIs and Communications Protocols.^[348] Commentors argue that such APIs and Communications Protocols are critically important to many middleware applications and that this provision amounts to exempting from coverage by the RPFJ software and services that are the future of computing. Other commentors point out that the CIS language is significantly more defined and specific than the RPFJ. Still other commentors point to specific protocols that the CIS says will be provided, such as Secure Audio Path and Kerberos, and argue that notwithstanding the CIS, Section III.J.1 actually exempts those protocols. Still others point out that “layers of protocols” is significantly broader than the user-specific data described in the CIS.

360. Secure software systems can be designed in many different ways, and at any given time, is often some critical information can compromise that security. For instance, secure software often uses the term “keys” to refer to specific data that is used to authenticate or authorize a user to perform certain functions. Often the keys, or other user-specific data, must be kept secure because, if unauthorized people have them, they can be used to compromise the security of the system. These software keys can be thought of as being similar in some ways to regular keys: having the key to the front door compromises the house's security, and keeping control of the keys is critical to keeping the house secure.

361. Sometimes software systems are built not around keys but around keeping actual parts of the system hidden or unknown. Continuing with the house analogy, this is similar to keeping the existence of the door a secret, but once you know where the door is and what it does, you do not need a key. Sometimes such systems are referred to, unfavorably, as employing “security through obscurity.” Many software systems employ combinations of these security techniques.

362. The intent of Section III.J.1 is to allow Microsoft to keep secret those pieces of security-related systems the disclosure of which would compromise particular installations or groups of installations. The phrase “particular installations” is designed to indicate end-user installations or a specific, narrowly-prescribed subset of installations. It does not mean, for instance, all the installations that use Windows Media Player, nor does it mean all the installations that use Windows Media Player in conjunction with the Secure Audio Path functionality. Moreover, the disclosure actually must compromise the security of the particular installation. The disclosure cannot be withheld simply because Microsoft prefers that others not have it, or because it is valuable. Thus, for instance, if Microsoft previously has withheld an algorithm or format used in its Communications Protocols for business reasons, but the security of the system actually is dependent on other features such as keys, then Microsoft has no authority to withhold the disclosure or format.

363. Some commentors suggest that the CIS differs from the language of the RPFJ. The United States believes that the CIS reflects the parties' agreement as to the meaning of the RPFJ, including Section III.J.1. Moreover, the United States agrees with the many commentors who note that security-related features will be critically important to Non-Microsoft Middleware, and that overbroad withholding of security-related information could limit drastically the ability of such products to pose threats to the operating system monopoly. Section III.J.1, however, is not overly broad.

364. The second situation under Section III.J.1 in which Microsoft is notobligated to document, disclose or license is when Microsoft is so directed by a governmental agency of competent jurisdiction. One commentor argues that this provision appears to be a “big brother type deal between government and Microsoft to suppress information from the public.”^[349] Another commentor notes that this restriction is written more broadly than the CIS's “lawful orders” language.^[350] This section is appropriate and important for public security purposes, and limited to cases in which a government agency of competent jurisdiction directs Microsoft not to document, disclose or license specified information.

2. Conditioning Licenses on Certain Requirements

365. Section III.J.2 allows Microsoft to condition the license of security-related APIs, Documentation or Communications Protocols on four requirements. These four requirements for the licensee are: (a) No history of software counterfeiting or piracy or willful violations of intellectual property rights; (b) a reasonable business need for the information for a planned or shipping product; (c) meets reasonable and objective standards for the authenticity and viability of its business; and (d) programs verified by a third party to ensure compliance with Microsoft specifications for use of the information.

366. Many commentors argue that the provisions of Section III.J.2 can be used by Microsoft to withhold unfairly information from competing companies, and in particular from open source developers.^[351] One commentor, in contrast, finds that Microsoft's legitimate security concerns, which the commentor argues are shared by all of its major business rivals, are addressed appropriately under Section III.J.2, and therefore the restrictions of Section III.J.1 are unnecessary.^[352]

367. As was explained in the CIS, the requirements of this subsection cannot be used as a pretext for denying disclosure and licensing, but instead are limited to the narrowest scope of what is reasonable and necessary. These requirements focus on screening out only individuals or firms that should not have access to or use the specified security-related information because they have a history of engaging in unlawful conduct related to computer software, do not have any legitimate basis for needing the information, or are using the information in a way that threatens the proper operation and integrity of the systems and mechanism to which they relate.

368. With regard to requirement (a) concerning software piracy, some commentors argue that it unjustly could exclude any company that ever has been sued for patent infringement and lost. The requirement was not intended to extend this far, because legitimate businesses do lose patent lawsuits on occasion. Rather, application of this requirement is to be guided by the phrase “history of software counterfeiting or piracy” and will not be interpreted to extend to otherwise reputable companies that are involved in intellectual property disputes.

369. Many commentors focus on requirements (b) and (c) and argue that they improperly will exclude the entire open source movement and require start-up companies to submit their business plans to Microsoft. First, it is appropriate to note that the “open source movement” is not composed of a single type of organization or software developer. Rather, large companies such as IBM are strong supporters of products such as Linux and of other open source solutions. Smaller companies such as Red Hat are also reputable firms focused on the open source movement. The United States expects that such firms will have little trouble satisfying requirements (b) and (c). That is not to say that all open source organizations, or individual developers, will be able to pass these requirements. The United States believes that Microsoft has a legitimate interest in protecting the security of its systems and that requirements (b) and (c), properly interpreted, are a reasonable balancing of Microsoft's interests and the needs of competition.

370. Finally, requirement (d) allows Microsoft to condition the granting of a license on the submission of any computer program using the licensed API, Documentation or Communications Protocol to third-party verification. Some commentors incorrectly have read this requirement to mandate the submission of the computer program to Microsoft. To the contrary, this requirement is structured specifically so that Microsoft will not be able to gain access to another's intellectual property. Rather, an independent third party will test and verify the computer program against specifications provided by Microsoft. These specifications must relate to the proper operation and integrity of the systems under test, and cannot relate to any other business-related factors. Finally, some commentors argue that it is inappropriate for this testing to be at the licensee's expense rather than at Microsoft's expense. The United States understands that with other third-party testing programs in the software industry, the cost usually is borne by the organization submitting the program. The United States sees no reason to deviate from that practice.

E. Disclosure of File Formats

371. Many commentors argue that Microsoft should be required to disclose file formats.^[353] Some of these commentors make the request generally, while others make reference to specific file formats such as those for Microsoft Office programs (e.g., Word, Excel, Outlook).^[354] A file format, generally speaking, is the structure of a file, showing how the file organizes and stores data. File formats can be either proprietary or open. File formats are sometimes associated with three-letter file extensions at the end of a file name; for instance, “file.wpd” is usually a file in Word Perfect format, while “file.doc” is usually a file in Microsoft Word format.

372. File formats are covered to a limited extent under Sections III.D and III.E, which deal with disclosure and licensing. Section III.D calls for the disclosure of APIs that Microsoft Middleware uses to call on a Windows Operating System Product, while Section III.E calls for the licensing of certain Communications Protocols implemented in a Windows Operating System Product and used to communicate natively with a Microsoft server operating system product. To the extent either the APIs or Communications Protocols encompass “file formats,” then those structures are covered.

373. However, the major comments concerning file formats request disclosure of the file formats of Microsoft products such as Office. Office does not meet the definition of Microsoft Middleware, and so it does not fall under Section III.D. Nor is Office implemented natively in a Windows Operating System Product, so it does not fall under Section III.E. Thus, the file formats for Office will not be disclosed or licensed pursuant to the RPFJ.

374. Commentors argue that the file formats for Office should be disclosedbecause Office is a significant part of the applications barrier to entry that protects the Windows monopoly. Disclosure of the file formats would allow other office productivity applications, such as word processors, to exchange files with Office. Allowing the exchange of files would allow consumers to change word processors, and potentially change operating systems, without concern that they could not exchange files with the dominant applications in Office.

375. The scope of the case as decided by the Court of Appeals does not extend to non-middleware or to Office or other applications that are not distributed with Windows. Whatever impact generally the disclosure of file formats might have on the applications barrier to entry that protects Windows, such disclosure was not among the conduct charged as illegal by the plaintiffs or upheld by the Court of Appeals, nor is it of the same type or class as Microsoft's attack on potentially threatening middleware. Thus, it would be inappropriate for file formats for Office to be part of the remedy.

VIII. Enforcement

376. Numerous comments criticize various aspects of the compliance and enforcement procedures set forth in Section IV of the RPFJ. Many of these comments take issue with the composition and duties of the Technical Committee (“TC”) (RPFJ § IV.B) and the supplemental dispute resolution provisions (RPFJ § IV.D), some suggesting that the enforcement scheme should be based on an entirely different, more draconian, model. In several cases, these comments misunderstand the purposes underlying the RPFJ's supplemental enforcement mechanisms. In others, they imply that the RPFJ somehow dilutes the United States' and the Court's traditional judgment construction and enforcement powers, or that Microsoft arguably has an undue amount of control over the process.^[355] These allegations are meritless.

377. The additional monitoring and dispute resolution mechanisms of the RPFJ are intended to enhance the likelihood of efficient resolution of compliance issues that may arise, without undue delay or the necessity of extensive prosecutorial or judicial involvement. They in no way prohibit or impede traditional judicial construction or enforcement of the RPFJ. With the limited exception of giving Microsoft a reasonable opportunity first to cure violations of Sections III.C, III.D, III.E, and III.H (see RPFJ § IV.A.4)—which is intended to encourage the voluntary remediation of alleged violations by Microsoft—the United States retains the full ability, in appropriate instances, immediately and directly to request that the Court bring to bear its full arsenal of enforcement and declaratory construction powers on any alleged violations or interpretative disputes.

A. The Enforcement Powers of Plaintiffs and the Court

378. Section IV.A grants the United States (and the Settling States collectively) all of the investigatory and enforcement powers customarily found in antitrust final judgments in cases brought by the United States in recent decades. See, e.g., ATT, 552 F. Supp. at 230-31 (“Visitorial Provisions”). The RPFJ grants Plaintiffs the power to inspect Microsoft documents and computer source code, to interview or depose Microsoft employees, and to require the production of written reports, in the form of interrogatory responses or otherwise. See RPFJ § IV.A.2. Plaintiffs may seek any appropriate orders relating to the enforcement of the RPFJ, including the ability to file petitions for orders to show cause why Microsoft should not be held in criminal or civil contempt, petitions for injunctive relief to restrain or prevent violations, motions for declaratory judgment to clarify or interpret particular provisions, and motions to modify the RPFJ. See RPFJ § IV.A.4.

379. Likewise, the Court retains full jurisdiction to issue orders necessary to construe, carry out, modify, and enforce the RPFJ, and to punish violations thereof. See RPFJ §§ IV.A.4, VII. The Court's inherent powers include the power to construe or modify the decree, to compel Microsoft's compliance or remedy noncompliance through civil contempt, and to punish willful non-compliance through criminal contempt. See McComb v. Jacksonville Paper Co., 336 U.S. 187, 191-95 (1949); 18 U.S.C. 401(3). Nothing in the RPFJ diminishes any of these rights and powers.

380. Some comments criticize the provision in Section IV.A.4 that allows Microsoft a reasonable opportunity to cure alleged violations of Sections III.C, D, E, and H before Plaintiffs may seek an enforcement order, as simply giving Microsoft a mechanism for delay.^[356] To the contrary, the limited opportunity to cure is intended to encourage rapid, consensual resolution of issues arising under some of the provisions governing Microsoft's relations with third parties, without the necessity of prosecutorial or judicial intervention. Section IV.A.4 expressly prohibits Microsoft from using its efforts to cure as a defense to enforcement actions designed to punish violations (such as willful violations subject to criminal contempt^[357] ), or systematic violations that may require additional prospective RPFJ modifications in order to prevent recurrences.

B. The Technical Committee

381. In addition to all traditional decree enforcement rights and powers, the RPFJ adds a number of additional mechanisms to assist in achieving and maintaining compliance short of formal litigation. These additional mechanisms provide unprecedented enhancement to the United States' traditional enforcement powers. The most important of these mechanisms is the Technical Committee (TC). The TC, which remains under the control of the United States, itself has broad information-gathering powers to monitor Microsoft's compliance, evaluate third-party complaints, and propose ways to cure violations. The TC's ongoing monitoring duties will help ensure that Microsoft remains compliant with its obligations under the RPFJ, and that if it fails to comply, violations promptly will be detected and brought to Plaintiffs' attention. The TC, however, is not a law enforcement body. Rather, traditional prosecutorial powers remain with the United States and plaintiff States, while traditional compulsory, remedial, and enforcement powers remain with the Court.

1. Technical Committee Powers

382. Because several comments criticize the powers of the TC asinadequate,^[358] a detailed explanation of the TC's powers is in order. The TC has a number of purposes.

383. First, the TC provides in-depth, ongoing monitoring of Microsoft's activities as they relate to compliance with the RPFJ. This will permit rapid detection and reporting of potential violations to the United States and the plaintiff States, after which Plaintiffs can, in the exercise of their prosecutorial discretion, bring such enforcement action as is appropriate to the situation. As part of this function, the TC has broad powers to obtain information from Microsoft. The TC may require Microsoft to make available records and documents, and to provide physical access to Microsoft facilities, systems and equipment. Microsoft must also make its personnel available for interviews on essentially the same terms as they are available to the United States and plaintiff States in their enforcement investigations and actions.^[359] The TC even has the right to unfettered access to Microsoft's software source code, subject only to standard confidentiality protections. See RPFJ § IV.A.8.

384. The TC has the authority to receive and evaluate complaints from third parties, from Microsoft's Compliance Officer, and from Plaintiffs. RPFJ §§ IV.A.8.d; D.4.a, b. The TC may keep the identity of complainants anonymous, and Microsoft will not have the right under the RPFJ to obtain the identity of the complainant. This should encourage information flow to the TC, even from those who might fear Microsoft retaliation. RPFJ § IV.D.4.e. Further, the TC has an obligation to report to Plaintiffs, both at regular intervals and immediately upon discovery of an apparent violation. RPFJ §§ IV.A.8.e, f. Finally, the TC has the right to report back to third parties who have made complaints or inquiries as to how they might be resolved with Microsoft, subject only to the TC's overall confidentiality obligations. See RPFJ §§ IV.8.f, 8.c, 9, 10.^[360]

385. Some comments criticize the restriction on direct use of the TC's reports and conclusions in enforcement actions.^[361] This direct use restriction has two purposes: First, by ensuring that Microsoft's and third parties' communications will not be used directly against Microsoft, the TC will benefit from heightened candor and information disclosure by Microsoft employees and others. Second, and equally important, the TC cannot be expected to develop evidence for use in adversary proceedings with the necessary level of rigor that law enforcement or legally trained personnel could muster. Those criticizing the restriction on direct use of the TC's output overlook the fact that Plaintiffs remain free to make full derivative use of all the TC's work in enforcement—such as pursuing leads to build solid enforcement actions based on admissible evidence. In this sense, the TC's work will prove invaluable.

386. A second purpose of the TC is to facilitate the resolution of potentially complex and technologically nuanced disputes between Microsoft and others over the practical workings of the RPFJ. The TC is not intended to have independent enforcement authority; that authority remains with Plaintiffs and the Court. See CIS at 55.^[362] Rather, the TC has a “dispute resolution” role, intended to facilitate the rapid, consensual resolution of issues where possible. As noted above, the TC complements, but does not supplant, Plaintiffs' and the Court's traditional methods and powers of decree enforcement. It is thus intended to provide an additional mechanism for the efficient voluntary resolution of what otherwise could be time-consuming, costly, and frustrating disputes to all concerned. Viewed in this light, rather than as being a surrogate prosecutor or judge, both the TC's procedures and substantive powers make eminent sense.

387. Some comments question why the TC is not given an explicit mandate to also have business or legal expertise to facilitate the review of Microsoft's non-technical business or legal decisions.^[363] The RPFJ sets forth a baseline of technical expertise because it is essential that the TC have “experts in software design and programming,” to do its job. RPFJ § IV.B.2. Nothing in the RPFJ, however, limits the expertise of TC members, staff, and consultants to only these areas. In short, the TC can and should have available to it expertise broader than purely technical matters and will be expected to address and report on business and other issues that come to its attention in connection with its monitoring of Microsoft's compliance with the RPFJ. Furthermore, the United States, the plaintiff States, and the Court routinely confront complex economic and business strategy issues, and clearly have the capability to address such issues as they affect enforcement matters.

2. Composition and Control of the Technical Committee

388. Some comments take issue with the manner in which the TC will be constituted, object to Microsoft playing any role in selecting its members, and generally imply that the TC will lack independence.^[364] Many of these comments fail to appreciate that Plaintiffs, not Microsoft, control the TC.

389. The TC is composed of three members who are to be “experts in software design and programming.” RPFJ § IV.B.2. Plaintiffs and Microsoft will each nominate one member, who must meet strict conflict-of-interest standards, to ensure that they perform their duties in a “fair and unbiased manner” (RPFJ § IV.B.2), and have the right to object to the other's proposed appointee. Any unresolvable disputes about TC membership are decided by the Court, which retains the ultimate ability to appoint the members. After the first two members are appointed, they will propose a third member; again, the Court will decide disputes and approve or reject this member. See RPFJ § IV.B.3. Having all parties play a role in selecting the TC ensures that it will not have an overall bias for or against one party. Furthermore, there remain safeguards against bias even after the TC is chosen. If, for example, the TC member nominated by Microsoft fails tobehave in an unbiased manner or otherwise does not act in accord with the purposes of the RPFJ, the United States has the right to insist that the member be replaced (RPFJ § IV.B.5); Microsoft, however, has no corresponding right.

390. Further, as noted critically by a few comments,^[365] TC members are subject to employment restrictions that preclude them from having served as expert witnesses in this or other cases involving Microsoft, and impose prohibitions on being employed by Microsoft or its competitors for a limited time before, during and after their service on the TC. Such limited, ancillary employment restriction covenants are also intended to ensure that TC members will not have or develop biases, or be able to trade on confidential, competitively sensitive business information learned while serving on the TC. In appropriate cases, however, these requirements may be waived by the agreement of the parties to the RPFJ. RPFJ § IV.B.2.

391. Microsoft is responsible for paying all costs of the TC. RPFJ §§ IV.B.6, 7, 8.h. It is wholly reasonable that the defendant in this case, rather than the taxpayer, defray the potentially substantial cost of supporting the TC. Microsoft will not be able to manipulate the activities of the TC through any “power of the purse,” however, as it will have the burden of demonstrating the unreasonableness of any TC expense, and the Court has the authority to compel payment in the event of a dispute. RPFJ § IV.B.8.i. The TC will have offices on Microsoft's corporate campus, RPFJ § IV.B.7, which will greatly enhance its ability to carry out its duties; however, Microsoft cannot exercise any control over the TC's activities by virtue of its location. The comments expressing concern that Microsoft somehow can control the TC, either through funding or geographic proximity, are unfounded.^[366]

392. Most importantly, the TC remains under the express control of Plaintiffs, not Microsoft. It is Plaintiffs, not Microsoft, that apply to the Court for the appointment of the TC members. RPFJ § IV.B.3.b, d. The United States, not Microsoft, contracts with the TC for its services, and defines the basic parameters of that agreement. RPFJ § IV.B.6. The United States, but not Microsoft, has the right to remove any TC member if it determines that the member has failed to act diligently and consistently with the purposes of the RPFJ. RPFJ § IV.B.4. The TC files its reports with Plaintiffs, not Microsoft. RPFJ § IV.B.8.e, f.^[367] The hiring of additional staff or consultants by the TC is subject to approval by Plaintiffs; Microsoft is entitled only to prior notice of such hiring, and is obligated to pay for such hires. RPFJ § IV.B.8.h. Plaintiffs, not Microsoft, approve the TC's expenses. If Microsoft brings an objection to the Court concerning the TC's expenses, Microsoft bears the burden of proving that they are unreasonable, and has to pay all costs and attorneys' fees incurred by the TC by virtue of such challenge. RPFJ § IV.9.

C. Internal Compliance

393. Several commentors expressed their preference for the Litigating States' Proposal regarding internal compliance measures. The RPFJ and the Litigating States' Proposal both provide for a Compliance Officer (“CO”) inside Microsoft who will be responsible for developing and supervising internal programs to ensure Microsoft's compliance with the antitrust laws and any final judgment. The Litigating States' proposal largely tracks the RPFJ with respect to the role that the CO is supposed to play to ensure compliance with the terms of the decree. For example, both proposals contemplate that the CO will supervise the review of Microsoft's activities during the term of the decree and will be responsible for ensuring that the relevant company representatives are aware of and have agreed to comply with the decree. Both proposals charge the CO with similar briefing and record-keeping duties.

394. There are, however, certain differences between the two proposals. The RPFJ requires the CO to maintain the procedures for submitting complaints on Microsoft's website, whereas the Litigating States propose that the Special Master handle this particular responsibility. Both approaches achieve the same result. The United States, however, believes that it is more efficient for the CO, who will be a Microsoft employee and therefore in a better position effectively to monitor the website, to handle this task.

395. The Litigating States' Proposal also includes certain provisions that are similar to provisions contained in the IFJ, but that the United States believes are either unnecessary or more effectively addressed in the manner proposed in the RPFJ. For example, the Litigating States' Proposal establishes a Compliance Committee (“Committee”), the only responsibility of which appears to be appointment and removal of the CO. The United States considered this approach but ultimately decided that an independent Technical Committee would be more effective than the Committee contemplated by the States.

396. The Litigating States also propose a confidential reporting mechanism that Microsoft employees can use to report potential violations of the decree or the antitrust laws. One comment suggests that the RPFJ should explicitly permit Microsoft employees to submit anonymous information to the TC.^[368] The RPFJ provides the TC with the ability to receive and evaluate complaints, including anonymous complaints, and the United States believes that the scope of this authority is broad enough to protect Microsoft employees in appropriate cases.

397. Several comments note that the Litigating States' Proposal requires the CO to disseminate the decree (and related materials) to platform software developers and other Microsoft employees involved in working with OEMs, ISVs, IHVs and third-party licensees, whereas the RPFJ requires dissemination only to Microsoft's officers and directors.^[369] See RPFJ § IV.C.3; Litigating States' Proposal § 17. Although a provision similar to the Litigating States' Proposal appeared in the IFJ, the United States ultimately decided that dissemination to officers and directors—who would then be responsible for disseminating additional instructions and advice to lower-level employees—would sufficiently ensure that Microsoft's policymakers, who are responsible for establishing the strategic and technical direction of the company, are on actual notice of the RPFJ's requirements. To require such procedures for all employees would be a significant additional burden, and is unlikely materially to improve either Microsoft's level of compliance or its corporate culpability in the event of violations. Although such education and certification requirements are not unique in antitrust decrees, many antitrust consent decrees entered into by the United States, including the 1994 Microsoft decree (No. 94-CV-1564), do not impose any continuing educationand certification requirements on the defendant whatsoever.

398. In sum, although the Litigating States' proposal and the RPFJ may differ to some degree in the manner in which they define the scope of authority and responsibility given to the CO, both proposals achieve essentially the same result of vigorous internal compliance that will play a crucial role in the effectiveness of the proposed decrees. The United States believes, however, that the procedures for the TC set forth in the RPFJ, when viewed in conjunction with the responsibilities of the TC and the United States' existing enforcement authority, provide the most effective approach to enforcement.

D. Voluntary Dispute Resolution

399. The RPFJ sets up an even more informal, entirely optional, voluntary dispute resolution mechanism that permits third parties or Plaintiffs to first submit complaints to Microsoft's internal Compliance Officer, which Microsoft then can attempt to resolve within 30 days. RPFJ § IV.D.3. Some comments describe this provision as simply a delay mechanism.^[370] In many instances, however, it will be in both Microsoft's and the third party's clear interest to resolve issues quickly and informally, without the expenditure of time, money, and management distraction attendant with more formal investigations and enforcement actions. This provision permits Microsoft and third parties to do so. Further, no person is required to first submit issues to Microsoft's internal Compliance Officer—the process is entirely optional. Any person concerned about delay or Microsoft's good faith may complain to the TC or directly to Plaintiffs.

E. Proposals for a Special Master

400. Some comments argue that the TC should be replaced with a special master similar to that proposed in New York.^[371] Compare RPFJ § IV.B.8, with Litigating States' Proposal § 18. Specifically, the commentors suggest that this type of enforcement regime would provide both a more effective means of ensuring Microsoft's compliance with the final judgment and a vehicle for the speedy resolution of complaints from plaintiffs, state attorneys general, and independent third parties. We disagree on both counts.

401. To some degree, the RPFJ's TC and the States' special master would perform the same functions. Significantly, however, the authority the States propose giving the special master represents an unprecedented, radical, and unwarranted removal of prosecutorial discretion from the United States that would weaken the mechanisms for compliance with the decree.

402. Both the special master and the TC would have the power and authority to monitor Microsoft's compliance with its obligations under the final judgment and would have access to the information, personnel, systems, equipment, premises, and facilities necessary to fulfill their respective responsibilities. Each would be required to receive complaints from a Microsoft Antitrust Compliance Officer, third parties, and the plaintiffs; submit reports every six months regarding Microsoft's compliance with the final judgment; and report any non-compliance at any time. In addition, both the special master and TC would be paid by Microsoft and would be permitted to hire advisors, and such other staff as is necessary, at Microsoft's expense.

403. But the Litigating States' proposal also calls for the appointed special master, with the assistance of an “advisory committee,” to act as prosecutor, witness, and judge. The scope of the special master's authority apparently extends without limitation to all “technical, economic, business” and other aspects of the decree. Litigating States' Proposal §§ 18.d, f. The special master would have unfettered discretion to receive complaints, decide whether to investigate the complaints, conduct the investigation, hold hearings, make factual findings, and issue proposed enforcement orders. Litigating States' Proposal § 18.f. Further, the special master would be bound to act within extremely tight deadlines, regardless of the complexity of the issue, the ability of the parties to marshal evidence within an extraordinarily short 14-day deadline, or the ability of the special master to evaluate the evidence and reach conclusions within a mandatory 15-day post-hearing deadline. Id. The special master's findings—and even its recommendations, apparently whether accepted by the Court or not—would be admissible in any action, and the special master expressly would be permitted to testify in any action, including apparently private litigation. Litigating States' Proposal § 18.h.

404. The United States is aware of no previous antitrust decree to which it has been a party that appoints a special master for general decree enforcement. Rather, in every case in which an action to enforce an antitrust final judgment was necessary, the United States has been permitted to exercise its traditional role as prosecutor.^[372] Likewise, no court has successfully delegated its inherent powers of antitrust judgment enforcement as completely as proposed here.^[373] The comments supporting this radical deviation from established practice cite no compelling reason for such a remarkable course of action.^[374]

405. Some comments express concern about “delay” occasioned by the TC dispute resolution process, suggesting that the tight time deadlines and apparent binding authority of a special master would resolve matters more swiftly.^[375] The TC and other supplemental dispute resolution processes, however, are not mandatory; they in no way constrain the ability of the United States and the State Plaintiffs from proceeding directly to court for interpretative and enforcement action when, in their exercise of prosecutorial discretion, it is appropriate to do so.

406. Moreover, the special master's findings are neither binding nor non-appealable. Thus, although both proposed decrees provide for a different review process for complaints of illegal behavior made against Microsoft, prompt and effective relief is no more certain under one than the other where the parties to the complaint are unwilling to reach a resolution in the absence of a court order. In light of this, the United States, while reserving for Plaintiffs the right to seek court intervention when necessary, believes the model for the resolution of complaints contained in the RPFJ best promotes prompt and effective relief.

F. Proposed Reporting Requirements

407. Some commentors argue that the RPFJ should include special transactionreporting requirements, as the Litigating States' Proposal does. In New York, the Litigating States propose to mandate government oversight of transactions related to the software industry and other related areas by requiring Microsoft to disclose such transactions to the plaintiffs, along with the type of transaction-related materials and information that is typically required in filings with the federal government under the Hart-Scott-Rodino Antitrust Improvements Act of 1976 (“HSR”), where such transactions would not otherwise be subject to the disclosure requirements of the Act.^[376]

408. The United States believes that such a provision is not an appropriate remedy for the violations found by the District Court and sustained by the Court of Appeals. Foremost among the United States' considerations when negotiating the RPFJ was the recognition that the remedy must be consistent with the liability findings of the case, none of which relates to the use of acquisitions by Microsoft as a tool to maintain its operating system monopoly.

409. Furthermore, but no less important, requiring the disclosure of transactions that fall below the HSR threshold would require the United States to engage in purely regulatory behavior without providing any substantial likelihood of assisting in the remedial goal of restoring competitive conditions to the market at issue. The United States strives to enact enforcement tools that are closely targeted to remedying the harm found and restoring competition. The imposition of additional reporting obligations on Microsoft—obligations greater than those deemed appropriate by Congress—would create burdens on Microsoft, the potential acquired parties, and the United States, without adding a significant likelihood of achieving any corresponding increase in the detection of anticompetitive transactions. Moreover, to the extent that the review process unnecessarily delays those transactions that pose no competitive concerns, the reporting obligation runs the risk of having a negative impact on consumers. The United States' standard investigative authority should sufficiently ensure that the United States is aware of—and able to seek more information about—transactions in which Microsoft is involved that might pose a competitive threat.

IX. Termination

410. A number of comments argue that the five-year term in Section V.A (or seven years when including the possible two-year extension under Section V.B) is too short for the RPFJ to remedy the competitive harm.^[377]

411. The five-year period provides sufficient time for the conduct remedies contained in the RPFJ to take effect in this evolving market and to restore competitive conditions to the greatest extent possible.^[378] As the Court of Appeals noted, the characteristics of the market in this case make it conducive to rapid change. See Microsoft, 253 F.3d at 79 (“So a company like Netscape founded in 1994 can be by the middle of 1995 clearly a potentially lethal competitor to Windows because it can supplant its position in the market because of the characteristics of these markets.”) (quoting counsel for Microsoft); id. at 49 (six years is an “eternity” in this market). To be sure, there is no scientific way to determine the optimal term of a consent decree, which is the product of negotiation. The United States' position on the term of a decree is a matter of judgment informed by experience. Ultimately, the United States concluded that a five-year term (extendable by two years) is an appropriate and reasonable predictive judgment in this case.

412. Some comments take the position that the length of Microsoft's anticompetitive conduct should have determined the length of the decree,^[379] but that would have provided an unreliable measuring stick for evaluating the amount of time necessary to restore competitive conditions. Other comments urge the United States merely to adopt the term length from prior recent cases, quoting the Antitrust Division Manual's general guidance that “staff should not negotiate any decree of less than 10 years” duration although decrees of longer than 10 years may be appropriate in certain circumstances.”^[380] Antitrust Division Manual at IV-54 (3d ed. Feb. 1998). But, as the Manual also states at the outset of its discussion of negotiating and entering consent decrees, “[t]he theory behind equitable relief is that it should be fashioned to fit the particular facts of the case at issue.” Id. at IV-50. The longer a decree's duration, particularly if it no longer fits the facts of the case, the more the decree becomes regulatory in nature. The United States has imposed five-year terms in numerous past decrees,^[381] including in industries, like this one, that are characterized by rapid technological change.^[382] In this case, in an evolving market, the five-year term, particularly as augmented by a potential two-year extension, is long enough.^[383] Because Microsoft will be eager to be released from the decree as soon as possible, the prospect of an extension should deter any violations and provide an extra incentive to comply.^[384] Moreover, wholly apart fromseeking the two-year extension, the United States may seek civil and criminal contempt sanctions against Microsoft and its personnel if violations of the decree warrant that action.^[385] See RPFJ § IV.A. Nothing in the RPFJ undermines or erodes the United States' existing and powerful contempt and enforcement authority.^[386] Therefore, in the event that additional steps are necessary to secure compliance or to punish Microsoft for violations of the decree, the United States will not lack the necessary enforcement tools.

413. Some of the comments regarding this issue also express concern that certain key disclosure requirements may not be triggered until as late as one year into the term of the decree, which renders those provisions effective for only four years.^[387] At least one commentor complains that Microsoft has relied upon this provision as the basis for not yet disclosing certain APIs.^[388] We note foremost that Microsoft's obligations under the disclosure provisions are triggered from the date of submission of the RPFJ to the Court on November 6, 2001, not its entry by the Court. See RPFJ §§ III.D-E. The RPFJ will be in place for five years from the date of entry; as such, those commentors who claim that the disclosure provisions will be in effect only for four years have ignored the fact that the clock is already running for Microsoft to implement its disclosure obligations. Moreover, although certain disclosure provisions may not become effective until up to one year after the submission of the decree to the Court (see, e.g., RPFJ § III.H), absent the decree, Microsoft would be under no obligation to provide such information. Giving Microsoft a limited amount of time to implement its duties under these provisions is necessary to ensure that they are properly implemented, and it is the overall impact of the various decree provisions working together over the course of the five-year term that will restore competitive conditions in the market.

X. Comparing the RPFJ to the IFJ

A. Structural Relief vs. Conduct Restrictions

414. A number of commentors suggest that the United States should have pursued a restructuring of Microsoft into separate companies,^[389] arguing that “divestiture remains the most effective remedy for Microsoft's wide-ranging unlawful practices.”^[390]

415. Shortly after remand, plaintiffs (the United States and all of the plaintiff States) informed Microsoft and the Court that, in light of the Court of Appeals' decision, they no longer would seek to break up Microsoft. Joint Status Report 2 (Sept. 20, 2001). Thus, even if the United States had litigated a remedy, it would not have sought structural relief, just as the Non-Settling States do not seek it in their litigated case.

416. This unanimity among the government parties not to seek divestiture reflects a sound view of the legal landscape created by the Court of Appeals, which viewed structural relief in this case skeptically, at best. The Court of Appeals questioned whether plaintiffs had “established a sufficient causal connection between Microsoft's anticompetitive conduct and its dominant position in the [operating system] market” to justify divestiture. Microsoft, 253 F.3d at 106. The Court of Appeals continued that “[a]bsent such causation, the antitrust defendant's unlawful behavior should be remedied by ‘an injunction against continuation of that conduct.’ ”Id. (quoting 3 Antitrust Law¶ 650a, at 67). The Court of Appeals also suggested that the necessary causation might be lacking here, noting that even the District Court “expressly did not adopt the position that Microsoft would have lost its position in the [operating system] market but for its anticompetitive behavior.” Id. at 107 (quoting Findings of Fact,¶ 411) (emphasis added). Moreover, the Court of Appeals observed that divestiture by and large has been directed at “entities formed by mergers and acquisitions,” and told the District Court to “reconsider” whether “divestiture is appropriate with respect to Microsoft, which argues that it is a unitary company.”Id. at 105. And the Court of Appeals emphasized that, when fashioning a new remedy, the District Court should bear in mind that the Court of Appeals had “drastically” altered the basis of liability (Id. at 105, 107) and that the new remedy should reflect the “limited ground of liability” upheld on appeal. Id. at 107.

417. Second, if plaintiffs had pursued structural relief on remand, Microsoft would have been entitled to present evidence challenging a “wide range of plaintiffs” factual representations, including the feasibility of dividing Microsoft, the likely impact on consumers, and the effect of divestiture on shareholders.”Id. at 101. This process not only would have been time consuming—both in the District Court and then, assuming the District Court actually ordered structural relief anew, again in the Court of Appeals—but also would have permitted Microsoft to introduce a plethora of new evidence. Foregoing a structural remedy permitted plaintiffs to speed along the remand proceedings and obtain relief (1) sooner and (2) that more likely would be affirmed on appeal.

B. Anti-Tying Provisions

418. The Court of Appeals vacated and remanded the District Court's judgment that Microsoft's contractual tying of its Internet Explorer web browser with its Windows operating system was per se unlawful under Section 1 of the Sherman Act. See U.S. Memorandum at 6-7, 64-66. Given the Court of Appeals' imposition of a more rigorous legal standard on this claim, including additional and difficult factual proof requirements, and given the plaintiffs' interest in achieving expeditious relief in this case, plaintiffs (including the Litigating States) made a judgment that they would not litigate the Section 1 tying claim on remand and so informed Microsoft on September 6, 2001. At that point, the tying claim disappeared from the case. And so, although two commentors^[391] and the Litigating States urge that the Court impose a remedy directed toward banning contractual tying, there is no legal basis for a remedy on an issue where Microsoft was not found liable and where the plaintiffs had valid grounds for choosing not to pursue the claim.

C. Intentionally Disabling Rival Software

419. Some comments complain that the RPFJ does not “prohibit Microsoft from intentionally disabling oradversely affecting the operation of competing products.”^[392] They argue that such a restriction is necessary to prevent Microsoft from thwarting “the effectiveness of the disclosure requirements by altering the interfaces or other information on which non-Microsoft products rely.”^[393] And they correctly observe that the IFJ contained an interim provision expressly prohibiting Microsoft from “tak[ing] any action it knows will interfere with or degrade the performance of any non-Microsoft Middleware when interoperating with any Windows Operating System Product” without notifying the supplier ahead of time that it intends to take such action and any ways known by Microsoft to avoid or reduce the interference with the performance of the rival software.^[394] One comment also criticizes the RPFJ for omitting a provision similar (or identical) to Provision 5 of the Litigating States' Proposal (“Notification of Knowing Interference with Performance”).^[395]

420. The United States, upon re-evaluation, chose not to include a provision modeled on Section 3.c of the IFJ because that provision could have been read to allow Microsoft to take steps to change its operating system in order to interfere with the ability of rival middleware to interoperate as long as Microsoft informed the third party of the change and what, if anything, could be done to fix the problem. This effectively would have given Microsoft a license to interfere with competing middleware as long as it simply notified the competing developer. In addition, this provision would have been difficult for the United States to enforce because of the constant changes that Microsoft makes to its operating system, which while potentially procompetitive, may have the unintentional consequence of affecting a competing product's interoperability. The result would have been unnecessary compliance disputes.

421. Provision 5 of the Litigating States' Proposal is similar to, though substantially broader than, Section 3.c of the IFJ. Provision 5 is overbroad and sweeps in conduct that should not reasonably be considered anticompetitive. Thus, for example, in the normal course of the development of its software, Microsoft may take actions that have the unintended, but nevertheless known, consequence of interfering with or degrading the performance or compatibility of some non-Microsoft middleware. The United States does not believe that such actions either should be prohibited or subject Microsoft to any additional notice or disclosure requirements. In addition, determining when Microsoft, as a corporate entity, has, or reasonably should have, such knowledge is exceedingly difficult to determine.

422. Moreover, the type of conduct at issue (e.g., actions undertaken for the express purpose of degrading the software of a developer of software that competes with Microsoft Platform Software or software that runs on software that competes with Microsoft Platform Software) would be prohibited by Section III.F of the RPFJ and/or likely would expose Microsoft to statutory, tort, or other legal sanctions apart from the RPFJ.

423. Instead of including a provision similar to Section § 3.c of the IFJ or Section 5 of the Litigating States' Proposal, the RPFJ restrictions and requirements ensure ease in third-party interoperability. Thus, the RPFJ requires Microsoft to disclose those APIs that its middleware products use to interoperate with the operating system. See RPFJ § III.D. This disclosure will make it harder for Microsoft to interfere with competing middleware. Further, to the extent that computer industry standards are implemented in communications protocols, Microsoft must license these protocols (see RPFJ § III.E), including any modifications or alterations to industry-standard protocols. When the industry standard is implemented between a Microsoft middleware product, such as its Java Virtual Machine, and the operating system, Microsoft must disclose that interface.

D. Agreements Limiting Competition

424. Section 3.h of the IFJ included a provision relating to agreements entered into by Microsoft that have the effect of limiting competition.^[396] The United States initially proposed this provision in the IFJ based on Findings of Fact, ¶¶ 80-132, which described five different incidents in which Microsoft attempted to use agreements to limit support for competing middleware: (1) Microsoft's attempt to dissuade Netscape from developing a browser for Windows that could serve as an independent applications platform; (2) Microsoft's attempt to dissuade Intel from developing NSP (video) software for Windows 95; (3) Microsoft's attempt to dissuade Apple from developing multimedia QuickTime playback capability for Windows; (4) Microsoft's agreement with RealNetworks to have RealNetworks abandon the media playback business on the Windows desktop; and (5) Microsoft's offer of incentives to IBM to abandon promotion of OS/2 and Lotus Smartsuite.

425. The primary goal of Section 3.h was to “prohibit naked bargains to not compete” in the platform space.^[397] The RPFJ seeks this same goal, but also expressly recognizes that under settled antitrust law, agreements that limit competition sometimes are properly ancillary to: (1) Pro-competitive joint development agreements; (2) discussions relating to the coordination of the development of complementary products; or (3) Microsoft contracting with third parties to develop technologies for use and distribution with its Windows operating system. Rather than using broad language that could be construed to prohibit all agreements that place limits on competition—and risk prohibiting even those agreements that have procompetitive justification—the United States therefore opted for a more targeted approach in the RPFJ. Sections III.F.2 and III.G of the RPFJ thus are designed to prevent Microsoft from entering into any contract relating to the Windows operating system that conditions consideration on an ISV not supporting software that competes with a Microsoft platform product, requiring any firm to promote exclusively a Microsoft Platform Software, or conditioning placement of an IAP or ICP on the Windows desktop on that firm refraining from supporting any product that competes with a Microsoft Middleware Product.^[398]

XI. Other Proposed Remedies

A. Restrictions On Software Development Tools

426. At least two comments express concern that the RPFJ does not address Microsoft's alleged market power with respect to its line of software development tools. One commentor apparently seeks to compel Microsoft to grant the commentor access to aMicrosoft partnership program that would more easily allow the commentor to incorporate development tools for its alternate platform with Microsoft's Visual Studio development environment. The comment alleges that Microsoft could apply discriminatory criteria, denying alternate platform vendors posing a potential threat to Microsoft's monopoly the ability to integrate their platform development tools with Microsoft's Visual Studio development suite, while allowing other vendors who do not pose a threat to have that access. According to the comment, without a software development environment common to the one used for the dominant Microsoft platform, ISVs and others would be much less likely to write software for alternate platforms, a circumstance that would help preserve Microsoft's applications barrier to entry.^[399]

427. The second comment alleges that Microsoft's license restrictions require ISVs that write software applications that take advantage of the “redistributable components” found in Microsoft's Visual Studio development suite to use such “redistributable” code only on applications written for Microsoft operating system products. This comment argues that this restriction prohibits, as a practical matter, the porting of such applications to other platforms, thereby increasing the applications barrier to entry protecting Microsoft's operating system monopoly. This commentor seeks elimination of this license restriction from Microsoft's Visual Studio license.^[400]

428. The relief sought by these commentors would go well beyond the scope of this case. The evidence that related to Microsoft's misuse of development tools involved specific deceptive practices regarding Microsoft's own development tools for the Java platform. Microsoft in essence failed adequately to disclose that its version of Java development tools contained various Windows-specific features that made it difficult to use or port Java programs written with Microsoft tools to other Java virtual machines or operating systems. See Microsoft, 253 F.3d at 76-77. There is nothing in either the allegations made in these comments or in the trial record to suggest that Microsoft's refusal to allow any competing platform vendor to integrate its development tools with Microsoft's Visual Studio development suite, or its license restrictions that prohibit ISVs from porting applications containing Microsoft redistributable code to other platforms, somehow will deceive ISVs into developing applications that run only on a Microsoft platform.

429. Further, the remedy suggested by these comments could have the effect of retarding innovation, to the detriment of consumers. Requiring Microsoft affirmatively to support allowing competing platform vendors to use Microsoft's Visual Studio development suite to host competing development tools or create applications for non-Microsoft platforms using Microsoft-developed redistributable code may create a significant disincentive for Microsoft to continue to invest heavily in further development of its tools suites or redistributable code, because that investment would redound at least in part to the benefit of Microsoft's competitors. Moreover, software tool developers would lose their incentive to innovate if they were permitted simply to free-ride on Microsoft. That result would not benefit either ISVs or, ultimately, their customers.

B. Java Must-Carry

430. In New York, the Litigating States propose to require Microsoft to include a free copy of Sun Microsystems' Java technology with all copies of its Windows Operating System Products and Internet Browser for a period of ten (10) years. See Litigating States' Proposal § 13. Several comments echo this type of “must-carry” proposal.^[401] The commentors correctly note that the Court of Appeals upheld Microsoft's liability under Section 2 of the Sherman Act for exclusionary conduct aimed at extinguishing the “middleware threat” posed by Java and other middleware. See Microsoft, 253 F.3d at 75-77. The comments suggest that requiring Microsoft to distribute Non-Microsoft Middleware such as Java would not only deny Microsoft the fruits of its violation, but also would begin to erode the applications barrier to entry.

431. The United States considered a “must-carry” provision but rejected it for at least two reasons: (1) it is not the proper role of the government to bless one competitor over others, or one potential middleware platform over others, nor is the government in the best position to do so; and (2) mandatory distribution of a particular product likely would lead to a decrease in innovation and improvement in that product because its developer will have no incentive to make it better. The United States thus believes that the promotion of consumer choice and the product innovation that comes along with that choice, i.e., the promotion of competition and not specific competitors, is the goal of the antitrust laws and this antitrust remedy, while mandatory distribution of a particular product is the antithesis of this goal. Unlike the “must-carry” provision proposed by the Litigating States, the affirmative requirements imposed on Microsoft and the prohibitions against anticompetitive conduct contained in the RPFJ, and the subsequent freedom this structure promotes among ISVs, IHVs, IAPs, ICPs, and OEMs, will give all middleware technologies, including but not limited to Java, an equal opportunity to succeed in the market.

C. Porting Microsoft Office

432. Several comments suggest that Microsoft should be required to port or continue to port its Office Suite of software applications to competing operating systems, including but not limited to the Macintosh OS, as a means to erode the applications barrier to entry.^[402] The Litigating States also have advanced this proposal,^[403] but the proposal is unwarranted.

433. First, the United States did not allege that Microsoft monopolized or attempted to monopolize a software market in which Office competes, or that Microsoft engaged in anticompetitive conduct intended to encourage the use of Office rather than rival software applications that compete with Office.^[404] Second, the imposition of such a porting requirement is substantially outside the scope of the underlying case.^[405] Any remedy must be tailored to the violations found. See Microsoft, 253 F.3d at 104-07. The only claim sustained by the Court of Appeals was that Microsoft illegally maintained its PC operating system monopoly by taking specific acts that impeded middleware products that had the potential to erode the applications barrier to entry. The Court of Appeals did not find that Microsoft's unlawful actions created the barrier to entry. The United States crafted the RPFJ to restore the competitive conditions in the market that were impeded by Microsoft's actions, allowingconsumers, software developers, OEMs, and others to make decisions based on the competitive merit of their options. In this way, the market will determine whether particular products will erode the applications barrier to entry. The commentors' and Litigating States' proposal, however, goes far beyond the violations found by imposing on the market a porting requirement for Office that substitutes for competition on the merits and preordains the market outcome.

D. Licensing of Predecessor Versions of Windows

434. A few commentors propose that the United States adopt the Litigating States' remedy proposal requiring Microsoft to continue to license and support immediately prior versions of the Windows Operating System Product.^[406] Others object to this proposal, arguing that it would impose unnecessary costs on Microsoft that would be passed on to consumers, that it would fragment the Windows standard, and reduce incentives for Microsoft to innovate.^[407] The Litigating States' Proposal mandates support and licensing of predecessor versions for five years after release of a major Windows Operating System Product on the same terms and conditions as previously offered. In addition, Microsoft must license and support Windows 98SE for three years after entry of the Final Judgment.

435. The Litigating States cite the District Court's findings on discriminatory and restrictive licensing as support for this provision. The provision purports to cure these practices by permitting customization of Windows (including earlier versions) to incorporate Microsoft or competitive middleware. Commentors assert that requiring licensing of predecessor versions would provide a lower-priced operating system alternative;^[408] offer a version of Windows that has less Microsoft middleware and greater reliance on industry standards;^[409] and provide greater incentives for Microsoft to innovate, because it would have to offer a substantially better operating system in order to sell new releases.^[410] Commentors also argue that requiring Microsoft to license predecessor versions would permit customization of Windows (including earlier versions) to incorporate Microsoft or competitive middleware.

436. The United States believes that the RPFJ adequately addresses the restrictive and discriminatory licensing practices engaged in by Microsoft and found unlawful by the Court of Appeals. Thus, under the RPFJ, OEMs and end users are free to replace Microsoft middleware, choose between competing middleware, and, with minimal limitations, configure the desktop.^[411] OEMs also are able to make decisions about distributing and supporting non-Microsoft software products without fear of reprisal.^[412] A provision mandating the licensing of predecessor versions of Windows is therefore unnecessary and would do little or nothing to enhance these goals.

E. Industry Standards

437. Several commentors express concern that the RPFJ imposes no requirement on Microsoft to support industry standards for interoperability.^[413] By industry standards, the commentors generally mean industry-wide technical specifications for communication between pieces of software. Such standards often are approved and supervised by international standards-setting organizations (e.g., the World Wide Web Consortium (W3C), which oversees HTML, the language used to create Web pages). In addition to these de jure standards, some specifications for interaction remain under the control of the firms that invent them, but obtain sufficiently wide usage to be considered standards in a less formal sense. An example of this less official category of standards is Sun's Java programming language.

438. Several commentors propose provisions that would constrain Microsoft's behavior with respect to industry standards. Generally, these commentors argue the importance of prohibiting Microsoft from corrupting or “polluting” open standards by extending or altering them with proprietary code to cause them to interoperate better, or solely, with Microsoft software than with rival software.^[414] The commentors correctly point out that the Court of Appeals found that Microsoft undermined the threat posed by Sun's Java middleware by deceiving ISVs into believing that software written with Microsoft's Java developer tools would run on platforms other than Windows (Microsoft, 253 F.3d at 75-77), and they argue that Microsoft continues to adopt but subvert public standards by inserting proprietary elements into the implementation of the Kerberos standard that is built into Microsoft products.

439. One commentor proposes that Microsoft be enjoined from modifying, altering, sub-setting, or super-setting any industry-standard communications interface or security protocol in any way that is not approved by an international industry standards-setting body.^[415] The United States believes this proposal is likely to be ineffective at promoting interoperability and unlikely to benefit consumers. It would not prevent Microsoft from inserting proprietary elements into industry standards that are designed to allow such extensions (for instance, the Kerberos security standard).^[416] Nor would it constrain in any way Microsoft's actions with respect to industry standards like Java that are not under the supervision of an international standards body. It would simply deter Microsoft from introducing potentially beneficial extensions to industry standards, since Microsoft would have to work through the approval process at a standards body before it could introduce its innovation.

440. The Litigating States propose a range of provisions to encourage Microsoft to adhere to industry standards.^[417] Litigating States Provision 16.a (“Compliance with Standards”) would require Microsoft to comply with any standard that has been approved by or submitted to “any organization or group that sets standards,” if Microsoft publicly claims that it is compliant with the standard. If Microsoft extends or modifies that standard, it must continue also to implement the standard in its unextended or unmodified version, until either Microsoft disclaims that it implements the standard or the standard goes out of force at the industry body. Microsoft may not require third parties to use or adopt Microsoft's version of the standard and must support the nonproprietary industry version in its operating systems. The United States considered a provision substantially similar to Litigating States Provision16.a for the RPFJ, but ultimately decided it was likely to be both unwieldy and ineffective.^[418]

441. This type of standards requirement likely would prove unwieldy because of the complexity of the institutions, technologies, and behavior being regulated here. Which among the multitude of existing standards-setting bodies, or bodies that might be established after, and possibly because of, this decree, would be considered legitimate under Provision 16.a? (What if Microsoft sponsors a new standards body, for instance?) Is it even technically possible or desirable, in all covered circumstances, for Microsoft to meet the requirements of the provision by supporting the industry standard of a technology at the same time it supports its own extended version?

442. The Litigating States' provision also is likely to be ineffective. It substantially regulates Microsoft's speech rather than its actions. If Microsoft publicly claims to be supporting its own implementation of a standard (e.g.,“Microsoft Technology A”) and does not publicly claim to be supporting the standard itself (e.g.,“Technology A”), it would be in full compliance with the provision and yet would not have any obligation to adhere to the “Technology A” standard. It is difficult to see a provision that operates in this manner as imposing a competitively meaningful constraint. Moreover, to the extent that the provision regulates actions, it appears to be internally contradictory. It requires Microsoft, as a condition of being permitted to introduce a proprietary version of the standard, to implement the industry version until either Microsoft disclaims support for it or until the standard is rescinded by the governing body. But it also explicitly requires Microsoft's operating systems to continue to support the industry standard, apparently without time limit, as a condition of being permitted to introduce Microsoft's own proprietary version.

443. Litigating States' Provision 16.b (“Compliance with De Facto Standards”) modifies Provision 16.a to permit Microsoft, upon notification and consent of the States' enforcement authorities, to meet its compliance obligations by implementing a variant of the standard “to the extent that industry custom and practice recognizes compliance with the Standard to include variations from the formal definition.” The need for this provision highlights the unwieldiness of Provision 16.a: what is truly “standard” in the industry is not necessarily what a standards body formally has adopted. Further, and fatally for those who justify the Litigating States' Provision 16 as a response to Microsoft's illegal Java deception, no part of that section actually would have prohibited Microsoft from pursuing its illegal acts.^[419] Throughout most of its history, Sun's Java has neither been a technical standard approved by, submitted to, or under consideration by a standard-setting body (the criterion for protection under Provision 16.a) nor a “variation” from such a standard (the criterion under Provision 16.b), but rather a widely-used proprietary technology under the control of its owner, Sun.

F. Protection for Large End Users

444. A few commentors lament the lack of special protection in the RPFJ for large end user purchasers of Microsoft products.^[420] These commentors express several concerns regarding large corporations, universities, or federal, state, or local government purchasers: (1) Microsoft may retaliate against end users purchasing competing middleware;^[421] (2) Microsoft continues to charge license fees to these purchasers for all machines capable of running a Microsoft operating system (a “per processor fee”), thereby removing incentives to purchase competing operating systems;^[422] (3) Microsoft imposes other coercive licenses directed at end users;^[423] and (4) Microsoft, without some restraint, can undo all of the RPFJ provisions applying to OEMs upon the first license renewal with an end user.^[424]

445. The commentors' proposed relief is outside the scope of the underlying case. The United States did not allege, or prove, that Microsoft engaged in anticompetitive conduct involving its large end user customers. Although the United States proved that Microsoft illegally maintained its PC operating system monopoly through actions directed at eliminating the middleware threat, it presented no evidence—and the District Court made no finding—that purchasers large and sophisticated enough to deal directly with Microsoft were in need of special protection.

446. Nevertheless, certain provisions of the RPFJ do apply to end users. Pursuant to Section III.H.1-2, end users are able (1) to configure the desktop to enable or remove access to each Microsoft Middleware Product as described, and (2) to designate a Non-Microsoft Middleware Product to be invoked in place of a Microsoft Middleware Product as described. And, pursuant to Section III.H.3, Microsoft cannot alter those configurations without permission from the end user.

G. Non-Retaliation for Participation in Litigation

447. At least one comment^[425] has advocated inclusion of the Litigating States' proposal specifically to prohibit retaliation by Microsoft against those who participated in litigation in either of the now de-consolidated actions.^[426] Such a provision is unnecessary because the Court retains ample authority, regardless of whether such a provision is included in the RPFJ, to sanction such conduct if and when it arises.

448. Thus, should retaliation of the sort described by the comment arise, the United States may petition the Court to exercise its continuing jurisdiction to issue “further orders as may be necessary or appropriate to carry out or construe this Final Judgment . . . to modify . . . any of its provisions, to enforce compliance, and to punish violations thereof.” RPFJ § VII. Under both its inherent powers and Section VII of the RPFJ, the Court could take whatever action is necessary to prevent, halt, and remedy any such retaliation against participants in this litigation. Further, depending on the facts of any such retaliation, Microsoft also could face criminal liability under a number of statutes. See, e.g., 18 U.S.C. 1503 (“whoever . . . corruptly or by threats or force, or by any threatening letter or communication, influences, obstructs, or impedes, or endeavors to influence, obstruct, or impede the due administration of justice . . .”); 18 U.S.C. 1512 (witness tampering, generally). A specific anti-retaliation provision of the sort proposed here is therefore unnecessary and unwarranted.

XII. Miscellaneous Comments

A. Microsoft's “.Net” Initiative

449. Some comments^[427] argue that the RPFJ fails effectively to constrain Microsoft's diverse set of announced and emerging web services initiatives, grouped generally under the “.Net” trademark.^[428] The comments claim that Microsoft, having vanquished the nascent cross-platform distributedcomputing threat posed by the Java architecture, is now implementing its own closed system that will require Microsoft operating system products on both the server side of the network and on the client side (i.e., Windows Operating System Products). Under such a scenario, argue the commentors, neither server nor client software competitors of Microsoft will be able to interoperate with the .Net technologies. The suggested remedies for this situation, according to the comments, range from mandatory transparency of all Microsoft APIs, Communications Interfaces, and other technical information, regardless of whether the disclosures touch on either Microsoft's desktop operating system monopoly or middleware, to mandatory porting of the basic .Net architecture (the “.Net Framework”) to several alternate server and client platforms. These criticisms are not well taken.

450. First, whether .Net is, in fact, likely to have an anticompetitive effect, or what its competitive significance might be in general, is not yet clear. The very concept of “web services” is still evolving as new ways to use networking and the Internet are discovered. Many parts of .Net, and even some of the detailed plans for .Net, have not yet been released, and therefore cannot fully be evaluated. Similarly, announced (but not yet released) alternate web services frameworks, such as the multi-vendor “Liberty Alliance”^[429] founded by Sun Microsystems, are not fully developed and do not have actual products in the market. It would be difficult, if not impossible, to draw conclusions about the competitive impact of such pre-nascent initiatives that have sufficient reliability to warrant additional remedies or restrictions.

451. Second, the remedies proposed by the commentors, including mandatory transparency of Microsoft technical information, regardless to whether such disclosures relate to middleware or Microsoft's operating system, reach beyond the scope of the case as sustained by the Court of Appeals. Any remedy must focus on addressing the specific conduct by Microsoft to impede the nascent middleware threat to its operating system.

452. Third, to the extent .Net might implicate middleware or Microsoft's platform monopoly as developed in this case, it can, of course, fully be evaluated within the context of the RPFJ and this case. Thus, availability of Communications Protocols as provided for in Section III.E of the RPFJ provides a continuing obligation for Microsoft to make available, through licensing on reasonable and non-discriminatory terms, the Communications Protocols utilized by the .Net Framework to the extent these Communications Protocols are used by a Microsoft server operating system product to interoperate with the Windows Operating System Product. See discussion at Section III(B)(1)(d)-(2)(e), above. The practical effect of this provision is that, if Microsoft puts client/server interfaces for the .Net framework in its monopoly Windows Operating System Product, these interfaces will be available for use by third parties. Indeed, the United States understands that various Microsoft technologies, including the Active Directory services model, the Kerberos security model, and the Common Language Runtime analog to Java virtual machines, are core components of the .Net Framework that the comments complain about and are already covered by the RPFJ. See CIS at 37-39.

B. Course of Conduct

453. A commentor criticizes the United States for taking the position that the Court of Appeals failed to uphold Microsoft's course of conduct as an independent violation of Sherman Act § 2.^[430] Yet, it is difficult to see how the Court of Appeals could have made its position any clearer:

the District Court did not point to any series of acts, each of which harms competition only slightly but the cumulative effect of which is significant enough to form an independent basis for liability. The “course of conduct” section of the District Court's opinion contains, with one exception, only broad, summarizing conclusions. See, e.g., Conclusions of Law, at 44 (“Microsoft placed an oppressive thumb on the scale of competitive fortune. . . .”). The only specific acts to which the court refers are Microsoft's expenditures in promoting its browser, see id. (“Microsoft has expended wealth and foresworn opportunities to realize more. . . .”), which we have explained are not in themselves unlawful. Because the District Court identifies no other specific acts as a basis for “course of conduct” liability, we reverse its conclusion that Microsoft's course of conduct separately violates § 2 of the Sherman Act.

Microsoft, 253 F.3d at 78.

454. The comment disagrees that the net effect of the Court of Appeals's substantial narrowing of the findings of liability, including its rejection of the District Court's “course of conduct” finding, was to curtail the available remedies. Again, the Court of Appeals made clear that “[w]hile we do not undertake to dictate to the District Court the precise form that relief should take on remand, we note again that it should be tailored to fit the wrong creating the occasion for the remedy.” Id. at 107; see also id. (“we have drastically altered the scope of Microsoft's liability, and it is for the District Court in the first instance to determine the propriety of a specific remedy for the limited ground of liability which we have upheld”). In light of the Court of Appeals' decision, the wrong creating the occasion for remedy—the limited ground of liability upheld—is Microsoft's specific practices, and not any alleged course of conduct undertaken to protect the operating system monopoly.

C. Restoring Java/Netscape Threats

455. Several commentors^[431] suggest that the RPFJ does nothing to restore Netscape Navigator and Java as competitive threats to Microsoft. This criticism ignores what the RPFJ does do: it restores the ability of middleware, including browsers like Navigator and other middleware like Java, to threaten the applications barrier to entry protecting Microsoft's operating system monopoly. The RPFJ not only enjoins Microsoft from continuing the anticompetitive conduct that it directed against Netscape and Java but also, as detailed elsewhere, imposes affirmative obligations on Microsoft that will give middleware providers the opportunity to develop as threats to Microsoft's operating system monopoly. The United States believes that this restoration of the opportunity for middleware of all types, present and future—and not limited to Web browsers and Java—to erode Microsoft's operating system monopoly is the appropriate goal for a remedy in this case.

456. As an initial matter, some comments presuppose that, had Microsoft not engaged in its unlawful conduct, both Netscape and Java would have succeeded in eroding Microsoft's operating system monopoly. In fact, however, even the District Court concluded that “there is insufficient evidence to find that, absent Microsoft's actions, Navigator and Java already would have ignited genuine competition” in the PC operating system market. Findings of Fact, ¶ 411; see also id., ¶ 69 (threat posed by Netscape was only a “potential” threat); id., ¶ 77 (Netscape and Java had “a long way to go before they might imperil theapplications barrier to entry”). And similarly, the Court of Appeals did not adopt the view that Microsoft “would have lost its position in the OS market but for its anticompetitive behavior.”Microsoft, 253 F.3d at 107. Thus, the emphasis that these comments place on the restoration of Java and Netscape as “threats” is misplaced.

457. The United States believes that the relief contained in the RPFJ, which applies to a broad range of middleware functionality and not just to Web browsers and Java, achieves the overriding goal that these comments also desire: the restoration of competitive conditions so that consumers have choices and collectively can determine competitors' respective fates. The relief will allow for Navigator, Java, and other current middleware products to fulfill whatever capability they have as threats to Microsoft's operating system monopoly and for other new and as-of-yet unanticipated forms of middleware to evolve as potential threats to Microsoft's monopoly.

D. Microsoft's Responses to the Litigating States' RFAs

1. Meeting of the Minds

458. Two commentors say that Microsoft's responses to Requests for Admission (RFAs) in New York show that the United States and Microsoft failed to reach a meeting of the minds on the essential terms of the RPFJ.;^[432] Because these commentors mischaracterize Microsoft's responses, however, they mistakenly see disagreement where agreement exists.

459. The Litigating States in New York propounded 51 RFAs, pursuant to Fed. R. Civ. P. 36(a), some of which sought Microsoft's interpretation of the terms of the RPFJ and cited or quoted (and on occasion mis-quoted) the CIS.^[433] In response, Microsoft objected to these and other RFAs on the basis that they call for a legal conclusion. The mere fact that Microsoft asserted legal objections to this discovery carries no significance in this case, because it does not constitute evidence of anything at all about the meeting of the minds of the parties to the settlement.

460. In response to a limited number of RFAs, however, Microsoft did deny that it shares the opinion of the United States as set forth in the CIS.^[434] But none of the selected portions of the CIS quoted addresses an interpretation of the terms of the RPFJ. Rather, the cited portions of the CIS contain expressions of the United States' views regarding the competitive significance of the RPFJ: “the key to the proper remedy in this case” (RFA No. 2); that OEMs are a crucial distribution channel (RFA No. 3); that it is critical that OEMs are free to distribute and promote non-Microsoft middleware (RFA No. 4); that Windows license royalties and terms are complex and easy for Microsoft to use to affect OEMs' behavior (RFA No. 10), and that the competitive significance of middleware is highly dependent on certain factors (RFA No. 32). Microsoft's disagreement with the United States' opinion in these matters has no bearing on the parties' interpretation of essential terms of the RPFJ.

2. Objections to Language in the CIS As “Vague and Ambiguous”

461. In response to other RFAs, Microsoft identifies certain terms (all used by the United States in the CIS) as “vague and ambiguous” and objects to the RFAs on that basis.^[435] Microsoft also identifies as “vague and ambiguous” a sentence in the RFA referring to Section III.J.1.a (RFA No. 45 (quoting terms from CIS at 39 (discussing RPFJ Section III.J.1.a))).

462. In response to concerns raised by commentors regarding the interpretation of Section III.E, the United States and Microsoft have agreed to the modification of the language of Section III.E described in Section VII(B) above. For a discussion of the terms of Section III.J, see Section VII(D) above.

E. “Open Source” Community

463. Commentors raise a variety of concerns about how the RPFJ may affect the “open source” community. Generally, “open source” software is distinguished from traditional, proprietary software by who writes it, how (or whether) they are compensated, and the terms under which it is licensed to users and other developers. Open source software often is written by collections of individuals not affiliated within the framework of a firm, who may or may not be compensated for their work, and generally is distributed under licenses that grant greater rights to create and distribute derivative works than is typical of licenses for traditional, proprietary software.^[436] The Linux operating system, for example, is open source software.

464. Several commentors express concern that Microsoft somehow may claim that an open source developer, or a network of open source developers, or a marketer of open source software, should not be considered to meet Section VI.I's definition of an “ISV” and so should not receive the benefits and protections given to ISVs by the RPFJ.^[437] The United States believes this concern is groundless. See the discussion in Section III(A), above.

465. A number of commentors are concerned that Microsoft will deny disclosure of APIs and Documentation (as required by Section III.D), or licensing of Communications Protocols (as required by Section III.E), to open source developers on the grounds that the developers do not meet the “reasonable business need” or “authenticity and viability of [ ] business” criteria of Section III.J.2.^[438] The United States believes that the requirements in Section III.J.2 are no broader than is necessary to prevent misuse or misappropriation of intellectual property. See the discussion at Section VII(D), above.

466. One commentor in the open source community contends that the RPFJ fails to restore competitive conditions because the RPFJ does not prohibit Microsoft from bringing infringement suits to protect its extensive patent portfolio. The commentor recommends requiring Microsoft to license all of its intellectual property that would otherwise potentially be infringed by products that threaten Microsoft's operating system monopoly, including competing operating systems, middleware, or other software and hardware.^[439] The United States believes that preventing Microsoft from protecting its intellectual property is unwarranted and inappropriate. Section III.I requires Microsoft to license to OEMs, ISVs, IAPs, and others “any intellectual property rights” necessary for those entities to exercise any of their options or alternatives under the RPFJ. But allowing rivals otherwise to expropriate Microsoft's intellectual property in order to compete with Microsoft would deter Microsoft from investing in innovation and simultaneously deter rival developers from inventing different, new, potentially better technologies to build into their own products. Nothing in this “solution” would benefit consumers.

467. In a similar but less extreme vein, another commentor suggests that the RPFJ should require Microsoft to list which software patents protectWindows APIs, so that vendors of other operating systems can avoid infringing Microsoft's patents accidentally and reassure users that those operating systems are not infringing.^[440] While avoiding infringement is a laudable goal, it is not the purpose of the RPFJ to reduce the legal and technical efforts necessary for competitors to build products that they may lawfully market.

468. Several commentors complain that the RPFJ does not eliminate license terms that prohibit open source and other developers from finding ways to make Windows applications run on non-Windows operating systems. The issues these commentors raise appear to concern both terms in the licenses for Microsoft Office and terms in the licenses for Windows APIs and tools.^[441] The Litigating States' Provision 6.b addresses the same point; it would prohibit agreements that “restrict Microsoft redistributable code from use with non-Microsoft Platform Software.” Such provisions are far outside the scope of this case, and in any event are unlikely to benefit consumers. If Microsoft could not prevent people from expropriating and modifying its applications or middleware products—that is, its “redistributable code”—to turn them into complements to non-Microsoft operating systems, Microsoft would have a significantly reduced incentive to invest in developing and marketing attractive applications and middleware for Windows users.

469. One comment contends that Microsoft should be prohibited from retaliating against an OEM that ships computers loaded with only a non-Microsoft operating system, rather than (as in Section III.A.2) prohibited only from retaliating against an OEM that ships a computer with Microsoft and non-Microsoft operating systems or one that ships a computer that will “dual-boot” with more than one operating system.^[442] Neither the District Court nor the Court of Appeals held Microsoft liable because it prevented OEMs from producing PCs with non-Microsoft operating systems; thus, there is no basis for redressing such conduct. The absence of such a provision, however, is not problematic. If the OEM ships no machines with Windows, then presumably it ships no machines with Windows applications, either; thus, Microsoft would have few ways to “retaliate” against that OEM for its decision not to ship Windows.

F. “Reasonableness” Standard

470. A handful of comments express concerns about the use of a “reasonableness” standard in various provisions of the RPFJ.^[443] The commentors assert that use of a reasonableness standard for measuring certain of Microsoft's conduct offers little practical guidance, and injects ambiguity into the decree, rendering it virtually unenforceable.^[444] Commentors also assert that the adoption of a reasonableness standard turns the RPFJ into nothing more than an admonition to Microsoft to comply with the law.^[445]

471. Contrary to these comments' assertions, measuring a defendant's conduct against a reasonableness standard does not render the RPFJ impermissibly vague. Inclusion of the term “reasonable” is common in antitrust decrees. See, e.g., United States v. Enova Corp., 107 F. Supp.2d 10, 21, 27 (D.D.C. 2000) (defendant required to use “reasonable best efforts” to obtain approvals and “all reasonable efforts” to maintain assets in a decree entered by the Court); United States v. 3D Sys. Corp., 66 FR 49200-01 (D.D.C. 2001) (defendant to provide “reasonable access to personnel,” “reasonable efforts” by trustee to sell assets); United States v. Premdor, Inc., 66 FR 45326-01 (D.D.C. 2001) (defendant to use “reasonable efforts” to maintain assets, provide “reasonable levels of transitional support,” provide “reasonable access” to personnel, trustee to receive “reasonable compensation”); United States v. Electronic Payment Servs., Inc., 1994-2 Trade Cas. (CCH) ¶ 70,796, 1994 WL 730003 at *4 (D. Del. 1994) (third-party processor is qualified if it meets “reasonable and nondiscriminatory technical, financial and operating criteria”; defendant may charge “reasonable set-up fees”); United States v. Pilkington PLC, 1994-2 Trade Cas. (CCH) ¶ 70,842 1994, WL 750645 at * 4 (D. Ariz. 1994) (permitting charges of “commercially reasonable and non-discriminatory Fees for the use or sublicensing of Float Technology . . .”).^[446]

472. Certain commentors urge that the RPFJ reject the reasonableness standard and, instead, adopt bright-line prohibitions against Microsoft engaging in various activities.^[447] Such absolute prohibitions might benefit Microsoft's rivals, but they also would reduce choice and thus not be in the interest of competition and consumers overall.^[448] Moreover, bright-line rules tend to require elaborate definitions that can render an agreement unduly complex. The inclusion of the reasonableness standard represents a recognition of the necessity for terms to be sufficiently flexible to allow for a multitude of future possibilities without requiring excess verbiage.^[449]

473. Commentors are also incorrect in their insistence that including a reasonableness standard simply engrafts the rule of reason into the RPFJ,^[450] turning it into an instruction to Microsoft to comply with the law—effectively to “go forth and sin no more.” In fact, the RPFJ goes beyond eliminating illegal practices and preventing recurrence of the same or similar practices in the future. The RPFJ also takes affirmative steps to restore the competitive threat that middleware posed prior to Microsoft's unlawful undertakings. So, for example, Microsoft is required to disclose and license its proprietary technology—although the Court of Appeals did not sustain any allegation that a failure to do so constituted monopoly maintenance.Similarly, the RPFJ ensures access to, and use of, Microsoft's proprietary server-related protocols, even though the word “server” does not appear in the complaint and appears only in passing in the Findings of Fact. An instruction simply to obey the law would have taken the form of a decree saying only that Microsoft is enjoined “from future violations of the antitrust laws,” in stark contrast to the detailed and specific prohibitions in the RPFJ.

474. Finally, commentors suggest that the inclusion of a reasonableness standard will require a court to interpret the RPFJ, with an attendant delay in enforcement. That a decree may require interpretation is not and cannot be a basis for rejection; otherwise, no decree would remain.

G. Computers for Schools

475. Many comments refer to or discuss the proposed settlement in the private, class actions against Microsoft, whereby Microsoft would donate $1 billion worth of computer hardware and software to needy schools. See In re Microsoft Corp. Antitrust Litig., 2002 WL 99709 (D. Md. Jan. 11, 2002) (proposed settlement in MDL No. 1332).

476. There is no relationship between the settlement of the United States' antitrust lawsuit against Microsoft and the settlement of the private, class action against the company. Because these comments relate to the settlement of an entirely different proceeding, in which the United States played no role, we do not believe these comments can be appropriately construed as comments on the RPFJ and therefore do not respond to them.

477. To the extent that comments mean that the RPFJ is deficient because it does not require Microsoft to make charitable donations, that cannot be a legal basis for rejecting a consent decree. Requiring charitable donations is not a proper remedy in a government civil antitrust case.

Respectfully submitted,

Charles A. James

Assistant Attorney General

Deborah P. Majoras

Deputy Assistant Attorney General

Phillip R. Malone

Renata B. Hesse

David Blake-Thomas

Paula L. Blizzard

Kenneth W. Gaul

Adam D. Hirsh

Jacqueline S. Kelley

Steven J. Mintz

Barbara Nelson

David Seidman

David P. Wales

Attorneys U.S. Department of Justice, Antitrust Division, 601 D Street N.W., Suite 1200, Washington, D.C. 20530-0001, [phone].

Philip S. Beck,

Special Trial Counsel.

February 27, 2002.

Appendix A

Comments Cited in the Response

1. Allen Akin (“Akin”)—MTC-00002904

2. Mark Alexander (“Alexander”)—MTC-00002572

3. America Online/Time Warner (“AOL”)—MTC-00030615

4. The American Antitrust Institute (“AAI”)—MTC-0030600

5. Declaration of Kenneth J. Arrow, submitted as Attachment to ProComp (“ProComp, Arrow”)—MTC-00030608

6. Association for Competitive Technology (“ACT”)—MTC-00027806

7. Joseph L. Bast (“Bast”)—MTC-00013362

7. John Becker (“Becker”)—MTC-00031674

8. Jim Bode (“Bode”)—MTC-00003974

9. Kris Brinkerhoff (“Brinkerhoff”)—MTC-00013542

9. Matthew M. Burke (“Burke”)—MTC-00024360

10. John A. Carroll (“Carroll”)—MTC-00008557

11. Catavault—MTC-00033650

12. Center for the Moral Defense of Capitalism (“CMDC”)—MTC-00028833

13. Robert Cheetham (“Cheetham”)—MTC-00004982

14. Jerry Clabaugh (“Clabaugh”)—MTC-00004870

15. Tony Clapes (“Clapes”)—MTC-00004159

16. Computer Communications Industry Association (“CCIA”)—MTC-00030610

17. Computing Technology Industry Association (“CompTIA”)—MTC-00028726

18. Consumer Federation of America (“CFA”)—MTC-00028565

19. Consumers for Computing Choice and Open Platform Working Group (“CCC”) —

MTC-00033613

20. Tim Daly (“Daly”)—MTC-00000307

21. Jerry Davis (“Davis”)—MTC-00004860

22. David Demland (“Demland”)—MTC-00007735

23. Sean Drew (“Drew”)—MTC-00014368

24. Nicholas S. Economides (“Economides”)—MTC-00022465

25. Einer Elhauge (“Elhauge”)—MTC-00027209

26. Scott Francis (“Francis”)—MTC-00021847

27. Sean Gallagher (“Gallagher”)—MTC-00012695

28. John Giannandrea (“Giannandrea”)—MTC-00030193

29. Tom Giebel (“Giebel”)—MTC-00018241

30. Jonathan Gifford (“Gifford”)—MTC-00028546

31. David Godshall (“Godshall”)—MTC-00002260

32. Eberhard Hafermalz (“Hafermalz”)—MTC-00009260

33. Wayne Hammett (“Hammett”)—MTC-00002009

34. Derek Harkess (“Harkess”)—MTC-00022874

35. Norman Harman (“Harman”)—MTC-00022721

36. Jeffrey E. Harris (“Harris”)—MTC-00027387

37. Rebecca Henderson (“Henderson”)—MTC-00030602

38. Jim Herrmann (“Herrmann”)—MTC-00010686

39. Phillip Hofmeister (“Hofmeister”)—MTC-00004548

40. Art Holland (“Holland”—MTC-00000643

41. Joe Huwaldt (“Huwaldt”)—MTC-00004162

42. Paul Johnson (“Johnson”)—MTC-00012543

43. KDE League, Inc. (“KDE”)—MTC-00028788

44. Dan Kegel (“Kegel”)—MTC-00028571

45. Ronald A. Klain, Benjamin G. Bradshaw, Jessica Davidson Miller, A Detailed Critique of the Proposed Final Judgment in U.S. v. Microsoft, submitted as Attachment B to AOL (AOL, Klain)—MTC-00030615

46. The Honorable Herb Kohl, U.S. Senator (“Sen. Kohl”)—MTC-00030603

47. Brian Koppe (“Koppe”)—MTC-00018682

48. Robert Levy (“Levy”)—MTC-00004804

49. Scott Lewis (“Lewis”)—MTC-00026511

50. Robert E. Litan, Roger D. Noll, and William D. Nordhaus (“Litan et al.”)—MTC-00013366

51. Litigating States—MTC-00030607

52. Chris M. Lloyd (“Lloyd”)—MTC-00011255

53. Mike Lococo (“Lococo”)—MTC-00004717

54. Kevin Lowe (“Lowe”)—MTC-00017163

55. Daniel Maddux (“Maddux”)—MTC-00021587

56. Frank Mathewson and Ralph A. Winter, Microsoft's Tying Strategies to Maintain Monopoly Power in its Operating System, submitted as Attachment A to AOL (“AOL, Mathewson Winter”)—MTC-00030615

57. John McBride (“McBride”)—MTC-00004731

58. Garrett McWilliams (“McWilliams”)—MTC-00019950

59. Andrig T. Miller (“Miller”)—MTC-00003096

60. David Mitchell (“Mitchell”)—MTC-00017643

61. Eben Moglen (“Moglen”)—MTC-00027626

62. David Morrissey (“Morrissey”)—MTC-00004525

63. Ralph Nader and James Love (“Nader/Love”)—MTC-00028313

64. NetAction and Computer Professionals for Social Responsibility (“NetAction”)—MTC-00030604

65. The New York Times (“NYT”)—MTC-00029783

66. Novell, Inc. (“Novell”)—MTC-00029523

67. Palm, Inc. (“Palm”)—MTC-0030613

68. Ramon G. Pantin (“Pantin”)—MTC-00029685

69. Theresa Peterson (“Peterson”)—MTC-00019410

70. Larry Poindexter (“Poindexter”)—MTC-00000493

71. R.D. Porcher (“Porcher”)—MTC-00015938

72. Vince Pratt (“Pratt”)—MTC-00004691

73. The Progress Freedom Foundation (“PFF”)—MTC-00030606

74. Project to Promote Competition Innovation in the Digital Age (“ProComp”)—MTC-00030608

75. RealNetworks, Inc. (“RealNetworks”)—MTC-00029305

76. Red Hat, Inc. (“Red Hat”)—MTC-00030616

77. Ray Reid (“Reid”)—MTC-00022393

78. Relpromax Antitrust, Inc. (“Relpromax”)—MTC-00030631

79. Declaration of Edward Roeder, submitted as Attachment to CCIA (“CCIA, Roeder”)—MTC-00030610

80. P.J. Rovero (“Rovero”)—MTC-00002180

81. SBC Communications, Inc. (“SBC”)—MTC-00029411

82. Robert L. Scala (“Scala”)—MTC-00016177

83. Joel Schneider (“Schneider”)—MTC-00022882

84. Bion Schulken (“Schulken”)—MTC-00002254

85. Bob Schulze (“Schulze”)—MTC-00018164

86. David Skinn (“Skinn”)—MTC-00031409

87. Software and Information Industry Association (“SIIA”)—MTC-00030614

88. Sony Corporation (“Sony”)—MTC-00030605

89. Robert Spotswood (“Spotswood”)—MTC-00000604

90. Declaration of Joseph E. Stiglitz and Jason Furman, submitted as Attachment to CCIA (“CCIA, Stiglitz Furman”)—MTC-00030610

91. Sun Microsystems, Inc. (“Sun”)—MTC-00030609

92. The Telecommunications Research and Action Center, National Black Chamber of Commerce, and National Native Americans Chamber of Commerce (“TRAC”)—MTC-00028893

93. Stuart Thiel (“Thiel”)—MTC-00012095

94. Mason Thomas (“Thomas”)—MTC-00030468

95. Nikkil Tilwalli (“Tilwalli”)—MTC-00016984

96. Robert Timlin (“Timlin”)—MTC-00011156

97. The Honorable John V. Tunney, Former U.S. Senator (“Sen. Tunney”)—MTC-00032065

98. Nicholas Turk (“Turk”)—MTC-00016312

99. U.S. Senate—MTC-00033734

100. Lee Wagstaff (“Wagstaff”)—MTC-00014376

101. Steven Waldman (“Waldman”)—MTC-00025808

102. Michael Wang (“Wang”)—MTC-00003256

103. Washington Legal Foundation (“WLF”)—MTC-00030601

104. Robert Weiler (“Weiler”)—MTC-00017967

105. Tim Williams (“Williams”)—MTC-00000491

106. Chris Young (“Young”)—MTC-00014037

107. Anthony W. Youngman (“Youngman”)—MTC-00010202

Stipulation and Second Revised Proposed Final Judgment

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant; Stipulation.

Next Court Deadline: March 6, 2002; Tunney Act Hearing

Plaintiff United States of America (“United States”), the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin (collectively, the “Settling States”) and Defendant Microsoft Corporation (“Microsoft”), by and through their respective attorneys, having agreed to the entry of this Stipulation, it is hereby stipulated and agreed that:

1. A Final Judgment in the form attached hereto (“second revised proposed Final Judgment”) may be filed and entered by the Court in this action and as to the Settling States only in State of New York, et al. v. Microsoft (Civil Action No. 98-1233(CKK)), upon the motion of any party or upon the Court's own motion, at any time after compliance with the requirements of the Antitrust Procedures and Penalties Act, 15 U.S.C. 16, and without further notice to any party or other proceedings, provided that the United States has not withdrawn its consent, which it may do at any time before the entry of the second revised proposed Final Judgment by serving notice thereof on Microsoft and by filing that notice with the Court.

2. Microsoft's prior obligations to comply with the revised proposed Final Judgment, submitted to the Court on November 6, 2001, shall continue uninterrupted under this Stipulation and the second revised proposed Final Judgment (except as modified by the second revised proposed Final Judgment) as if the second revised proposed Final Judgment was in full force and effect. Unless otherwise provided in the second revised proposed Final Judgment, Microsoft shall immediately begin complying with the second revised proposed Final Judgment as if it was in full force and effect. Where the second revised proposed Final Judgment provides that the timing of Microsoft's obligations are calculated from the date of submission to the Court of the second revised proposed Final Judgment, the time shall be calculated from November 6, 2001, the date of submission to the Court of the revised proposed Final Judgment. Subject to the foregoing, Microsoft agrees to be bound by the provisions of the second revised proposed Final Judgment pending its entry by the Court. If the United States withdraws its consent, or if (a) the second revised proposed Final Judgment is not entered pursuant to the terms of the Stipulation, (b) the time has expired for all appeals of any Court ruling declining to enter the second revised proposed Final Judgment, and (c) the Court has not otherwise ordered continued compliance with the terms and provisions of the second revised proposed Final Judgment, then all of the parties shall be released from all further obligations under this Stipulation, and the making of this Stipulation shall be without prejudice to any party in this or any other proceeding.

3. Once the requirements for compliance with 15 U.S.C. 16, as set forth in the Stipulation filed by the parties on November 6, 2001, have been satisfied, the United States will file with the Court a certificate of compliance and a Motion for Entry of Second Revised Proposed Final Judgment, unless it withdraws its consent to entry of the second revised proposed Final Judgment pursuant to paragraph 2, above. At any time thereafter, and at the conclusion of any further proceedings ordered by the Court pursuant to 15 U.S.C. 16(f), the Court may then enter the second revised proposed Final Judgment, provided that the Court determines that entry of the second revised proposed Final Judgment will serve the public interest.

Dated this 27th day of February, 2002.

For Plaintiff the United States of America:

Deborah P. Majoras,

Deputy Assistant Attorney General, Antitrust Division, United States Department of Justice, 901 Pennsylvania Avenue, NW., Washington, DC 20530,[phone].

For Plaintiffs the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin:

Jay L. Himes,

Chief, Antitrust Bureau, Office of the Attorney General of New York, 120 Broadway, New York, New York 10271, [phone].

For Defendant Microsoft Corporation:

Charles F. Rule,

Fried, Frank, Harris, Shriver Jacobson, 1001 Pennsylvania Avenue, NW., Suite 800, Washington, DC 20004, [phone].

Second Revised Proposed Final Judgment

WHEREAS, plaintiffs United States of America (“United States”) and the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin and defendant Microsoft Corporation (“Microsoft”), by their respective attorneys, have consented to the entry of this Final Judgment;

And whereas, this Final Judgment does not constitute any admission by any party regarding any issue of fact or law;

And whereas, Microsoft agrees to be bound by the provisions of this FinalJudgment pending its approval by the Court;

Now Therefore, upon remand from the United States Court of Appeals for the District of Columbia Circuit, and upon the consent of the aforementioned parties, it is hereby ordered, adjudged, and decreed:

I. Jurisdiction

This Court has jurisdiction of the subject matter of this action and of the person of Microsoft.

II. Applicability

This Final Judgment applies to Microsoft and to each of its officers, directors, agents, employees, subsidiaries, successors and assigns; and to all other persons in active concert or participation with any of them who shall have received actual notice of this Final Judgment by personal service or otherwise.

III. Prohibited Conduct

A. Microsoft shall not retaliate against an OEM by altering Microsoft's commercial relations with that OEM, or by withholding newly introduced forms of non-monetary Consideration (including but not limited to new versions of existing forms of non-monetary Consideration) from that OEM, because it is known to Microsoft that the OEM is or is contemplating:

1. developing, distributing, promoting, using, selling, or licensing any software that competes with Microsoft Platform Software or any product or service that distributes or promotes any Non-Microsoft Middleware;

2. shipping a Personal Computer that (a) includes both a Windows Operating System Product and a non-Microsoft Operating System, or (b) will boot with more than one Operating System; or

3. exercising any of the options or alternatives provided for under this Final Judgment.

Nothing in this provision shall prohibit Microsoft from enforcing any provision of any license with any OEM or any intellectual property right that is not inconsistent with this Final Judgment. Microsoft shall not terminate a Covered OEM's license for a Windows Operating System Product without having first given the Covered OEM written notice of the reasons for the proposed termination and not less than thirty days' opportunity to cure. Notwithstanding the foregoing, Microsoft shall have no obligation to provide such a termination notice and opportunity to cure to any Covered OEM that has received two or more such notices during the term of its Windows Operating System Product license.

Nothing in this provision shall prohibit Microsoft from providing Consideration to any OEM with respect to any Microsoft product or service where that Consideration is commensurate with the absolute level or amount of that OEM's development, distribution, promotion, or licensing of that Microsoft product or service.

B. Microsoft's provision of Windows Operating System Products to Covered OEMs shall be pursuant to uniform license agreements with uniform terms and conditions.

Without limiting the foregoing, Microsoft shall charge each Covered OEM the applicable royalty for Windows Operating System Products as set forth on a schedule, to be established by Microsoft and published on a Web site accessible to the Plaintiffs and all Covered OEMs, that provides for uniform royalties for Windows Operating System Products, except that:

1. the schedule may specify different royalties for different language versions;

2. the schedule may specify reasonable volume discounts based upon the actual volume of licenses of any Windows Operating System Product or any group of such products; and

3. the schedule may include market development allowances, programs, or other discounts in connection with Windows Operating System Products, provided that:

a. such discounts are offered and available uniformly to all Covered OEMs, except that Microsoft may establish one uniform discount schedule for the ten largest Covered OEMs and a second uniform discount schedule for the eleventh through twentieth largest Covered OEMs, where the size of the OEM is measured by volume of licenses;

b. such discounts are based on objective, verifiable criteria that shall be applied and enforced on a uniform basis for all Covered OEMs; and

c. such discounts or their award shall not be based on or impose any criterion or requirement that is otherwise inconsistent with any portion of this Final Judgment.

C. Microsoft shall not restrict by agreement any OEM licensee from exercising any of the following options or alternatives:

1. Installing, and displaying icons, shortcuts, or menu entries for, any Non-Microsoft Middleware or any product or service (including but not limited to IAP products or services) that distributes, uses, promotes, or supports any Non-Microsoft Middleware, on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed, except that Microsoft may restrict an OEM from displaying icons, shortcuts and menu entries for any product in any list of such icons, shortcuts, or menu entries specified in the Windows documentation as being limited to products that provide particular types of functionality, provided that the restrictions are non-discriminatory with respect to non-Microsoft and Microsoft products.

2. Distributing or promoting Non-Microsoft Middleware by installing and dis playing on the desktop shortcuts of any size or shape so long as such shortcuts do not impair the functionality of the user interface.

3. Launching automatically, at the conclusion of the initial boot sequence or subsequent boot sequences, or upon connections to or disconnections from the Internet, any Non-Microsoft Middleware if a Microsoft Middleware Product that provides similar functionality would otherwise be launched automatically at that time, provided that any such Non-Microsoft Middleware displays on the desktop no user interface or a user interface of similar size and shape to the user interface displayed by the corresponding Microsoft Middleware Product.

4. Offering users the option of launching other Operating Systems from the Basic Input/Output System or a non-Microsoft boot-loader or similar program that launches prior to the start of the Windows Operating System Product.

5. Presenting in the initial boot sequence its own IAP offer provided that the OEM complies with reasonable technical specifications established by Microsoft, including a requirement that the end user be returned to the initial boot sequence upon the conclusion of any such offer.

6. Exercising any of the options provided in Section III.H of this Final Judgment.

D. Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network (“MSDN”) or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. For purposes of this Section III.D, the term APIs means the interfaces, including any associatedcallback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner.

E. Starting nine months after the submission of this proposed Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of inter operating or communicating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (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.

F. 1. Microsoft shall not retaliate against any ISV or IHV because of that ISV's or IHV's:

a. developing, using, distributing, promoting or supporting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software, or

b. exercising any of the options or alternatives provided for under this Final Judgment.

2. Microsoft shall not enter into any agreement relating to a Windows Operating System Product that conditions the grant of any Consideration on an ISV's refraining from developing, using, distributing, or promoting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software, except that Microsoft may enter into agreements that place limitations on an ISV's development, use, distribution or promotion of any such software if those limitations are reasonably necessary to and of reasonable scope and duration in relation to a bona fide contractual obligation of the ISV to use, distribute or promote any Microsoft software or to develop software for, or in conjunction with, Microsoft.

3. Nothing in this section shall prohibit Microsoft from enforcing any provision of any agreement with any ISV or IHV, or any intellectual property right, that is not inconsistent with this Final Judgment.

G. Microsoft shall not enter into any agreement with:

1. any IAP, ICP, ISV, IHV or OEM that grants Consideration on the condition that such entity distributes, promotes, uses, or supports, exclusively or in a fixed percentage, any Microsoft Platform Software, except that Microsoft may enter into agreements in which such an entity agrees to distribute, promote, use or support Microsoft Platform Software in a fixed percentage whenever Microsoft in good faith obtains a representation that it is com mercially practicable for the entity to provide equal or greater distribution, promotion, use or support for software that competes with Microsoft Platform Software, or

2. any IAP or ICP that grants placement on the desktop or elsewhere in any Windows Operating System Product to that IAP or ICP on the condition that the IAP or ICP refrain from distributing, promoting or using any software that competes with Microsoft Middleware.

Nothing in this section shall prohibit Microsoft from entering into (a) any bona fide joint venture or (b) any joint development or joint services arrangement with any ISV, IHV, IAP, ICP, or OEM for a new product, technology or service, or any material value-add to an existing product, technology or service, in which both Microsoft and the ISV, IHV, IAP, ICP, or OEM contribute significant developer or other resources, that prohibits such entity from competing with the object of the joint venture or other arrangement for a reasonable period of time.

This Section does not apply to any agreements in which Microsoft licenses intellectual property in from a third party.

H. Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall:

1. Allow end users (via a mechanism readily accessible from the desktop or Start menu such as an Add/Remove icon) and OEMs (via standard preinstallation kits) to enable or remove access to each Microsoft Middleware Product or Non-Microsoft Middleware Product by (a) displaying or removing icons, shortcuts, or menu entries on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed, except that Microsoft may restrict the display of icons, shortcuts, or menu entries for any product in any list of such icons, shortcuts, or menu entries specified in the Windows documentation as being limited to products that provide particular types of functionality, provided that the restrictions are non-discriminatory with respect to non-Microsoft and Microsoft products; and (b) enabling or disabling automatic invocations pursuant to Section III.C.3 of this Final Judgment that are used to launch Non-Microsoft Middleware Products or Microsoft Middleware Products. The mechanism shall offer the end user a separate and unbiased choice with respect to enabling or removing access (as described in this subsection III.H.1) and altering default invocations (as described in the following subsection III.H.2) with regard to each such Microsoft Middle ware Product or Non-Microsoft Middleware Product and may offer the end-user a separate and unbiased choice of enabling or removing access and altering default configurations as to all Microsoft Middleware Products as a group or all Non-Microsoft Middleware Products as a group.

2. Allow end users (via an unbiased mechanism readily available from the desktop or Start menu), OEMs (via standard OEM preinstallation kits), and Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user in an unbiased manner) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa) in any case where the Windows Operating System Product would otherwise launch the Microsoft Middleware Product in a separate Top-Level Window and display either (i) all of the user interface elements or (ii) the Trademark of the Microsoft Middleware Product.

Notwithstanding the foregoing Section III.H.2, the Windows Operating System Product may invoke a Microsoft Middleware Product in any instance in which:

(a) that Microsoft Middleware Product would be invoked solely for use in interoperating with a server maintained by Microsoft (outside the context of general Web browsing), or

(b) that designated Non-Microsoft Middleware Product fails to implement a reasonable technical requirement (e.g., a requirement to be able to host a particular ActiveX control) that isnecessary for valid technical reasons to supply the end user with functionality consistent with a Windows Operating System Product, provided that the technical reasons are described in a reasonably prompt manner to any ISV that requests them.

3. Ensure that a Windows Operating System Product does not (a) automatically alter an OEM's configuration of icons, shortcuts or menu entries installed or displayed by the OEM pursuant to Section III.C of this Final Judgment without first seeking confirmation from the user and (b) seek such confirmation from the end user for an automatic (as opposed to user-initiated) alteration of the OEM's configuration until 14 days after the initial boot up of a new Personal Computer. Any such automatic alteration and confirmation shall be unbiased with respect to Microsoft Middleware Products and Non-Microsoft Middleware. Microsoft shall not alter the manner in which a Windows Operating System Product automatically alters an OEM's configuration of icons, shortcuts or menu entries other than in a new version of a Windows Operating System Product.

Microsoft's obligations under this Section III.H as to any new Windows Operating System Product shall be determined based on the Microsoft Middleware Products which exist seven months prior to the last beta test version (i.e., the one immediately preceding the first release candidate) of that Windows Operating System Product.

I. Microsoft shall offer to license to ISVs, IHVs, IAPs, ICPs, and OEMs any intellectual property rights owned or licensable by Microsoft that are required to exercise any of the options or alternatives expressly provided to them under this Final Judgment, provided that

1. all terms, including royalties or other payment of monetary consideration, are reasonable and non-discriminatory;

2. the scope of any such license (and the intellectual property rights licensed thereunder) need be no broader than is necessary to ensure that an ISV, IHV, IAP, ICP or OEM is able to exercise the options or alternatives expressly provided under this Final Judgment (e.g., an ISV's, IHV's, IAP's, ICP's and OEM's option to promote Non-Microsoft Middleware shall not confer any rights to any Microsoft intellectual property rights infringed by that Non-Microsoft Middleware);

3. an ISV's, IHV's, IAP's, ICP's, or OEM's rights may be conditioned on its not assigning, transferring or sublicensing its rights under any license granted under this provision; and

4. the terms of any license granted under this section are in all respects con sistent with the express terms of this Final Judgment.

Beyond the express terms of any license granted by Microsoft pursuant to this section, this Final Judgment does not, directly or by implication, estoppel or otherwise, confer any rights, licenses, covenants or immunities with regard to any Microsoft intellectual property to anyone.

J. No provision of this Final Judgment shall:

1. Require Microsoft to document, disclose or license to third parties: (a) portions of APIs or Documentation or portions or layers of Communications Protocols the disclosure of which would compromise the security of a particular installation or group of installations of anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems, including without limitation, keys, authorization tokens or enforcement criteria; or (b) any API, interface or other information related to any Microsoft product if lawfully directed not to do so by a governmental agency of competent jurisdiction.

2. Prevent Microsoft from conditioning any license of any API, Documentation or Communications Protocol related to anti-piracy systems, anti-virus technologies, license enforcement mechanisms, authentication/authorization security, or third party intellectual property protection mechanisms of any Microsoft product to any person or entity on the requirement that the licensee: (a) Has no history of software counterfeiting or piracy or willful violation of intellectual property rights, (b) has a reasonable business need for the API, Documentation or Communications Protocol for a planned or shipping product, (c) meets reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business, (d) agrees to submit, at its own expense, any computer program using such APIs, Documentation or Com munication Protocols to third-party verification, approved by Microsoft, to test for and ensure verification and compliance with Microsoft specifications for use of the API or interface, which specifications shall be related to proper operation and integrity of the systems and mechanisms identified in this paragraph.

IV. Compliance and Enforcement Procedures

A. Enforcement Authority

1. The Plaintiffs shall have exclusive responsibility for enforcing this Final Judgment. Without in any way limiting the sovereign enforcement authority of each of the plaintiff States, the plaintiff States shall form a committee to coordinate their enforcement of this Final Judgment. A plaintiff State shall take no action to enforce this Final Judgment without first consulting with the United States and with the plaintiff States' enforcement committee.

2. To determine and enforce compliance with this Final Judgment, duly authorized representatives of the United States and the plaintiff States, on reasonable notice to Microsoft and subject to any lawful privilege, shall be permitted the following:

a. Access during normal office hours to inspect any and all source code, books, ledgers, accounts, correspondence, memoranda and other documents and records in the possession, custody, or control of Microsoft, which may have counsel present, regarding any matters contained in this Final Judgment.

b. Subject to the reasonable convenience of Microsoft and without restraint or interference from it, to interview, informally or on the record, officers, employees, or agents of Microsoft, who may have counsel present, regarding any matters contained in this Final Judgment.

c. Upon written request of the United States or a duly designated representative of a plaintiff State, on reasonable notice given to Microsoft, Microsoft shall submit such written reports under oath as requested regarding any matters contained in this Final Judgment.

Individual plaintiff States will consult with the plaintiff States' enforcement committee to minimize the duplication and burden of the exercise of the foregoing powers, where practicable.

3. The Plaintiffs shall not disclose any information or documents obtained from Microsoft under this Final Judgment except for the purpose of securing compliance with this Final Judgment, in a legal proceeding to which one or more of the Plaintiffs is a party, or as otherwise required by law; provided that the relevant Plaintiff(s) must provide ten days' advance notice to Microsoft before disclosing in any legal proceeding (other than a grand jury proceeding) to which Microsoft is not a party any information or documents provided by Microsoft pursuant to this Final Judgment which Microsoft hasidentified in writing as material as to which a claim of protection may be asserted under Rule 26(c)(7) of the Federal Rules of Civil Procedure.

4. The Plaintiffs shall have the authority to seek such orders as are necessary from the Court to enforce this Final Judgment, provided, however, that the Plaintiffs shall afford Microsoft a reasonable opportunity to cure alleged violations of Sections III.C, III.D, III.E and III.H, provided further that any action by Microsoft to cure any such violation shall not be a defense to enforcement with respect to any knowing, willful or systematic violations.

B. Appointment of a Technical Committee

1. Within 30 days of entry of this Final Judgment, the parties shall create and recommend to the Court for its appointment a three-person Technical Committee (“TC”) to assist in enforcement of and compliance with this Final Judgment.

2. The TC members shall be experts in software design and programming. No TC member shall have a conflict of interest that could prevent him or her from performing his or her duties under this Final Judgment in a fair and unbiased manner. Without limitation to the foregoing, no TC member (absent the agreement of both parties):

a. shall have been employed in any capacity by Microsoft or any competitor to Microsoft within the past year, nor shall she or he be so employed during his or her term on the TC;

b. shall have been retained as a consulting or testifying expert by any person in this action or in any other action adverse to or on behalf of Microsoft; or

c. shall perform any other work for Microsoft or any competitor of Microsoft for two years after the expiration of the term of his or her service on the TC.

3. Within 7 days of entry of this Final Judgment, the Plaintiffs as a group and Microsoft shall each select one member of the TC, and those two members shall then select the third member. The selection and approval process shall proceed as follows.

a. As soon as practicable after submission of this Final Judgment to the Court, the Plaintiffs as a group and Microsoft shall each identify to the other the individual it proposes to select as its designee to the TC. The Plaintiffs and Microsoft shall not object to each other's selection on any ground other than failure to satisfy the requirements of Section IV.B.2 above. Any such objection shall be made within ten business days of the receipt of notification of selection.

b. The Plaintiffs shall apply to the Court for appointment of the persons selected by the Plaintiffs and Microsoft pursuant to Section IV.B.3.a above. Any objections to the eligibility of a selected person that the parties have failed to resolve between themselves shall be decided by the Court based solely on the requirements stated in Section IV.B.2 above.

c. As soon as practical after their appointment by the Court, the two members of the TC selected by the Plaintiffs and Microsoft (the “Standing Committee Members”) shall identify to the Plaintiffs and Microsoft the person that they in turn propose to select as the third member of the TC. The Plaintiffs and Microsoft shall not object to this selection on any grounds other than failure to satisfy the requirements of Section IV.B.2 above. Any such objection shall be made within ten business days of the receipt of notification of the selection and shall be served on the other party as well as on the Standing Committee Members.

d. The Plaintiffs shall apply to the Court for appointment of the person selected by the Standing Committee Members. If the Standing Committee Members cannot agree on a third member of the TC, the third member shall be appointed by the Court. Any objection by Microsoft or the Plaintiffs to the eligibility of the person selected by the Standing Committee Members which the parties have failed to resolve among themselves shall also be decided by the Court based on the requirements stated in Section IV.B.2 above.

4. Each TC member shall serve for an initial term of 30 months. At the end of a TC member's initial 30-month term, the party that originally selected him or her may, in its sole discretion, either request re-appointment by the Court to a second 30-month term or replace the TC member in the same manner as provided for in Section IV.B.3.a above. In the case of the third member of the TC, that member shall be re-appointed or replaced in the manner provided in Section IV.B.3.c above.

5. If the United States determines that a member of the TC has failed to act diligently and consistently with the purposes of this Final Judgment, or if a member of the TC resigns, or for any other reason ceases to serve in his or her capacity as a member of the TC, the person or persons that originally selected the TC member shall select a replacement member in the same manner as provided for in Section IV.B.3.

6. Promptly after appointment of the TC by the Court, the United States shall enter into a Technical Committee services agreement (“TC Services Agreement”) with each TC member that grants the rights, powers and authorities necessary to permit the TC to perform its duties under this Final Judgment. Microsoft shall indemnify each TC member and hold him or her harmless against any losses, claims, damages, liabilities or expenses arising out of, or in connection with, the performance of the TC's duties, except to the extent that such liabilities, losses, damages, claims, or expenses result from misfeasance, gross negligence, willful or wanton acts, or bad faith by the TC member. The TC Services Agreements shall include the following.

a. The TC members shall serve, without bond or other security, at the cost and expense of Microsoft on such terms and conditions as the Plaintiffs approve, including the payment of reasonable fees and expenses.

b. The TC Services Agreement shall provide that each member of the TC shall comply with the limitations provided for in Section IV.B.2 above.

7. Microsoft shall provide the TC with a permanent office, telephone, and other office support facilities at Microsoft's corporate campus in Redmond, Washington. Microsoft shall also, upon reasonable advance notice from the TC, provide the TC with reasonable access to available office space, telephone, and other office support facilities at any other Microsoft facility identified by the TC.

8. The TC shall have the following powers and duties:

a. The TC shall have the power and authority to monitor Microsoft's compliance with its obligations under this final judgment.

b. The TC may, on reasonable notice to Microsoft:

(i) interview, either informally or on the record, any Microsoft personnel, who may have counsel present; any such interview to be subject to the reasonable convenience of such personnel and without restraint or interference by Microsoft;

(ii) inspect and copy any document in the possession, custody or control of Microsoft personnel;

(iii) obtain reasonable access to any systems or equipment to which Microsoft personnel have access;

(iv) obtain access to, and inspect, any physical facility, building or other premises to which Microsoft personnel have access; and

(v) require Microsoft personnel to provide compilations of documents, data and other information, and tosubmit reports to the TC containing such material, in such form as the TC may reasonably direct.

c. The TC shall have access to Microsoft's source code, subject to the terms of Microsoft's standard source code Confidentiality Agreement, as approved by the Plaintiffs and to be agreed to by the TC members pursuant to Section IV.B.9 below, and by any staff or consultants who may have access to the source code. The TC may study, interrogate and interact with the source code in order to perform its functions and duties, including the handling of complaints and other inquiries from non-parties.

d. The TC shall receive complaints from the Compliance Officer, third parties or the Plaintiffs and handle them in the manner specified in Section IV.D below.

e. The TC shall report in writing to the Plaintiffs every six months until expiration of this Final Judgment the actions it has undertaken in performing its duties pursuant to this Final Judgment, including the identification of each business practice reviewed and any recommendations made by the TC.

f. Regardless of when reports are due, when the TC has reason to believe that there may have been a failure by Microsoft to comply with any term of this Final Judgment, the TC shall immediately notify the Plaintiffs in writing setting forth the relevant details.

g. TC members may communicate with non-parties about how their complaints or inquiries might be resolved with Microsoft, so long as the confidentiality of information obtained from Microsoft is maintained.

h. The TC may hire at the cost and expense of Microsoft, with prior notice to Microsoft and subject to approval by the Plaintiffs, such staff or consultants (all of whom must meet the qualifications of Section IV.B.2) as are reasonably necessary for the TC to carry out its duties and responsibilities under this Final Judgment. The compensation of any person retained by the TC shall be based on reasonable and customary terms commensurate with the individual's experience and responsibilities.

i. The TC shall account for all reasonable expenses incurred, including agreed upon fees for the TC members' services, subject to the approval of the Plaintiffs. Microsoft may, on application to the Court, object to the reasonableness of any such fees or other expenses. On any such application: (a) the burden shall be on Microsoft to demonstrate unreasonableness; and (b) the TC member(s) shall be entitled to recover all costs incurred on such application (including reasonable attorneys' fees and costs), regardless of the Court's disposition of such application, unless the Court shall expressly find that the TC's opposition to the application was without substantial justification.

9. Each TC member, and any consultants or staff hired by the TC, shall sign a confidentiality agreement prohibiting disclosure of any information obtained in the course of performing his or her duties as a member of the TC or as a person assisting the TC to anyone other than Microsoft, the Plaintiffs, or the Court. All information gathered by the TC in connection with this Final Judgment and any report and recommendations prepared by the TC shall be treated as Highly Confidential under the Protective Order in this case, and shall not be disclosed to any person other than Microsoft and the Plaintiffs except as allowed by the Protective Order entered in the Action or by further order of this Court.

10. No member of the TC shall make any public statements relating to the TC's activities.

C. Appointment of a Microsoft Internal Compliance Officer

1. Microsoft shall designate, within 30 days of entry of this Final Judgment, an internal Compliance Officer who shall be an employee of Microsoft with responsibility for administering Microsoft's antitrust compliance program and helping to ensure compliance with this Final Judgment.

2. The Compliance Officer shall supervise the review of Microsoft's activities to ensure that they comply with this Final Judgment. He or she may be assisted by other employees of Microsoft.

3. The Compliance Officer shall be responsible for performing the following activities:

a. within 30 days after entry of this Final Judgment, distributing a copy of the Final Judgment to all officers and directors of Microsoft;

b. promptly distributing a copy of this Final Judgment to any person who succeeds to a position described in Section IV.C.3.a above;

c. ensuring that those persons designated in Section IV.C.3.a above are annually briefed on the meaning and requirements of this Final Judgment and the U.S. antitrust laws and advising them that Microsoft's legal advisors are available to confer with them regarding any question concerning compliance with this Final Judgment or under the U.S. antitrust laws;

d. obtaining from each person designated in Section IV.C.3.a above an annual written certification that he or she: (i) has read and agrees to abide by the terms of this Final Judgment; and (ii) has been advised and understands that his or her failure to comply with this Final Judgment may result in a finding of contempt of court;

e. maintaining a record of all persons to whom a copy of this Final Judgment has been distributed and from whom the certification described in Section IV.C.3.d above has been obtained;

f. establishing and maintaining the website provided for in Section IV.D.3.b below.

g. receiving complaints from third parties, the TC and the Plaintiffs concerning Microsoft's compliance with this Final Judgment and following the appropriate procedures set forth in Section IV.D below; and

h. maintaining a record of all complaints received and action taken by Microsoft with respect to each such complaint.

D. Voluntary Dispute Resolution

1. Third parties may submit complaints concerning Microsoft's compliance with this Final Judgment to the Plaintiffs, the TC or the Compliance Officer.

2. In order to enhance the ability of the Plaintiffs to enforce compliance with this Final Judgment, and to advance the parties' joint interest and the public interest in prompt resolution of issues and disputes, the parties have agreed that the TC and the Compliance Officer shall have the following additional responsibilities.

3. Submissions to the Compliance Officer.

a. Third parties, the TC, or the Plaintiffs in their discretion may submit to the Compliance Officer any complaints concerning Microsoft's compliance with this Final Judgment. Without in any way limiting its authority to take any other action to enforce this Final Judgment, the Plaintiffs may submit complaints related to Sections III.C, III.D, III.E and III.H to the Compliance Officer whenever doing so would be consistent with the public interest.

b. To facilitate the communication of complaints and inquiries by third parties, the Compliance Officer shall place on Microsoft's Internet website, in a manner acceptable to the Plaintiffs, the procedures for submitting complaints. To encourage whenever possible the informal resolution of complaints and inquiries, the website shall provide a mechanism forcommunicating complaints and inquiries to the Compliance Officer.

c. Microsoft shall have 30 days after receiving a complaint to attempt to resolve it or reject it, and will then promptly advise the TC of the nature of the complaint and its disposition.

4. Submissions to the TC.

a. The Compliance Officer, third parties or the Plaintiffs in their discretion may submit to the TC any complaints concerning Microsoft's compliance with this Final Judgment.

b. The TC shall investigate complaints received and will consult with the Plaintiffs regarding its investigation. At least once during its investigation, and more often when it may help resolve complaints informally, the TC shall meet with the Compliance Officer to allow Microsoft to respond to the substance of the complaint and to determine whether the complaint can be resolved without further proceedings.

c. If the TC concludes that a complaint is meritorious, it shall advise Microsoft and the Plaintiffs of its conclusion and its proposal for cure.

d. No work product, findings or recommendations by the TC may be admitted in any enforcement proceeding before the Court for any purpose, and no member of the TC shall testify by deposition, in court or before any other tribunal regarding any matter related to this Final Judgment.

e. The TC may preserve the anonymity of any third party complainant where it deems it appropriate to do so upon the request of the Plaintiffs or the third party, or in its discretion.

V. Termination

A. Unless this Court grants an extension, this Final Judgment will expire on the fifth anniversary of the date it is entered by the Court.

B. In any enforcement proceeding in which the Court has found that Microsoft has engaged in a pattern of willful and systematic violations, the Plaintiffs may apply to the Court for a one-time extension of this Final Judgment of up to two years, together with such other relief as the Court may deem appropriate.

VI. Definitions

A. “API” means application programming interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.

B. “Communications Protocol” means the set of rules for information exchange to accomplish predefined tasks between a Windows Operating System Product and a server operating system product connected via a network, including, but not limited to, a local area network, a wide area network or the Internet. These rules govern the format, semantics, timing, sequencing, and error control of messages exchanged over a network.

C. “Consideration” means any monetary payment or the provision of preferential licensing terms; technical, marketing, and sales support; enabling programs; product information; information about future plans; developer support; hardware or software certification or approval; or permission to display trademarks, icons or logos.

D. “Covered OEMs” means the 20 OEMs with the highest worldwide volume of licenses of Windows Operating System Products reported to Microsoft in Microsoft's fiscal year preceding the effective date of the Final Judgment. The OEMs that fall within this definition of Covered OEMs shall be recomputed by Microsoft as soon as practicable after the close of each of Microsoft's fiscal years.

E. “Documentation” means all information regarding the identification and means of using APIs that a person of ordinary skill in the art requires to make effective use of those APIs. Such information shall be of the sort and to the level of specificity, precision and detail that Microsoft customarily provides for APIs it documents in the Microsoft Developer Network (“MSDN”).

F. “IAP” means an Internet access provider that provides consumers with a connection to the Internet, with or without its own proprietary content.

G. “ICP” means an Internet content provider that provides content to users of the Internet by maintaining Web sites.

H. “IHV” means an independent hardware vendor that develops hardware to be included in or used with a Personal Computer running a Windows Operating System Product.

I. “ISV” means an entity other than Microsoft that is engaged in the development or marketing of software products.

J. “Microsoft Middleware” means software code that:

1. Microsoft distributes separately from a Windows Operating 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 defined in section VI.K.1; and

3. provides the same or substantially similar functionality as a Microsoft Middleware Product.

Microsoft Middleware shall include at least the software code that controls most or all of the user interface elements of that Microsoft Middleware.

Software code described as part of, and distributed separately to update, a Microsoft Middleware Product shall not be deemed Microsoft Middleware unless identified as a new major version of that Microsoft Middleware Product. A major version shall be identified by a whole number or by a number with just a single digit to the right of the decimal point.

K. “Microsoft Middleware Product” means:

1. the functionality provided by Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express and their successors in a Windows Operating System Product, and

2. for any functionality that is first licensed, distributed or sold by Microsoft after the entry of this Final Judgment and that is part of any Windows Operating System Product:

a. Internet browsers, email client software, networked audio/video client software, instant messaging software or

b. functionality provided by Microsoft software that—

i. is, or in the year preceding the commercial release of any new Windows Operating System Product was, distributed separately by Microsoft (or by an entity acquired by Microsoft) from a Windows Operating System Product;

ii. is similar to the functionality provided by a Non-Microsoft Middleware Product; and

iii. is Trademarked.

Functionality that Microsoft describes or markets as being part of a Microsoft Middleware Product (such as a service pack, upgrade, or bug fix for Internet Explorer), or that is a version of a Microsoft Middleware Product (such as Internet Explorer 5.5), shall be considered to be part of that Microsoft Middleware Product.

L. “Microsoft Platform Software” means (i) a Windows Operating System Product and/or (ii) a Microsoft Middleware Product.

M. “Non-Microsoft Middleware” means a non-Microsoft software product running on a Windows Operating System Product that exposes a range of functionality to ISVs through published APIs, and that could, if ported to or made interoperable with, a non-Microsoft Operating System, thereby make it easier for applications that rely in whole or in part on the functionality supplied by that software product to be ported to or run on that non-Microsoft Operating System.

N. “Non-Microsoft Middleware Product” means a non-Microsoft software product running on a WindowsOperating System Product (i) that exposes a range of functionality to ISVs through published APIs, and that could, if ported to or made interoperable with, a non-Microsoft Operating System, thereby make it easier for applications that rely in whole or in part on the functionality supplied by that software product to be ported to or run on that non-Microsoft Operating System, and (ii) of which at least one million copies were distributed in the United States within the previous year.

O. “OEM” means an original equipment manufacturer of Personal Computers that is a licensee of a Windows Operating System Product.

P. “Operating System” means the software code that, inter alia, (i) controls the allocation and usage of hardware resources (such as the microprocessor and various peripheral devices) of a Personal Computer, (ii) provides a platform for developing applications by exposing functionality to ISVs through APIs, and (iii) supplies a user interface that enables users to access functionality of the operating system and in which they can run applications.

Q. “Personal Computer” means any computer configured so that its primary purpose is for use by one person at a time, that uses a video display and keyboard (whether or not that video display and keyboard is included) and that contains an Intel x86 compatible (or successor) microprocessor. Servers, television set top boxes, handheld computers, game consoles, telephones, pagers, and personal digital assistants are examples of products that are not Personal Computers within the meaning of this definition.

R. “Timely Manner” means at the time Microsoft first releases a beta test version of a Windows Operating System Product that is made available via an MSDN subscription offering or of which 150,000 or more beta copies are distributed.

S. “Top-Level Window” means a window displayed by a Windows Operating System Product that (a) has its own window controls, such as move, resize, close, minimize, and maximize, (b) can contain sub-windows, and (c) contains user interface elements under the control of at least one independent process.

T. “Trademarked” means distributed in commerce and identified as distributed by a name other than Microsoft® or Windows® that Microsoft has claimed as a trademark or service mark by (i) marking the name with trademark notices, such as ® or TM, in connection with a product distributed in the United States; (ii) filing an application for trademark protection for the name in the United States Patent and Trademark Office; or (iii) asserting the name as a trademark in the United States in a demand letter or lawsuit. Any product distributed under descriptive or generic terms or a name comprised of the Microsoft® or Windows® trademarks together with descriptive or generic terms shall not be Trademarked as that term is used in this Final Judgment. Microsoft hereby disclaims any trademark rights in such descriptive or generic terms apart from the Microsoft® or Windows® trademarks, and hereby abandons any such rights that it may acquire in the future.

U. “Windows Operating System Product” means the software code (as opposed to source code) distributed commercially by Microsoft for use with Personal Computers as Windows 2000 Professional, Windows XP Home, Windows XP Professional, and successors to the foregoing, including the Personal Computer versions of the products currently code named “Longhorn” and “Blackcomb” and their successors, including upgrades, bug fixes, service packs, etc. The software code that comprises a Windows Operating System Product shall be determined by Microsoft in its sole discretion.

VII. Further Elements

Jurisdiction is retained by this Court over this action and the parties thereto for the purpose of enabling either of the parties thereto to apply to this Court at any time for further orders and directions as may be necessary or appropriate to carry out or construe this Final Judgment, to modify or terminate any of its provisions, to enforce compliance, and to punish violations of its provisions.

VIII. Third Party Rights

Nothing in this Final Judgment is intended to confer upon any other persons any rights or remedies of any nature whatsoever hereunder or by reason of this Final Judgment.

United States Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment

In the United States District Court for the District of Columbia

United States of America, Plaintiff, v. Microsoft Corporation, Defendant;

United States' Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment

Next Court Deadline: March 6, 2002; Tunney Act Hearing.

Plaintiff United States of America submits the following memorandum regarding modifications to the Revised Proposed Final Judgment (“RPFJ”). These modifications are reflected in the new, Second Revised Proposed Final Judgment (“SRPFJ”), which is being filed concurrently with this memorandum,^[1] along with a new stipulation signed by representatives of the United States, the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin (collectively the “Settling States”) and Microsoft Corporation (“Microsoft”).^[2]

Introduction

On November 6, 2001, the United States, the Settling States and Microsoft submitted the RPFJ to the Court. Pursuant to §§ 16(b) and (d) of the Tunney Act, 15 U.S.C. §§ 16(b)-(h), the United States received public comments submitted on the RPFJ between November 5, 2001, and January 28, 2002.^[3] The United States received over 30,000 comments during that period, which it has reviewed and considered as required by 15 U.S.C. § 16(d). Concurrently with this Memorandum, the United States is filing the Response of the United States to Public Comments on the Revised Proposed Final Judgment and a Memorandum in Support of Entry of the Proposed Final Judgment. The United States will also file the public comments themselves (on CD-ROM only).

Discussion

The Tunney Act contemplates that the United States should evaluate the public comments that it receives and, if appropriate, consider modifications of the proposed consent decree in response to the issues raised by those comments. See 15 U.S.C. 16(b) and (d).^[4] On anumber of past occasions, the United States has modified proposed consent decrees as a result of public comments.^[5] In response to the Court's Order dated January 30, 2002,^[6] the parties reported in their Joint Status Report (“JSR”) filed February 7, 2002, that they were “considering whether, in response to the public comments, to submit to the Court proposed modifications to the RPFJ.” JSR at 7.

I. In Response to Public Comments, the Parties Have Agreed on Certain Modifications to the Terms of the RPFJ

Having fully reviewed and considered all public comments it received regarding the RPFJ, the United States proposed several modifications to the RPFJ. Microsoft and the Settling States have agreed to the modifications that are reflected in the SRPFJ. While the United States believes that the RPFJ as originally filed with the Court effectively remedied the violations sustained by the Court of Appeals and would be in the public interest, it believes that the modifications contained in the SRPFJ effectively respond to specific concerns raised in the public comments and that entry of the SRPFJ is in the public interest.

Each modification clarifies the language of the RPFJ in provisions about which public commentors have indicated concerns regarding the precise meaning of the language. Each modification is an outgrowth of specific concerns raised in the public comments and does not fundamentally change the RPFJ. With one exception,^[7] these modifications refine the language in the RPFJ, and are intended to clarify the parties' shared intentions in drafting the RPFJ. The following sections explain the modifications, as well as the rationale for making these refinements.

A. Section III.D and Definition VI.A—API

Section III.D. requires the disclosure of APIs (application programming interfaces) and other documentation for the purpose of ensuring interoperability between competing middleware and Windows Operating System Products. At least one commentor noted that in the RPFJ, the definition of API (Definition VI.A) includes only Microsoft APIs, thus rendering the other definitions that use the term API in the context of Non-Microsoft software potentially meaningless. Specifically, the definitions of Non-Microsoft Middleware, Non-Microsoft Middleware Product and Operating System arguably fail to function as intended if the definition of APIs is limited solely to Microsoft APIs. This definition of API, as originally drafted, was intended to apply only to Section III.D, but this limitation was not reflected in the text of the RPFJ. To correct this problem, the original definition of API has, in the SRPFJ, been inserted directly into Section III.D, so that Section III.D of the SRPFJ now reads:

Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network (“MSDN”) or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. For purposes of this Section III.D, the term APIs means the interfaces, including any associated callback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner. (New language in bold).

A generic definition of API that is not tied to Microsoft products has been inserted as Definition VI.A to apply throughout the SRPFJ except in Section III.D:

“API” means application programming interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.

The meaning of API in the definitions of Non-Microsoft Middleware, Non-Microsoft Middleware Product and Operating System is now defined, as intended, according to this generic definition, thereby resolving any potential concerns regarding their reliance on a definition of API that is specifically tied to Microsoft products. The modification does not change Microsoft's obligations under Section III.D.

B. Section III.E

Section III.E requires Microsoft to disclose all Communications Protocols that a Windows Operating System Product uses to interoperate natively with a Microsoft server operating system product. It ensures that non-Microsoft servers will be able to interoperate with a Windows Operating System Product using the same protocols the Microsoft server operating system product uses. Several commentors argued, however, that because the word “interoperate” in Section III.E is not defined, its meaning is unclear, potentially making it possible for Microsoft to evade this provision. The United States believes that, as interoperate is used in this Section III.E, its meaning clearly reflects the parties' intention that this provision presents the opportunity for seamless interoperability between Windows Operating System Products and non-Microsoft servers. Although the United States believes that the meaning of interoperate as included in Section III.E of the RPFJ is clear, in response to the public comments, the United States proposed, and Microsoft and the Settling States agreed, to supplement the term “interoperate” with “or communicate,” so that Section III.E of the SRPFJ now reads:

Starting nine months after the submission of this proposed Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of interoperating or communicating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (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. (New language in bold).

The addition of the phrase “or communicate” after “interoperate” brings further clarity to this provision. This revision clarifies the parties' intent in drafting Section III.E and thus removes any potential for confusion or ambiguity regarding the scope of theprovision based on the meaning of interoperate.

C. Section III.H.2

Section III.H.2 requires Microsoft to provide points in its Windows Operating System Products for automatically launching competing middleware, commonly referred to as default settings, in certain circumstances. Although Section III.H.1 states that Microsoft must give end users “a separate and unbiased choice” with respect to altering default invocations in Section III.H.2, there was a concern that the requirement that Microsoft implement Section III.H.2 in a wholly unbiased manner was not entirely clear. To clarify that Microsoft must be unbiased with respect to Microsoft and Non-Microsoft products under Section III.H.2, this provision was revised to expressly state that such mechanisms and confirmation messages must be unbiased. The revised language of Section III.H.2 in the SPRFJ provides:

Allow end users (via an unbiased mechanism readily available from the desktop or Start menu), OEMs (via standard OEM preinstallation kits), and Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user in an unbiased manner) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa) . . . (New language in bold).

This modification makes clear the parties' intention that the mechanism available to end users, as well as any confirmation messages to the end user, must be unbiased with respect to Microsoft and Non-Microsoft products.

This modification also addresses any concern that the phrase “at Microsoft's option” in Section III.H.2 could be read to allow Microsoft to take biased action against competing products. It also addresses concerns that Microsoft's presentation of the confirmation message could include derogatory comments about competing products.

In addition, the two exceptions (Sections III.H.2(a) and (b)) that previously followed Section III.H.3, but by their plain language modified III.H.2 (“Notwithstanding the foregoing Section III.H.2 . . .”), have been moved, so that they now follow Section III.H.2, and renumbered accordingly for clarification.

D. Section III.H.3

Section III.H.3 prohibits Microsoft from designing its Windows Operating System Products to alter automatically an OEM's configuration choices without seeking user confirmation and without waiting 14 days from the initial boot. In response to concerns raised regarding Microsoft's ability to change configurations pursuant to Section III.H.3, the following sentence has been added:

Any such automatic alteration and confirmation shall be unbiased with respect to Microsoft Middleware Products and Non-Microsoft Middleware.

This sentence clarifies the parties' intention in drafting the RPFJ that Microsoft may not alter a configuration based on whether the middleware products are Microsoft or Non-Microsoft products. Similarly, Microsoft may not present a biased confirmation message (such as a message that is derogatory with respect to Non-Microsoft products). Nor may automatic alterations take actions based on a trigger or rule that is biased against Non-Microsoft Middleware or in favor of Microsoft Middleware Products. This modification makes clear, as intended by the parties in the RPFJ, that any action taken under Section III.H.3 must therefore be independent of whether the affected products are Microsoft or Non-Microsoft products.

E. Section III.I.5

Several commentors raised concerns regarding Section III.I.5, under which an ISV, IHV, IAP, ICP, or OEM could be required to grant Microsoft a license, on reasonable and nondiscriminatory terms, to any intellectual property relating to that ISV's, IHV's, IAP's, ICP's or OEM's exercise of the options or alternatives provided by the RPFJ, if such a cross-license were necessary for Microsoft to provide the options or alternatives set forth in the RPFJ and exercised by the particular ISV, IHV, IAP, ICP or OEM. These concerns ranged from the general concern that the imposition of a cross-licensing requirement was inappropriate to more specific concerns, such as hypothesizing that the cross-licensing provision would reduce the likelihood that persons or entities would take advantage of the RPFJ's disclosure provisions.

As the United States pointed out in its CIS, Section III.I.5 was an extremely narrow provision designed to ensure that Microsoft would be able fully to comply with the terms of the RPFJ without creating greater indirect infringement liability for itself than it would otherwise have. See CIS at 50. In response to the concerns about this provision raised in the public comments, however, the United States proposed, and Microsoft and the Settling States agreed, that the provision should be deleted. Accordingly, Section III.I.5 does not appear in the SRPFJ. This modification does not alter Microsoft's existing obligations to comply fully with the terms of the SRPFJ.

F. Definition VI.J—Microsoft Middleware

Many commentors suggested that Definition VI.J, Microsoft Middleware, which required that software code be Trademarked, as that term is defined, could potentially exclude current products such as Internet Explorer, Windows Media Player, Microsoft's Java Virtual Machine, and Window Messenger because at least some such products, the commentors claimed, did not satisfy the definition of Trademarked. To clarify any issues surrounding the status of the software code associated with these products, the Microsoft Middleware definition has been modified to include explicitly the software code that is marketed by Microsoft as a major version of any of the named Microsoft Middleware Products listed in Section VI.K.1. With this change, software code can qualify as Microsoft Middleware in part by being either (1) Trademarked or (2) marketed as a major version of any of the named Microsoft Middleware Products (i.e., Internet Explorer, etc.), even if it does not satisfy the definition for Trademarked. The limitation to a major version of a Microsoft Middleware Product is simply a restatement of the limitation in the last paragraph of the Microsoft Middleware definition, which limits the covered software code to that identified as a major version of a Microsoft Middleware Product.

In addition, the previous subsection (4) now modifies the entire definition and has been revised to read:

Microsoft Middleware shall include at least the software code that controls most or all of the user interface elements of the Microsoft Middleware.

This change is intended to clarify that this provision of the definition is not a required element and therefore somehow intended to narrow or limit the definition; rather, the first three requirements are sufficient to define Microsoft Middleware. The purpose of this last provision is essentially to specify a minimum size or “floor” as to the collection of software code that is included in a particular piece of Microsoft Middleware, preventing the situation in which Microsoft could arbitrarily break up into separate pieces the software code of what would otherwise be Microsoft Middleware, thereby omitting from the MicrosoftMiddleware definition certain critical or significant pieces of code that constitute that Microsoft Middleware. This modification does not substantively change this definition but instead makes clear that this provision governs the scope of what code must be included in Microsoft Middleware.

B. Definition VI.R—Timely Manner

A number of commentors question Section VI.R's definition of Timely Manner, the term that defines when Microsoft must meet its disclosure obligations under Section III.D. Several commentors contend that 150,000 beta testers is too high a threshold to trigger Section III.D's disclosure requirement, arguing that for past Windows Operating System Products, Microsoft may have distributed 150,000 beta copies but may not have distributed them to 150,000 individual beta testers. These commentors are concerned that the threshold will never be reached, resulting in no required disclosure before a new Windows Operating System Product is released. Similarly, a number of commentors contend that Microsoft may in the future choose to distribute to fewer beta testers and thereby evade its disclosure obligations.

The parties' intention in drafting this definition was not to distinguish between beta copies and beta testers with respect to the 150,000 requirement. The parties originally chose the 150,000 beta tester distribution level based on the approximate current Microsoft Developer Network (“MSDN”) subscription base. In response to the foregoing concerns about the definition of Timely Manner, however, the United States proposed, and Microsoft and the Settling States agreed, to modify the definition to read:

Timely Manner” means at the time Microsoft first releases a beta test version of a Windows Operating System Product that is made available via an MSDN subscription offering or of which 150,000 or more beta copies are distributed.

This modification clarifies the parties' intention that Timely Manner should be triggered by the distribution of 150,000 or more beta copies, regardless of whether those copies are distributed to individuals who are considered to be “beta testers.” The modification adds a provision such that Timely Manner can also be triggered by distribution via an MSDN subscription offering. The inclusion of distribution via an MSDN subscription offering as a trigger for this definition ensures that, even in the event that the level of MSDN subscribers decreases substantially, Microsoft's disclosure obligations under Section III.D will still be triggered. Therefore, while this modification clarifies, and in fact may slightly broaden, Microsoft's disclosure obligations, it does not substantively differ from the original definition of Timely Manner in the RPFJ.

II. A New Round of Publication and Comment Is Not Warranted Because the Proposed Modifications Are a Logical Outgrowth of the RPFJ.

The foregoing modifications directly respond to concerns raised in the public comments and are the result of the United States' review and consideration, as part of its compliance with the Tunney Act, of the public comments submitted on the RPFJ. The Tunney Act does not require a new round of publication and comment as a result of the modifications contained in the SRPFJ. The publication and comment provisions of the Act serve “to enable the district court to make” its public interest determination. HyperLaw, Inc. v. United States, 1998 WL 388807, at *3, 159 F.3d 636 (D.C. Cir. 1998) (unpublished table decision). Accordingly, a “court should treat notice and comment under the Tunney Act as analogous to agency rulemaking notice and comment.” Id. (quotation marks omitted). Applying that analogy, “there is no need for successive rounds of notice and comment on each revision,” provided the final decree “is a “logical outgrowth” of the proposed consent decree. . . .. Further notice and comment should be required only if it “would provide the first opportunity for interested parties to offer comments that could persuade the agency to modify its [proposal].’”Id. (quoting Am. Water Works Ass'n v. EPA, 40 F.3d 1266, 1274 (D.C. Cir. 1994)).

The proposed decree as modified is a logical outgrowth of the RPFJ and requires no further notice and comment. As explained above, each modification responds to public comments on the RPFJ and clarifies language based upon those comments. Without question, each is a natural and logical outgrowth of the notice and comment process. Taken separately or together, the modifications do not fundamentally change the RPFJ. All contribute to benefitting the public interest (and certainly have no adverse effect on the public interest). The purpose of the notice and comment has thus been well-satisfied, and further notice and comment would merely delay the Court's public interest determination without good cause.^[8]

Conclusion

For the reasons described herein, the United States hereby submits the SRPFJ to the Court. In our separate Memorandum in Support of Entry of the Proposed Final Judgment and Response of the United States to Public Comments on the Revised Proposed Final Judgment, both of which are also being filed today, we set forth the reasons why the SRPFJ is in the public interest. Upon completion of the Tunney Act requirements, we will respectfully move the Court to enter the judgment.

Dated: February 27, 2002.

Respectfully submitted,

Charles A. James

Assistant Attorney General

Deborah P. Majoras

Deputy Assistant Attorney General

Phillip R. Malone

Renata B. Hesse

David Blake-Thomas

Paula L. Blizzard

Kenneth W. Gaul

Adam D. Hirsh

Jacqueline S. Kelley

Steven J. Mintz

Barbara Nelson

David Seidman

David P. Wales

Attorneys

U.S. Department of Justice, Antitrust Division, 601 D Street NW., Suite 1200, Washington, DC 20530, [phone].

Philip S. Beck,

Special Trial Counsel.

(Editorial Note: Certain conventions have been used by the Office of the Federal Register to highlight changes in the Second Revised Proposed Final Judgment. New language is shown in boldface, while language that was removed is set off with brackets.)

Exhibit A

Second Revised Proposed Final Judgment (Red-Lined Version)

Whereas, plaintiffs United States of America (“United States”) and the States of New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina and Wisconsin and defendant Microsoft Corporation (“Microsoft”), by their respective attorneys, have consented to the entry of this Final Judgment;

And whereas, this Final Judgment does not constitute any admission by any party regarding any issue of fact or law;

And whereas, Microsoft agrees to be bound by the provisions of this Final Judgment pending its approval by the Court;

Now therefore, upon remand from the United States Court of Appeals for the District of Columbia Circuit, and upon the consent of the aforementioned parties, it is hereby ordered, adjudged, and decreed:

I. Jurisdiction

This Court has jurisdiction of the subject matter of this action and of the person of Microsoft.

II. Applicability

This Final Judgment applies to Microsoft and to each of its officers, directors, agents, employees, subsidiaries, successors and assigns; and to all other persons in active concert or participation with any of them who shall have received actual notice of this Final Judgment by personal service or otherwise.

III. Prohibited Conduct

A. Microsoft shall not retaliate against an OEM by altering Microsoft's commercial relations with that OEM, or by withholding newly introduced forms of non-monetary Consideration (including but not limited to new versions of existing forms of non-monetary Consideration) from that OEM, because it is known to Microsoft that the OEM is or is contemplating:

1. developing, distributing, promoting, using, selling, or licensing any software that competes with Microsoft Platform Software or any product or service that distributes or promotes any Non-Microsoft Middleware;

2. shipping a Personal Computer that (a) includes both a Windows Operating System Product and a non-Microsoft Operating System, or (b) will boot with more than one Operating System; or

3. exercising any of the options or alternatives provided for under this Final Judgment.

Nothing in this provision shall prohibit Microsoft from enforcing any provision of any license with any OEM or any intellectual property right that is not inconsistent with this Final Judgment. Microsoft shall not terminate a Covered OEM's license for a Windows Operating System Product without having first given the Covered OEM written notice of the reasons for the proposed termination and not less than thirty days' opportunity to cure. Notwithstanding the foregoing, Microsoft shall have no obligation to provide such a termination notice and opportunity to cure to any Covered OEM that has received two or more such notices during the term of its Windows Operating System Product license.

Nothing in this provision shall prohibit Microsoft from providing Consideration to any OEM with respect to any Microsoft product or service where that Consideration is commensurate with the absolute level or amount of that OEM's development, distribution, promotion, or licensing of that Microsoft product or service.

B. Microsoft's provision of Windows Operating System Products to Covered OEMs shall be pursuant to uniform license agreements with uniform terms and conditions. Without limiting the foregoing, Microsoft shall charge each Covered OEM the applicable royalty for Windows Operating System Products as set forth on a schedule, to be established by Microsoft and published on a web site accessible to the Plaintiffs and all Covered OEMs, that provides for uniform royalties for Windows Operating System Products, except that:

1. the schedule may specify different royalties for different language versions;

2. the schedule may specify reasonable volume discounts based upon the actual volume of licenses of any Windows Operating System Product or any group of such products; and

3. the schedule may include market development allowances, programs, or other discounts in connection with Windows Operating System Products, provided that:

a. such discounts are offered and available uniformly to all Covered OEMs, except that Microsoft may establish one uniform discount schedule for the ten largest Covered OEMs and a second uniform discount schedule for the eleventh through twentieth largest Covered OEMs, where the size of the OEM is measured by volume of licenses;

b. such discounts are based on objective, verifiable criteria that shall be applied and enforced on a uniform basis for all Covered OEMs; and

c. such discounts or their award shall not be based on or impose any criterion or requirement that is otherwise inconsistent with any portion of this Final Judgment.

C. Microsoft shall not restrict by agreement any OEM licensee from exercising any of the following options or alternatives:

1. Installing, and displaying icons, shortcuts, or menu entries for, any Non-Microsoft Middleware or any product or service (including but not limited to IAP products or services) that distributes, uses, promotes, or supports any Non-Microsoft Middleware, on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed, except that Microsoft may restrict an OEM from displaying icons, shortcuts and menu entries for any product in any list of such icons, shortcuts, or menu entries specified in the Windows documentation as being limited to products that provide particular types of functionality, provided that the restrictions are non-discriminatory with respect to non-Microsoft and Microsoft products.

2. Distributing or promoting Non-Microsoft Middleware by installing and displaying on the desktop shortcuts of any size or shape so long as such shortcuts do not impair the functionality of the user interface.

3. Launching automatically, at the conclusion of the initial boot sequence or subsequent boot sequences, or upon connections to or disconnections from the Internet, any Non-Microsoft Middleware if a Microsoft Middleware Product that provides similar functionality would otherwise be launched automatically at that time, provided that any such Non-Microsoft Middleware displays on the desktop no user interface or a user interface of similar size and shape to the user interface displayed by the corresponding Microsoft Middleware Product.

4. Offering users the option of launching other Operating Systems from the Basic Input/Output System or a non-Microsoft boot-loader or similar program that launches prior to the start of the Windows Operating System Product.

5. Presenting in the initial boot sequence its own IAP offer provided that the OEM complies with reasonable technical specifications established by Microsoft, including a requirement that the end user be returned to the initial boot sequence upon the conclusion of any such offer.

6. Exercising any of the options provided in Section III.H of this Final Judgment.

D. Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network (“MSDN”) or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. For purposes of this Section III.D, the term APIs means the interfaces, including any associatedcallback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner.

E. Starting nine months after the submission of this proposed Final Judgment to the Court, Microsoft shall make available for use by third parties, for the sole purpose of interoperating or communicating with a Windows Operating System Product, on reasonable and non-discriminatory terms (consistent with Section III.I), any Communications Protocol that is, on or after the date this Final Judgment is submitted to the Court, (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.

F. 1. Microsoft shall not retaliate against any ISV or IHV because of that ISV's or IHV's:

a. developing, using, distributing, promoting or supporting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software, or

b. exercising any of the options or alternatives provided for under this Final Judgment.

2. Microsoft shall not enter into any agreement relating to a Windows Operating System Product that conditions the grant of any Consideration on an ISV's refraining from developing, using, distributing, or promoting any software that competes with Microsoft Platform Software or any software that runs on any software that competes with Microsoft Platform Software, except that Microsoft may enter into agreements that place limitations on an ISV's development, use, distribution or promotion of any such software if those limitations are reasonably necessary to and of reasonable scope and duration in relation to a bona fide contractual obligation of the ISV to use, distribute or promote any Microsoft software or to develop software for, or in conjunction with, Microsoft.

3. Nothing in this section shall prohibit Microsoft from enforcing any provision of any agreement with any ISV or IHV, or any intellectual property right, that is not inconsistent with this Final Judgment.

G. Microsoft shall not enter into any agreement with:

1. any IAP, ICP, ISV, IHV or OEM that grants Consideration on the condition that such entity distributes, promotes, uses, or supports, exclusively or in a fixed percentage, any Microsoft Platform Software, except that Microsoft may enter into agreements in which such an entity agrees to distribute, promote, use or support Microsoft Platform Software in a fixed percentage whenever Microsoft in good faith obtains a representation that it is commercially practicable for the entity to provide equal or greater distribution, promotion, use or support for software that competes with Microsoft Platform Software, or

2. any IAP or ICP that grants placement on the desktop or elsewhere in any Windows Operating System Product to that IAP or ICP on the condition that the IAP or ICP refrain from distributing, promoting or using any software that competes with Microsoft Middleware.

Nothing in this section shall prohibit Microsoft from entering into (a) any bona fide joint venture or (b) any joint development or joint services arrangement with any ISV, IHV, IAP, ICP, or OEM for a new product, technology or service, or any material value-add to an existing product, technology or service, in which both Microsoft and the ISV, IHV, IAP, ICP, or OEM contribute significant developer or other resources, that prohibits such entity from competing with the object of the joint venture or other arrangement for a reasonable period of time.

This Section does not apply to any agreements in which Microsoft licenses intellectual property in from a third party.

H. Starting at the earlier of the release of Service Pack 1 for Windows XP or 12 months after the submission of this Final Judgment to the Court, Microsoft shall:

1. Allow end users (via a mechanism readily accessible from the desktop or Start menu such as an Add/Remove icon) and OEMs (via standard preinstallation kits) to enable or remove access to each Microsoft Middleware Product or Non-Microsoft Middleware Product by (a) displaying or removing icons, shortcuts, or menu entries on the desktop or Start menu, or anywhere else in a Windows Operating System Product where a list of icons, shortcuts, or menu entries for applications are generally displayed, except that Microsoft may restrict the display of icons, shortcuts, or menu entries for any product in any list of such icons, shortcuts, or menu entries specified in the Windows documentation as being limited to products that provide particular types of functionality, provided that the restrictions are non-discriminatory with respect to non-Microsoft and Microsoft products; and (b) enabling or disabling automatic invocations pursuant to Section III.C.3 of this Final Judgment that are used to launch Non-Microsoft Middleware Products or Microsoft Middleware Products. The mechanism shall offer the end user a separate and unbiased choice with respect to enabling or removing access (as described in this subsection III.H.1) and altering default invocations (as described in the following subsection III.H.2) with regard to each such Microsoft Middleware Product or Non-Microsoft Middleware Product and may offer the end-user a separate and unbiased choice of enabling or removing access and altering default configurations as to all Microsoft Middleware Products as a group or all Non-Microsoft Middleware Products as a group.

2. Allow end users (via [a]an unbiased mechanism readily available from the desktop or Start menu), OEMs (via standard OEM preinstallation kits), and Non-Microsoft Middleware Products (via a mechanism which may, at Microsoft's option, require confirmation from the end user in an unbiased manner) to designate a Non-Microsoft Middleware Product to be invoked in place of that Microsoft Middleware Product (or vice versa) in any case where the Windows Operating System Product would otherwise launch the Microsoft Middleware Product in a separate Top-Level Window and display either (i) all of the user interface elements or (ii) the Trademark of the Microsoft Middleware Product.

Notwithstanding the foregoing Section III.H.2, the Windows Operating System Product may invoke a Microsoft Middleware Product in any instance in which:

(a) that Microsoft Middleware Product would be invoked solely for use in interoperating with a server maintained by Microsoft (outside the context of general Web browsing), or

(b) that designated Non-Microsoft Middleware Product fails to implement a reasonable technical requirement (e.g., a requirement to be able to host a particular ActiveX control) that isnecessary for valid technical reasons to supply the end user with functionality consistent with a Windows Operating System Product, provided that the technical reasons are described in a reasonably prompt manner to any ISV that requests them.

3. Ensure that a Windows Operating System Product does not (a) automatically alter an OEM's configuration of icons, shortcuts or menu entries installed or displayed by the OEM pursuant to Section III.C of this Final Judgment without first seeking confirmation from the user and (b) seek such confirmation from the end user for an automatic (as opposed to user-initiated) alteration of the OEM's configuration until 14 days after the initial boot up of a new Personal Computer. Any such automatic alteration and confirmation shall be unbiased with respect to Microsoft Middleware Products and Non-Microsoft Middleware. Microsoft shall not alter the manner in which a Windows Operating System Product automatically alters an OEM's configuration of icons, shortcuts or menu entries other than in a new version of a Windows Operating System Product.

[Notwithstanding the foregoing Section III.H.2, the Windows Operating System Product may invoke a Microsoft Middleware Product in any instance in which:

1. that Microsoft Middleware Product would be invoked solely for use in interoperating with a server maintained by Microsoft (outside the context of general Web browsing), or

2. that designated Non-Microsoft Middleware Product fails to implement a reasonable technical requirement (e.g., a requirement to be able to host a particular ActiveX control) that is necessary for valid technical reasons to supply the end user with functionality consistent with a Windows Operating System Product, provided that the technical reasons are described in a reasonably prompt manner to any ISV that requests them.]

Microsoft's obligations under this Section III.H as to any new Windows Operating System Product shall be determined based on the Microsoft Middleware Products which exist seven months prior to the last beta test version (i.e., the one immediately preceding the first release candidate) of that Windows Operating System Product.

I. Microsoft shall offer to license to ISVs, IHVs, IAPs, ICPs, and OEMs any intellectual property rights owned or licensable by Microsoft that are required to exercise any of the options or alternatives expressly provided to them under this Final Judgment, provided that

1. all terms, including royalties or other payment of monetary consideration, are reasonable and non-discriminatory;

2. the scope of any such license (and the intellectual property rights licensed thereunder) need be no broader than is necessary to ensure that an ISV, IHV, IAP, ICP or OEM is able to exercise the options or alternatives expressly provided under this Final Judgment (e.g., an ISV's, IHV's, IAP's, ICP's and OEM's option to promote Non-Microsoft Middleware shall not confer any rights to any Microsoft intellectual property rights infringed by that Non-Microsoft Middleware);

3. an ISV's, IHV's, IAP's, ICP's, or OEM's rights may be conditioned on its not assigning, transferring or sublicensing its rights under any license granted under this provision; and

4. the terms of any license granted under this section are in all respects con sistent with the express terms of this Final Judgment[; and.]

[5. an ISV, IHV, IAP, ICP, or OEM may be required to grant to Microsoft on reasonable and nondiscriminatory terms a license to any intellectual property rights it may have relating to the exercise of their options or alternatives provided by this Final Judgment; the scope of such license shall be no broader than is necessary to insure that Microsoft can provide such options or alternatives.]

Beyond the express terms of any license granted by Microsoft pursuant to this section, this Final Judgment does not, directly or by implication, estoppel or otherwise, confer any rights, licenses, covenants or immunities with regard to any Microsoft intellectual property to anyone.

J. No provision of this Final Judgment shall:

1. Require Microsoft to document, disclose or license to third parties: (a) portions of APIs or Documentation or portions or layers of Communications Protocols the disclosure of which would compromise the security of a particular installation or group of installations of anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems, including without limitation, keys, authorization tokens or enforcement criteria; or (b) any API, interface or other information related to any Microsoft product if lawfully directed not to do so by a governmental agency of competent jurisdiction.

2. Prevent Microsoft from conditioning any license of any API, Documentation or Communications Protocol related to anti-piracy systems, anti-virus technologies, license enforcement mechanisms, authentication/authorization security, or third party intellectual property protection mechanisms of any Microsoft product to any person or entity on the requirement that the licensee: (a) Has no history of software counterfeiting or piracy or willful violation of intellectual property rights, (b) has a reasonable business need for the API, Documentation or Communications Protocol for a planned or shipping product, (c) meets reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business, (d) agrees to submit, at its own expense, any computer program using such APIs, Documentation or Communication Protocols to third-party verification, approved by Microsoft, to test for and ensure verification and compliance with Microsoft specifications for use of the API or interface, which specifications shall be related to proper operation and integrity of the systems and mechanisms identified in this paragraph.

IV. Compliance and Enforcement Procedures

A. Enforcement Authority

1. The Plaintiffs shall have exclusive responsibility for enforcing this Final Judgment. Without in any way limiting the sovereign enforcement authority of each of the plaintiff States, the plaintiff States shall form a committee to coordinate their enforcement of this Final Judgment. A plaintiff State shall take no action to enforce this Final Judgment without first consulting with the United States and with the plaintiff States' enforcement committee.

2. To determine and enforce compliance with this Final Judgment, duly authorized representatives of the United States and the plaintiff States, on reasonable notice to Microsoft and subject to any lawful privilege, shall be permitted the following:

a. Access during normal office hours to inspect any and all source code, books, ledgers, accounts, correspondence, memoranda and other documents and records in the possession, custody, or control of Microsoft, which may have counsel present, regarding any matters contained in this Final Judgment.

b. Subject to the reasonable convenience of Microsoft and without restraint or interference from it, to interview, informally or on the record, officers, employees, or agents of Microsoft, who may have counselpresent, regarding any matters contained in this Final Judgment.

c. Upon written request of the United States or a duly designated representative of a plaintiff State, on reasonable notice given to Microsoft, Microsoft shall submit such written reports under oath as requested regarding any matters contained in this Final Judgment.

Individual plaintiff States will consult with the plaintiff States' enforcement committee to minimize the duplication and burden of the exercise of the foregoing powers, where practicable.

3. The Plaintiffs shall not disclose any information or documents obtained from Microsoft under this Final Judgment except for the purpose of securing compliance with this Final Judgment, in a legal proceeding to which one or more of the Plaintiffs is a party, or as otherwise required by law; provided that the relevant Plaintiff(s) must provide ten days' advance notice to Microsoft before disclosing in any legal proceeding (other than a grand jury proceeding) to which Microsoft is not a party any information or documents provided by Microsoft pursuant to this Final Judgment which Microsoft has identified in writing as material as to which a claim of protection may be asserted under Rule 26(c)(7) of the Federal Rules of Civil Procedure.

4. The Plaintiffs shall have the authority to seek such orders as are necessary from the Court to enforce this Final Judgment, provided, however, that the Plaintiffs shall afford Microsoft a reasonable opportunity to cure alleged violations of Sections III.C, III.D, III.E and III.H, provided further that any action by Microsoft to cure any such violation shall not be a defense to enforcement with respect to any knowing, willful or systematic violations.

B. Appointment of a Technical Committee

1. Within 30 days of entry of this Final Judgment, the parties shall create and recommend to the Court for its appointment a three-person Technical Committee (“TC”) to assist in enforcement of and compliance with this Final Judgment.

2. The TC members shall be experts in software design and programming. No TC member shall have a conflict of interest that could prevent him or her from performing his or her duties under this Final Judgment in a fair and unbiased manner. Without limitation to the foregoing, no TC member (absent the agreement of both parties):

a. shall have been employed in any capacity by Microsoft or any competitor to Microsoft within the past year, nor shall she or he be so employed during his or her term on the TC;

b. shall have been retained as a consulting or testifying expert by any person in this action or in any other action adverse to or on behalf of Microsoft; or

c. shall perform any other work for Microsoft or any competitor of Microsoft for two years after the expiration of the term of his or her service on the TC.

3. Within 7 days of entry of this Final Judgment, the Plaintiffs as a group and Microsoft shall each select one member of the TC, and those two members shall then select the third member. The selection and approval process shall proceed as follows.

a. As soon as practicable after submission of this Final Judgment to the Court, the Plaintiffs as a group and Microsoft shall each identify to the other the individual it proposes to select as its designee to the TC. The Plaintiffs and Microsoft shall not object to each other's selection on any ground other than failure to satisfy the requirements of Section IV.B.2 above. Any such objection shall be made within ten business days of the receipt of notification of selection.

b. The Plaintiffs shall apply to the Court for appointment of the persons selected by the Plaintiffs and Microsoft pursuant to Section IV.B.3.a above. Any objections to the eligibility of a selected person that the parties have failed to resolve between themselves shall be decided by the Court based solely on the requirements stated in Section IV.B.2 above.

c. As soon as practical after their appointment by the Court, the two members of the TC selected by the Plaintiffs and Microsoft (the “Standing Committee Members”) shall identify to the Plaintiffs and Microsoft the person that they in turn propose to select as the third member of the TC. The Plaintiffs and Microsoft shall not object to this selection on any grounds other than failure to satisfy the requirements of Section IV.B.2 above. Any such objection shall be made within ten business days of the receipt of notification of the selection and shall be served on the other party as well as on the Standing Committee Members.

d. The Plaintiffs shall apply to the Court for appointment of the person selected by the Standing Committee Members. If the Standing Committee Members cannot agree on a third member of the TC, the third member shall be appointed by the Court. Any objection by Microsoft or the Plaintiffs to the eligibility of the person selected by the Standing Committee Members which the parties have failed to resolve among themselves shall also be decided by the Court based on the requirements stated in Section IV.B.2 above.

4. Each TC member shall serve for an initial term of 30 months. At the end of a TC member's initial 30-month term, the party that originally selected him or her may, in its sole discretion, either request re-appointment by the Court to a second 30-month term or replace the TC member in the same manner as provided for in Section IV.B.3.a above. In the case of the third member of the TC, that member shall be re-appointed or replaced in the manner provided in Section IV.B.3.c above.

5. If the United States determines that a member of the TC has failed to act diligently and consistently with the purposes of this Final Judgment, or if a member of the TC resigns, or for any other reason ceases to serve in his or her capacity as a member of the TC, the person or persons that originally selected the TC member shall select a replacement member in the same manner as provided for in Section IV.B.3.

6. Promptly after appointment of the TC by the Court, the United States shall enter into a Technical Committee services agreement (“TC Services Agreement”) with each TC member that grants the rights, powers and authorities necessary to permit the TC to perform its duties under this Final Judgment. Microsoft shall indemnify each TC member and hold him or her harmless against any losses, claims, damages, liabilities or expenses arising out of, or in connection with, the performance of the TC's duties, except to the extent that such liabilities, losses, damages, claims, or expenses result from misfeasance, gross negligence, willful or wanton acts, or bad faith by the TC member. The TC Services Agreements shall include the following.

a. The TC members shall serve, without bond or other security, at the cost and expense of Microsoft on such terms and conditions as the Plaintiffs approve, including the payment of reasonable fees and expenses.

b. The TC Services Agreement shall provide that each member of the TC shall comply with the limitations provided for in Section IV.B.2 above.

7. Microsoft shall provide the TC with a permanent office, telephone, and other office support facilities at Microsoft's corporate campus in Redmond, Washington. Microsoft shall also, upon reasonable advance notice from the TC, provide the TC with reasonable access to available office space, telephone, and other office support facilities at anyother Microsoft facility identified by the TC.

8. The TC shall have the following powers and duties:

a. The TC shall have the power and authority to monitor Microsoft's compliance with its obligations under this final judgment.

b. The TC may, on reasonable notice to Microsoft:

(i) interview, either informally or on the record, any Microsoft personnel, who may have counsel present; any such interview to be subject to the reasonable convenience of such personnel and without restraint or interference by Microsoft;

(ii) inspect and copy any document in the possession, custody or control of Microsoft personnel;

(iii) obtain reasonable access to any systems or equipment to which Microsoft personnel have access;

(iv) obtain access to, and inspect, any physical facility, building or other premises to which Microsoft personnel have access; and

(v) require Microsoft personnel to provide compilations of documents, data and other information, and to submit reports to the TC containing such material, in such form as the TC may reasonably direct.

c. The TC shall have access to Microsoft's source code, subject to the terms of Microsoft's standard source code Confidentiality Agreement, as approved by the Plaintiffs and to be agreed to by the TC members pursuant to Section IV.B.9 below, and by any staff or consultants who may have access to the source code. The TC may study, interrogate and interact with the source code in order to perform its functions and duties, including the handling of complaints and other inquiries from non-parties.

d. The TC shall receive complaints from the Compliance Officer, third parties or the Plaintiffs and handle them in the manner specified in Section IV.D below.

e. The TC shall report in writing to the Plaintiffs every six months until expiration of this Final Judgment the actions it has undertaken in performing its duties pursuant to this Final Judgment, including the identification of each business practice reviewed and any recommendations made by the TC.

f. Regardless of when reports are due, when the TC has reason to believe that there may have been a failure by Microsoft to comply with any term of this Final Judgment, the TC shall immediately notify the Plaintiffs in writing setting forth the relevant details.

g. TC members may communicate with non-parties about how their complaints or inquiries might be resolved with Microsoft, so long as the confidentiality of information obtained from Microsoft is maintained.

h. The TC may hire at the cost and expense of Microsoft, with prior notice to Microsoft and subject to approval by the Plaintiffs, such staff or consultants (all of whom must meet the qualifications of Section IV.B.2) as are reasonably necessary for the TC to carry out its duties and responsibilities under this Final Judgment. The compensation of any person retained by the TC shall be based on reasonable and customary terms commensurate with the individual's experience and responsibilities.

i. The TC shall account for all reasonable expenses incurred, including agreed upon fees for the TC members' services, subject to the approval of the Plaintiffs. Microsoft may, on application to the Court, object to the reasonableness of any such fees or other expenses. On any such application: (a) the burden shall be on Microsoft to demonstrate unreasonableness; and (b) the TC member(s) shall be entitled to recover all costs incurred on such application (including reasonable attorneys' fees and costs), regardless of the Court's disposition of such application, unless the Court shall expressly find that the TC's opposition to the application was without substantial justification.

9. Each TC member, and any consultants or staff hired by the TC, shall sign a confidentiality agreement prohibiting disclosure of any information obtained in the course of performing his or her duties as a member of the TC or as a person assisting the TC to anyone other than Microsoft, the Plaintiffs, or the Court. All information gathered by the TC in connection with this Final Judgment and any report and recommendations prepared by the TC shall be treated as Highly Confidential under the Protective Order in this case, and shall not be disclosed to any person other than Microsoft and the Plaintiffs except as allowed by the Protective Order entered in the Action or by further order of this Court.

10. No member of the TC shall make any public statements relating to the TC's activities.

C. Appointment of a Microsoft Internal Compliance Officer

1. Microsoft shall designate, within 30 days of entry of this Final Judgment, an internal Compliance Officer who shall be an employee of Microsoft with responsibility for administering Microsoft's antitrust compliance program and helping to ensure compliance with this Final Judgment.

2. The Compliance Officer shall supervise the review of Microsoft's activities to ensure that they comply with this Final Judgment. He or she may be assisted by other employees of Microsoft.

3. The Compliance Officer shall be responsible for performing the following activities:

a. within 30 days after entry of this Final Judgment, distributing a copy of the Final Judgment to all officers and directors of Microsoft;

b. promptly distributing a copy of this Final Judgment to any person who succeeds to a position described in Section IV.C.3.a above;

c. ensuring that those persons designated in Section IV.C.3.a above are annually briefed on the meaning and requirements of this Final Judgment and the U.S. antitrust laws and advising them that Microsoft's legal advisors are available to confer with them regarding any question concerning compliance with this Final Judgment or under the U.S. antitrust laws;

d. obtaining from each person designated in Section IV.C.3.a above an annual written certification that he or she: (i) has read and agrees to abide by the terms of this Final Judgment; and (ii) has been advised and understands that his or her failure to comply with this Final Judgment may result in a finding of contempt of court;

e. maintaining a record of all persons to whom a copy of this Final Judgment has been distributed and from whom the certification described in Section IV.C.3.d above has been obtained;

f. establishing and maintaining the website provided for in Section IV.D.3.b below.

g. receiving complaints from third parties, the TC and the Plaintiffs concerning Microsoft's compliance with this Final Judgment and following the appropriate procedures set forth in Section IV.D below; and

h. maintaining a record of all complaints received and action taken by Microsoft with respect to each such complaint.

D. Voluntary Dispute Resolution

1. Third parties may submit complaints concerning Microsoft's compliance with this Final Judgment to the Plaintiffs, the TC or the Compliance Officer.

2. In order to enhance the ability of the Plaintiffs to enforce compliance with this Final Judgment, and to advance the parties' joint interest and the public interest in prompt resolution of issues and disputes, the parties haveagreed that the TC and the Compliance Officer shall have the following additional responsibilities.

3. Submissions to the Compliance Officer.

a. Third parties, the TC, or the Plaintiffs in their discretion may submit to the Compliance Officer any complaints concerning Microsoft's compliance with this Final Judgment. Without in any way limiting its authority to take any other action to enforce this Final Judgment, the Plaintiffs may submit complaints related to Sections III.C, III.D, III.E and III.H to the Compliance Officer whenever doing so would be consistent with the public interest.

b. To facilitate the communication of complaints and inquiries by third parties, the Compliance Officer shall place on Microsoft's Internet website, in a manner acceptable to the Plaintiffs, the procedures for submitting complaints. To encourage whenever possible the informal resolution of complaints and inquiries, the website shall provide a mechanism for communicating complaints and inquiries to the Compliance Officer.

c. Microsoft shall have 30 days after receiving a complaint to attempt to resolve it or reject it, and will then promptly advise the TC of the nature of the complaint and its disposition.

4. Submissions to the TC.

a. The Compliance Officer, third parties or the Plaintiffs in their discretion may submit to the TC any complaints concerning Microsoft's compliance with this Final Judgment.

b. The TC shall investigate complaints received and will consult with the Plaintiffs regarding its investigation. At least once during its investigation, and more often when it may help resolve complaints informally, the TC shall meet with the Compliance Officer to allow Microsoft to respond to the substance of the complaint and to determine whether the complaint can be resolved without further proceedings.

c. If the TC concludes that a complaint is meritorious, it shall advise Microsoft and the Plaintiffs of its conclusion and its proposal for cure.

d. No work product, findings or recommendations by the TC may be admitted in any enforcement proceeding before the Court for any purpose, and no member of the TC shall testify by deposition, in court or before any other tribunal regarding any matter related to this Final Judgment.

e. The TC may preserve the anonymity of any third party complainant where it deems it appropriate to do so upon the request of the Plaintiffs or the third party, or in its discretion.

V. Termination

A. Unless this Court grants an extension, this Final Judgment will expire on the fifth anniversary of the date it is entered by the Court.

B. In any enforcement proceeding in which the Court has found that Microsoft has engaged in a pattern of willful and systematic violations, the Plaintiffs may apply to the Court for a one-time extension of this Final Judgment of up to two years, together with such other relief as the Court may deem appropriate.

VI. Definitions

A. [“Application Programming Interfaces (APIs)”]“API” means [the interfaces]application programming interface, including any [associated callback interfaces,]interface that Microsoft [Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product]is obligated to disclose pursuant to III.D.

B. “Communications Protocol” means the set of rules for information exchange to accomplish predefined tasks between a Windows Operating System Product and a server operating system product connected via a network, including, but not limited to, a local area network, a wide area network or the Internet. These rules govern the format, semantics, timing, sequencing, and error control of messages exchanged over a network.

C. “Consideration” means any monetary payment or the provision of preferential licensing terms; technical, marketing, and sales support; enabling programs; product information; information about future plans; developer support; hardware or software certification or approval; or permission to display trademarks, icons or logos.

D. “Covered OEMs” means the 20 OEMs with the highest worldwide volume of licenses of Windows Operating System Products reported to Microsoft in Microsoft's fiscal year preceding the effective date of the Final Judgment. The OEMs that fall within this definition of Covered OEMs shall be recomputed by Microsoft as soon as practicable after the close of each of Microsoft's fiscal years.

E. “Documentation” means all information regarding the identification and means of using APIs that a person of ordinary skill in the art requires to make effective use of those APIs. Such information shall be of the sort and to the level of specificity, precision and detail that Microsoft customarily provides for APIs it documents in the Microsoft Developer Network (“MSDN”).

F. “IAP” means an Internet access provider that provides consumers with a connection to the Internet, with or without its own proprietary content.

G. “ICP” means an Internet content provider that provides content to users of the Internet by maintaining Web sites.

H. “IHV” means an independent hardware vendor that develops hardware to be included in or used with a Personal Computer running a Windows Operating System Product.

I. “ISV” means an entity other than Microsoft that is engaged in the development or marketing of software products.

J. “Microsoft Middleware” means software code that

1. Microsoft distributes separately from a Windows Operating 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 defined in section VI.K.1; and

3. provides the same or substantially similar functionality as a Microsoft Middleware Product; [and.]

[4. includes at least the software code that controls most or all of the user interface elements of that Microsoft Middleware.]

Microsoft Middleware shall include at least the software code that controls most or all of the user interface elements of that Microsoft Middleware.

Software code described as part of, and distributed separately to update, a Microsoft Middleware Product shall not be deemed Microsoft Middleware unless identified as a new major version of that Microsoft Middleware Product. A major version shall be identified by a whole number or by a number with just a single digit to the right of the decimal point.

K. “Microsoft Middleware Product” means

1. the functionality provided by Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express and their successors in a Windows Operating System Product, and

2. for any functionality that is first licensed, distributed or sold by Microsoft after the entry of this Final Judgment and that is part of any Windows Operating System Product

a. Internet browsers, email client software, networked audio/video client software, instant messaging software or

b. functionality provided by Microsoft software that—

i. is, or in the year preceding the commercial release of any new Windows Operating System Product was, distributed separately by Microsoft (or by an entity acquired by Microsoft) from a Windows Operating System Product;

ii. is similar to the functionality provided by a Non-Microsoft Middleware Product; and

iii. is Trademarked.

Functionality that Microsoft describes or markets as being part of a Microsoft Middleware Product (such as a service pack, upgrade, or bug fix for Internet Explorer), or that is a version of a Microsoft Middleware Product (such as Internet Explorer 5.5), shall be considered to be part of that Microsoft Middleware Product.

L. “Microsoft Platform Software” means (i) a Windows Operating System Product and/or (ii) a Microsoft Middleware Product.

M. “Non-Microsoft Middleware” means a non-Microsoft software product running on a Windows Operating System Product that exposes a range of functionality to ISVs through published APIs, and that could, if ported to or made interoperable with, a non-Microsoft Operating System, thereby make it easier for applications that rely in whole or in part on the functionality supplied by that software product to be ported to or run on that non-Microsoft Operating System.

N. “Non-Microsoft Middleware Product” means a non-Microsoft software product running on a Windows Operating System Product (i) that exposes a range of functionality to ISVs through published APIs, and that could, if ported to or made interoperable with, a non-Microsoft Operating System, thereby make it easier for applications that rely in whole or in part on the functionality supplied by that software product to be ported to or run on that non-Microsoft Operating System, and (ii) of which at least one million copies were distributed in the United States within the previous year.

O. “OEM” means an original equipment manufacturer of Personal Computers that is a licensee of a Windows Operating System Product.

P. “Operating System” means the software code that, inter alia, (i) controls the allocation and usage of hardware resources (such as the microprocessor and various peripheral devices) of a Personal Computer, (ii) provides a platform for developing applications by exposing functionality to ISVs through APIs, and (iii) supplies a user interface that enables users to access functionality of the operating system and in which they can run applications.

Q. “Personal Computer” means any computer configured so that its primary purpose is for use by one person at a time, that uses a video display and keyboard (whether or not that video display and keyboard is included) and that contains an Intel x86 compatible (or successor) microprocessor. Servers, television set top boxes, handheld computers, game consoles, telephones, pagers, and personal digital assistants are examples of products that are not Personal Computers within the meaning of this definition.

R. “Timely Manner” means at the time Microsoft first releases a beta test version of a Windows Operating System Product that is [distributed to]made available via an MSDN subscription offering or of which 150,000 or more beta [testers]copies are distributed.

S. “Top-Level Window” means a window displayed by a Windows Operating System Product that (a) has its own window controls, such as move, resize, close, minimize, and maximize, (b) can contain sub-windows, and (c) contains user interface elements under the control of at least one independent process.

T. “Trademarked” means distributed in commerce and identified as distributed by a name other than Microsoft® or Windows® that Microsoft has claimed as a trademark or service mark by (i) marking the name with trademark notices, such as ® or^TM, in connection with a product distributed in the United States; (ii) filing an application for trademark protection for the name in the United States Patent and Trademark Office; or (iii) asserting the name as a trademark in the United States in a demand letter or lawsuit. Any product distributed under descriptive or generic terms or a name comprised of the Microsoft® or Windows® trademarks together with descriptive or generic terms shall not be Trademarked as that term is used in this Final Judgment. Microsoft hereby disclaims any trademark rights in such descriptive or generic terms apart from the Microsoft® or Windows® trademarks, and hereby abandons any such rights that it may acquire in the future.

U. “Windows Operating System Product” means the software code (as opposed to source code) distributed commercially by Microsoft for use with Personal Computers as Windows 2000 Professional, Windows XP Home, Windows XP Professional, and successors to the foregoing, including the Personal Computer versions of the products currently code named “Longhorn” and “Blackcomb” and their successors, including upgrades, bug fixes, service packs, etc. The software code that comprises a Windows Operating System Product shall be determined by Microsoft in its sole discretion.

VII. Further Elements

Jurisdiction is retained by this Court over this action and the parties thereto for the purpose of enabling either of the parties thereto to apply to this Court at any time for further orders and directions as may be necessary or appropriate to carry out or construe this Final Judgment, to modify or terminate any of its provisions, to enforce compliance, and to punish violations of its provisions.

VIII. Third Party Rights

Nothing in this Final Judgment is intended to confer upon any other persons any rights or remedies of any nature whatsoever hereunder or by reason of this Final Judgment.

Dorothy Fountain,

Deputy Director of Operations.

Footnotes

1. One State later withdrew, and another settled in July 2001.

2. On February 1, 2002, this Court de-consolidated the cases. Order at 3 (Feb. 1, 2002).

3. At the time, Judge Posner was Chief Judge of the United States Court of Appeals for the Seventh Circuit.

4. Plaintiffs did not cross-appeal the dismissal of their Section 1 claim alleging exclusive dealing.

5. The Court of Appeals also rejected Microsoft's procedural challenges to the trail court proceedings, finding the district court's actions “comfortably within the bounds of its broad discretion to conduct trials as it sees fit.”Microsoft, 253 F.3d at 98, 100-01.

6. Indeed, the evidentiary hearing in New York v. Microsoft Corp., No. 98-CV-1233 (CKK) (D.D.C), between the Non-Settling States and Microsoft is scheduled to begin on March 11, 2002. (Order at 2 (Oct. 2, 2001).

7. New York, Ohio, Illinois, Kentucky, Louisiana, Maryland, Michigan, North Carolina, and Wisconsin (the “Settling States”)—each a party to New York v. Microsoft Corp., No. 98-Cv-1233 (CKK) (D.D.C.)—have signed the Revised Proposed Final Judgment.

8. The United States also filed, simultaneously with this Memorandum, a Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment. As explained briefly below, see Section II.G, page 34, the SRPFJ is a logical outgrowth of the RPFJ, its incremental modifications responding to the public comments, and the overall result further advances the public interest.

9. The United States has never before initiated a Tunney Act proceeding so late in a lawsuit although the settlement in the ATT case came after the trial court had “already heard what probably amounts to well over ninety percent of the parties's evidence.”United States v. ATT, 552 F. Supp. 131, 152 (D.D.C. 1982), aff'd mem. sub. nom. Maryland v. United States, 460 U.S. 1001 (1983). The ATT court followed Tunney Act procedures without deciding that the Tunney Act applied to what the parties characterized as the modification of a consent decree in one case and the dismissal of a different case. See id. at 144-45.

10. It has been suggested that the Tunney Act provision permitting a court to consider, as part of its public interest determination, “the public benefit, if any, to be derived from a determination of the issues at trial,” 15 U.S.C. 16(e)(2), limits the reach of the Act to pre-trial settlements. See Cal. Plaintiffs' Br. at 18. But that subsection demonstrates only that a consent decree may be proposed prior to trial, not that the Act is limited to pre-trial proposals. Indeed, in this case, the alternative to entry of the RPFJ likely would be trial of outstanding remedy issues. Pursuant to the statute, the Court may properly consider “the public benefit, if any” of requiring determination of those issues at trial.

11. The United States has consistently maintained that Tunney Act procedures are not required with respect to judgments addressing only claims for civil penalties under the antitrust laws. The antitrust laws do not provide civil penalties for violation of their substantive, competition-regulating, provisions. There are civil penalties under the “antitrust laws” as defined in the Clayton Act, see 15 U.S.C. 12(a) (defining “antitrust laws”), only for failure to comply with provisions relating to premerger notification and waiting periods, id. § 18a(g), and for violation of certain orders issued by certain federal agencies (not including the Department of Justice), id. 21(l). Courts in this district have consistently entered agreed upon settlements for civil penalties under 15 U.S.C. 18a(g) without employing Tunney Act procedures; each such entered judgment states that its entry is in the public interest. See, e.g., United States v. Input/Output, Inc., 1999-1 Trade Cas. (CCH) ¶ 72,528 (D.D.C. 1999); United States v. Blackstone Capital Partners II Merchant Banking Fund, 1999-1 Trade Cas. (CCH) ¶ 72,484 (D.D.C. 1999); United States v. Loewen Group Inc., 1998-1 Trade Cas. (CCH) ¶ 72,151 (D.D.C. 1998); United States v. Mahle GmbH, 1997-2 Trade Cas. (CCH ¶ 71,868 (D.D.C. 1997); United States v. Figgie Int'l Inc., 1997-1 Trade Cas. (CCH) ¶ 71,766 (D.D.C. 1997); United States v. Foodmaker, Inc., 1996-2 Trade Cas. (CCH) ¶ 71,555 (D.D.C. 1996); United States v. Titan Wheel Int'l, Inc., 1996-1 Trade Cas. (CCH) ¶ 71,406 (D.D.C. 1996); United States v. Automatic Data Processing, Inc., 1996-1 Trade Cas. (CCH) ¶ 71,361 (D.D.C. 1996); United States v. Trump, 1988-1 Trade Cas. (CCH) ¶ 67,968 (D.D.C. 1988). In each case, the United States noted the issue in a motion for entry of judgment, explaining to the court that it believed Tunney Act procedures were not required.

12. As enacted in 1914, the prima facie evidence provision made even clearer congressional understanding that there could be consent judgments or decrees entered after testimony had been taken. The text included this additional proviso, rendered superfluous by the passage of time: Provided further, This section shall not apply to consent judgments or decrees rendered in criminal proceedings or suits in equity, now pending, in which the taking of testimony has been commenced but has not been concluded, provided such judgments or decrees are rendered before any further testimony is taken.

Clayton Act, ch. 323, § 5, 38 Stat. 730, 731 (1914). This language not only clearly contemplates consent judgments or decrees entered after some testimony has been taken, but also gives prima facie evidence effect to some of them.

13. See also Utah Pub. Serv. Comm'n v. El Paso Natural Gas Co., 395 .S. 464, 467-68 (1969) (Supreme Court refers to a decree it had rejected (for failure to comply with its mandate) as a “consent decree” even though it had been agreed to following a trial on the merits and a Supreme Court determination of liability).

14. “[S]uppose that during the prosecution of a case against an oil company the government decided to settle for less relief than it could win on the merits because of the adverse impact full relief might have on a recently intervening energy crisis.” Consent Decree Bills: Hearings on H.R. 9203, H.R. 9947, and S. 782 Before the Subcomm. on Monopolies Commercial Law of the House Comm. on the Judiciary, 93rd Cong. 41 (1973) (“House Hearings”) (statement of Hon. Edward Hutchinson).

Similarly, Miles Kirkpatrick, who had recently stepped down as chairman of the FTC, testified at the same hearings about circumstances under which the government might file a proposed consent decree “with relief significantly different from that originally claimed.” These circumstances included “the post complaint realization by the Antitrust Division that there are certain aspects of its case that do not have the strengths that were initially believed to be present: that realization could come . . . after the partial trial of the case itself.”Id. at 145 (statement of Miles W. Kirkpatrick) (emphasis added.)

15. Although the United States has fully complied with each Tunney Act requirement, even substantial compliance that fulfills the purposes of the statute would suffice, for a court should “decline to read the . . .” statute as making strict technical compliance with the [Tunney Act] a condition to final entry of the decree.”United States v. Bechtel Corp., 648 F.2d 660, 664 (9th Cir. 1981).

16. “Any proposal for a consent judgment submitted by the United States for entry in any civil proceeding brought by or on behalf of the United States under the antitrust laws shall be filed with the district court before which such proceeding is pending and published by the United States in the Federal Register at least 60 days prior to the effective date of such judgment.” 15 U.S.C. 16(b).

“Simultaneously with the filing of such proposal, unless otherwise instructed by the court, the United States shall file with the district court, publish in the Federal Register, and thereafter furnish to any person upon request, a competitive impact statement.”Id.

17. Section 16(b) requires that the CIS “recite”:

(1) The nature and purpose of the proceeding;

(2) A description of the practices or events giving rise to the alleged violation of the antitrust laws;

(3) An explanation of the proposal for a consent judgment, including an explanation of any unusual circumstances giving rise to such proposal or any provision contained therein, relief to be obtained thereby, and the anticipated effects on competition of such relief;

(4) The remedies available to potential private plaintiffs damaged by the alleged violation in the event that such proposal for the consent judgment is entered in such proceeding;

(5) A description of the procedures available for modification of such proposal; and

(6) A description and evaluation of alternatives to such proposal actually considered by the United States.

15 U.S.C. 16(b).

18. See 15 U.S.C. 16(b) (materials “shall also be made available to the public at the district court and in such other districts as the court may subsequently direct”). This Court did not direct that any materials be made available at any other district court.

19. See supra note 18.

20. See supra note 16.

21. Section 16(c) provides:

The United States shall also cause to be published, commencing at least 60 days prior to the effective date of the judgment described in subsection (b) of this section, for 7 days over a period of 2 weeks in newspapers of general circulation of the district in which the case has been filed, in the District of Columbia, and in such other districts as the court may direct—

(i) A summary of the terms of the proposal for the consent judgment,

(ii) A summary of the competitive impact statement filed under subsection (b) of this section,

(iii) And a list of the materials and documents under subsection (b) of this section which the United States shall make available for purposes of meaningful public comment, and the place where such materials and documents are available for public inspection.

15 U.S.C. 16(c). The Court designated three newspapers, including one of general circulation in the District of Columbia. Nov. 8 Order at 2.

22. Section 16(d) provides:

During the 60-day period as specified in subsection (b) of this section, and such additional time as the United States may request and the court may grant, the United States shall receive and consider any written comments relating to the proposal for the consent judgment submitted under subsection (b) of this section. The Attorney General or his designee shall establish procedures to carry out the provisions of this subsection, but such 60-day time period shall not be shortened except by order of the district court upon a showing that (1) extraordinary circumstances require such shortening and (2) such shortening is not adverse to the public interest.

15 U.S.C. 16(d). The United States treated as Tunney Act comments various communications received between the first business day following submission of the initial Proposed Final Judgment to the Court and the beginning of the statutory comment period.

23. “Any written comments relating to such proposal and any responses by the United States thereto, shall also be filed with such district court and published by the United States in the Federal Register within such sixty-day period.” 15 U.S.C. 16(b).

“At the close of the period during which such comments may be received, the United States shall file with the district court and cause to be published in the Federal Register a response to such comments.” 15 U.S.C. 16(d).

24. Senator Tunney also noted that the need to file a CIS would help to focus the parties' attention during settlement negotiations. Tunney Remarks, 119 Cong. Rec. at 3452.

25. We attribute this success not only to the CIS itself, but also to the Internet's contribution to making the CIS, the RPFJ, the decisions of this Court and the Court of Appeals, and a wealth of other material readily available to the American public, far more available than mere publication in the Federal Register and distribution of paper copies by the United States and through this Court and other district courts would have accomplished. See ABA Section of Antitrust Law, Report to the Council of the Section of Antitrust Law Re: Proposed “Antitrust Procedures and Penalties Act,”reprinted in Senate Hearings at 427,431 (citing “the minimal attention which the average citizen devotes to the daily contents of the Federal Register”). The United States posted the RPFJ and the CIS on the Department of Justice website; they also were (and continue to be) available to PACER account holders at the Court's website; and they therefore are instantly available at any hour of day or night to anyone in the world with an Internet connection.

26. By contrast, the Department's 1994 consent decree with Microsoft generated only five public comments. See 59 FR 59,426, 59,427 (1994).

27. As previously noted, Joint Status Report at 3 (Feb. 7, 2002), over 1,000 comments were unrelated to this case or the RPFJ, nearly 3,000 are form letters, and nearly 20,000 contain an overall view of the RPFJ but no particularized discussion of it.

28. Considerably more detail can be found in the Findings of Fact, Conclusions of Law, and the Court of Appeals' opinion, all readily available on the Internet.

29. No Executive Order governs the content of a CIS, and the Tunney Act nowhere refers to cost/benefit analysis. We are also unaware of any requirement that a court, before imposing a remedy in a case litigated to final judgment or before entering a consent judgment, either itself perform such an analysis or insist that the parties do so.

30. For purposes of its public interest determination, the Court, of course, is not limited to the information in the CIS, but instead has available as well the trial record, the Court of Appeals' decision, the public comments, and the United States' response to public comments. And the Court can easily obtain additional information, whether by requesting it from the parties, or through the flexible procedures specified in the Tunney Act, see 15 U.S.C. 16(f).

31. The CIS does not address potential remedies available under state law or the laws of foreign countries. We do not believe that the Tunney Act plausibly can be read to require this. Indeed, requiring that the United States in effect provide legal advice regarding the laws of 50 states, let alone over a hundred foreign jurisdictions, would be unreasonably burdensome, take us far outside our area of expertise, and provide little or no benefit to anyone.

32. This point was raised, for example, in a lawsuit filed by one commentor, the American Antitrust Institute, American Antitrust Institute v. Microsoft Corp., No. 02-CV-0138 (CKK) (D.D.C., filed Jan. 24, 2002) (“AAI”), and in a Memorandum filed in this Court and attached to a filed comment, Comments of Relpromax Antitrust Inc., Ex. 11, at 3 (MTC # 00030631).

33. The United States did, however, discuss related issues recently. See Memorandum of Plaintiff United States in Response to the California Plaintiffs' Motion for Intervention, or in the Alternative, for Leave to File a Brief Amicus Curiae in the Tunney Act Settlement Proceedings Currently Pending in this Court, at 4-8 (Feb. 11, 2002).

34. As the CIS makes clear, CIS at 63, it does not describe literally every remedial proposal considered, no matter how fleetingly, and rejected. The statute does not impose such a requirement, which would be unduly burdensome and serve no useful purpose. As Senator Tunney said, the CIS ought to provide “some of the alternatives that were considered by the Department.” Senate Hearings at 108 (remarks of Sen. Tunney) (emphasis added).

35. The CIS does not document the evaluative process, as might be suitable in a technical report or an article prepared for publication in a scholarly journal of economics. Instead, the CIS reports the “result of evaluating,” Webster's Third International Dictionary 786 (1981) (defining “evaluation”), together with evaluative criteria.

36. Senator Hruska explained that “[t]hese anticipated effects quite clearly can be speculated upon by the district court considering a proposed consent judgment or by other interested parties.” 119 Cong. Rec. 24,604 (1973).

37. In the separate lawsuit it filed, a commentor relies on the concept of determinative documents applied in United States v. Central Contracting Co., 537 F. Supp. 571, 575 (E.D. Va. 1982), under which, even if documents are individually not determinative, they can be determinative “in the aggregate.” AAI Mem. at 17 n.10. We do not believe there are determinative documents in this case even under Central Contracting. But in any event, Central Contracting's broad definition of determinative documents has not been followed by any Tunney Act court, has been squarely repudiated by one district court, United States v. Alex. Brown Sons, 169 F.R.D. 532, 541 (S.D.N.Y. 1996) (“Central Contracting's broad definition of ‘determinative documents’ may conflict with Congress' intent to maintain the viability of consent decrees”) (cited with approval in MSL, 118 F.3d at 785), aff'd sub nom. United States v. Bleznak, 153 F.3d 16 (2d Cir. 1998), and cannot be reconciled with decisions of this Circuit and the Second Circuit. See MSL, 118 F.3d at 784; Bleznak, 153 F.3d at 20 (citing MSL and quoting “ ‘smoking gun’ or exculpatory opposite” with approval). Central Contracting is simply not good law in this regard.

38. The summary of the CIS included in the notice is brief, but sufficient to serve what we understand to be its purpose. The Senate Judiciary Committee added the newspaper provision to a bill that already included Federal Register publication of the CIS and proposed decree. Senate Report at 1-2 (Amendment No. 5). It did so “to enhance the degree of notice afforded the public,” since “[p]ublication in the Federal Register alone was not felt to be meaningful public notice.”Id. at 3. The notice in this case was plainly sufficient to put the public on notice of a proposed settlement of a major antitrust case potentially of interest; of the availability of additional information concerning that settlement; and of the opportunity to comment on the proposed judgment. Whatever else may be true of United States v. Microsoft, it is surely true that the proposed settlement has been amply noticed by the public at large.

39. See Alternative Publication Motion at 6 (descriptions of comments to be published and of a small category of wholly unrelated or duplicate comments that will not be published).

40. See supra note 15.

41. See Alternative Publication Motion at 2, 9-11; Supplemental at 2-3 n.1.

42. During approximately the first three to four weeks of this period before publication occurs, it would still be possible to terminate the remaining publication process and save a significant portion of the total cost of full publication.

43. Entry of a decree following modification without a new round of notice and comment is conventional in Tunney Act practice. For example, after notice and comment in ATT, the court said it would enter the decree as in the public interest if the parties agreed to a number of modifications, and the Court entered the modified decree without a new round of notice and comment. ATT, 552 F. Supp. at 225-26; see also MSL, 118 F.3d at 778.

44. The statute lists a number of factors a court “may consider,” 15 U.S.C. 16(e) (emphasis added); id. § 16(e)(1)-)2) (listing factors), but consideration of these factors is entirely discretionary. Senate Report at 6.

45. Nor may relief in a civil antitrust case be punitive. See United States v. E.I. du Pont de Nemours Co., 366 U.S. 316, 326 (1961); United States v. Oregon State Med. Soc'y, 343 U.S. 326, 333 (1952); United States v. Nat'l Lead Co., 332 U.S. 319, 338 (1947).

46. Congress intended that the statutory “public interest” concept encompass “compromises made for non-substantive reasons inherent in the process of settling cases through the consent decree procedure.” House Report at 12, 1974 U.S.C.C.A.N. at 6542.

47. Among the goals of an antitrust decree are “terminat[ing] the illegal monopoly” and “deny[ing] to the defendant the fruits of its statutory violation.”Microsoft, 253 F.3d at 103 (internal quotation omitted). But plaintiffs never alleged, and neither this Court nor the Court of Appeals found, that Microsoft acquired its monopoly unlawfully. See id. at 58 (Microsoft “violated § 2 by engaging in a variety of exclusionary acts . . . to maintain its monopoly”); see also Microsoft I, 56 F.3d at 1452. Thus, whether, and to what extent, Microsoft now has an “illegal monopoly” depends on whether its unlawful conduct increased or extended Microsoft's monopoly—that is, whether the fruits of its statutory violations included increments to the magnitude or duration of its market power. Again, neither the district court nor the Court of Appeals found this direct causal connection between the conduct and the continuance of the monopoly.

48. See Note, The Scope of Judicial Review of Consent Decrees under the Antitrust Procedures and Penalities Act of 1974, 82 Mich. L. Rev. 153, 175 n. 142 (1974) (“The legislative history of the [Tunney Act] should make the courts sensitive to the efficient allocation of the Department's resources in making their public interest determinations.”)

49. See, e.g., United States v. Paramount Pictures, Inc., 334 U.S. 131, 177 (1948); United States v. Borden Corp., 347 U.S. 514, 518 (1954); Bechtel, 648 F.2d at 666.

50. Some of the States that are plaintiffs in New York v. Microsoft Corp., No. 98-CV-1233, have settled with Microsoft on identical terms, while others have not settled and continue to litigate. We do not address here the nature of the task the Court now faces in New York.

51. More particularly, each party has conditionally abandoned the right to seek from the Court a remedy order to which the other has not agreed; each has abandoned the right to seek appellate review of the remedy order; and Microsoft has abandoned the right to seek Supreme Court review of the liability determinations and factual findings in this case (No. 98-1232) that were affirmed by the Court of Appeals. See United States v. Armour Co., 402 U.S. 673,681 (1971) (parties to a consent decree “waive their right to litigate the issues involved in the case”) These abandonments are conditional, because the United States has expressly reserved the right to withdraw its consent to the RPFJ prior to entry (Stipulation ¶1 (Nov. 6, 2001)), and the consent of both parties is contingent upon the Court's approval of the RPFJ (id.¶2).

52. In principle, the parties could have simply agreed between themselves on a purely contractual version of the RPFJ and terminated the litigation, without the Court's further action, by stipulation of dismissal, see Fed. R. Civ. P. 41(a)(1)(ii); Janus Films, 801 F.2d at 582; Michigan Note, 83 Mich. L. Rev. at 168n.98 (as an alternative to a consent decree, government could “settle the case by contract with the defendant”); see also In re IBM Corp., 687 F.2d 591, 600-03 (2d Cir. 1982) (Tunney Act does not apply to stipulations of dismissal). That alternative was unacceptable to the United States, which insisted, for various reasons including the availability of enforcement “by citation for contempt of court,” that the agreement carry “the legal force and character of a judgment entered after a trial.”Local No. 93, Int'l Ass'n of Firefighters v. City of Cleveland, 478 U.S. 501, 518 (1986); see Rufo v. Inmates of Suffolk County Jail, 502 U.S. 367, 378 (1992) (consent decree “is an agreement that the parties desire and expect will be reflected in, and be enforceable as, a judicial decree that is subject to the rules generally applicable to other judgments and decrees.”). Cf. United States v. United Artists Theatre Circuit, Inc., 1971 Trade Cas. (CCH) ¶73,751, at 91,183 (E.D.N.Y. 1971) (in case where government sought preliminary injunction, government advised the court “that it was its policy not to accept stipulations unless ‘So Ordered’ ”).

53. Cf. United States v. Microsoft Corp., 56 F.3d 1448, 1460 (D.C. Cir. 1995) (analogizing public interest determination to decision on decree modification, where “a court should not reject an agreed-upon modification unless ‘it has exceptional confidence that adverse antitrust consequences will result’ ”) (citation omitted).

54. For a response to commentors' claims of specific ambiguities, see Response of the United States To Public Comments on the Revised Proposed Final Judgment, passim, esp. § III (Definitions) (“Response”).

55. For a response to commentors' claims of specific shortcomings of the enforcement mechanisms of the RPFJ, see Response, § VIII (Enforcement); see also Declaration of David S. Sibley (“Sibley Decl.”) (attached as Appendix C).

56. For a fuller discussion of how the Court of Appeals addressed the twenty acts found by the district court to violate Section 2, see Appendix A (attached hereto), and Sibley Decl. ¶ 16 (Table One).

57. Of course, each Settling State also has authority to enforce the RPFJ.

58. For example, several commentors have urged that the RPFJ require Microsoft to distribute Sun-compatible Java products with each copy of the Windows operating system shipped by Microsoft. E.g., SILA Comments, at 49-51; Comments of SBC Communications, Inc. on the Proposed Final Judgment at 145 (MTC #00029411) (“SBC Comment”); ProComp Comment, Att. A, at 18-19 (Declaration of Kenneth J. Arrow) (“Arrow Decl.”). This remedy would go beyond restoring the competitive conditions existing prior to Microsoft's unlawful conduct—where Sun's Java product competed for space on Windows—and instead preordain the market outcome by ensuring Java placement on the operating system. See Sibley Decl. ¶ 80. As another example, a commentor proposes that Microsoft be required to offer, at a lower price, a separate, “stripped down” version of Windows that does not include Microsoft middleware products. SBC Comment, at 48-49. However, determining the appropriate discount for each of the middleware products stripped out of Windows, including an accounting for the shared costs between multiple projects, would result in a highly regulatory pricing apparatus susceptible to further litigation. See Sibley Decl. ¶¶ 71-74.

59. The various materials the Tunney Act does require, see 15 U.S.C. 16(b), together with any record created prior to settlement, will usually suffice. See United States v. Enova Corp., 107 F. Supp. 2d 10, 17 (D.D.C. 2000) (“Tunney Act expressly allows the court to make its public interest determination on the basis of the competitive impact statement and response to comments alone”); Senate Hearings at 152-53 (testimony of Hon. J. Skelly Wright) (“an experienced judge, who does have the facility of getting to the point and getting others to get to the point, can arrive at a public interest determination in most cases without using” additional tools); Senate Report at 6 (“[w]here the public interest can be meaningfully evaluated simply on the basis of briefs and oral arguments, that is the approach that should be utilized”). Even absent a settlement, no evidentiary hearing on relief is required where there are “no disputed factual issues regarding the matter of relief.”Microsoft, 253 F.3d at 101.

60. For example, commentor ProComp submitted a lengthy declaration from Professor Arrow, Arrow Decl., in opposition to the RPFJ, but fails to identify, in either its comments, ProComp Comment, or its filed memorandum, ProComp's Memorandum in Support of Its Motion for Limited Intervention or Tunney Act Participation (Feb. 7, 2002), anything specific that Professor Arrow would say at an evidentiary hearing beyond what already appears in his declaration. Cf. American Can Co. v. Mansukhani 814 F.2d 421, 425 (7th Cir. 1987) (defendants not entitled to a hearing on remedies because they failed “to explain to the district court what new proof they would present to show” that the proposed remedy was unwarranted).

61. Judge Greene also denied all motions to intervene prior to the court's public interest determination. ATT, 552 F. Supp. at 146 n.61.

62. Although Microsoft has agreed to be bound by much of the RPFJ pending its entry (Stipulation ¶ 2 (Nov. 6, 2001)), some important provisions become effective only after entry. See, e.g., RPFJ § IV.B (Technical Committee must be created “[w]ithin 30 days of entry of this Final Judgment”); id, § IV.C (Microsoft's internal compliance program begins “within 30 days of entry”).

63. Had the plaintiffs not embarked on this creative collaboration, it is highly unlikely that two cases against Microsoft would have gone forward, parallel but separate, with each reaching more or less the same result at more or less the same time.

1. Declarations of David S. Sibley, United States v. Microsoft Corp., Civ. Action No. 98-1232 (D.D.C. May 18, 1998) (hereinafter “May 1998 Sibley Decl.”). See also David S. Sibley, Michael J. Doane, and Ashish Nayyar (2001), “Economic Issues in U.S. v. Microsoft,” UWLA Law Review, Symposium: Cyber Rights, Protection, and Markets, 103-136.

2. My declaration does not address the compliance and enforcement procedures contained in the proposed remedy.

1. Revised Proposed Final Judgment, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. Nov. 6, 2001).

2. Second Revised Proposed Final Judgment, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. to be filed Feb. 27, 2002) (hereinafter “SRPFJ”); United States’ Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. to be filed Feb. 27, 2002).

3. Competitive Impact Statement, United States v. Microsoft Corp., Civ. Action No. 98-1232 (CKK) (D.D.C. No. 15, 2001) (hereinafter “CIS”).

4. See Findings of Fact, United States v. Microsoft Corp., 84 F. Supp.2d 9 (D.D.C. Nov. 5, 1999); Conclusions of Law, United States v. Microsoft Corp., 87 F. Supp.2d 30 (D.D.C. Apr. 3, 2000).

5. United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. June 28, 2001).

6. See United States Senate, Senate Committee on the Judiciary Documents for the December 12 Hearing on “The Microsoft Settlement: A Look to the Future”; Office of the Assistant Attorney General, United States Department of Justice, Response to written follow-up questions posed to Assistant Attorney General Charles James (Jan. 24, 2002).

7. See Office of the Assistant Attorney General, United States Department of Justice, Response to Senator Hatch's letter of November 29, 2001 (Dec. 11, 2001).

8. United States v. Microsft Corp., 253 F.3d 34, 79 (D.C. Cir. June 28, 2001).

9. Increasing returns to consumption is often discussed as an important consequence of network effects. First formalized by Rohlfs, there is a network effect whenever the value to existing users of a network increases as the network expands with new users. See Jeffrey H. Rohlfs (1974), “A Theory of Interdependent Demands for Communications Service,” 5 Bell Journal of Economics and Management Science 16-37. See also Michael Katz and Carl Shapiro (1985), “Network Externalities, Competition and Compatibility,” 75 American Economic Review 424-440; Michael Katz and Carl Shapiro (1986), “Technology Adoption in the Presence of Network Externalities,” 94 Journal of Political Economic 822-841.

10. See. e.g., Joseph Farrell and Garth Saloner (1986), “Installed Base and Compatibility: Innovation, Product Differentiation, and Predation,” 76 American Economic Review 940-955: Joseph Farrell and Garth Saloner (1985), “Standardization, Compatibility, and Innovation,” 16 Rand Journal of Economics 70-83.

11. In my May 1998 Declaration, I argued that the application barrier to entry occurs naturally in certain software markets and is not, by itself, a source of antitrust concern. By contrast, I stated “[t]he bundling and other contractual browser restrictions that Microsoft insists upon in its agreements with OEMs, IAPs, and ICPs add artificial entry barriers to those that occur naturally, and are therefore a source of competitive concern.”See 1998 Sibley Decl. at ¶ 19.

12. Government Exhibit No. 1.

13. See May 1998 Sibley Decl. at ¶¶ 18-19, 30, and 49-50.

14. Government Exhibit No. 20, Email from Bill Gates to the Microsoft Executive Staff and Direct Reports (May 26, 1995).

15. The appellate court reversed both the attempted monopolization and tying claims (remanding the tying claim for further hearing under the rule of reason standard) and vacated the Final Judgment that called for a structural remedy and interim conduct remedies.

16. United States v. Microsoft Corp., 253 F.3d 34, 6 (D.C. Cir. June 28, 2001).

17. See, e.g., May 1998 Sibley Decl. at ¶¶ 18-19.

18. Rent seeking involves the use of real resources to obtain favorable treatment or rules.

19. The size and shape of an icon is fixed and cannot be changed by the OEM or Microsoft Section III.C.2 prohibits Microsoft from restricting the OEM's selection of the size and shape of shortcuts, including shortcuts placed on the desktop.

20. The term “Non-Microsoft Middleware Product” is used only in Section III.H of the SRPFJ, and my use of the term applies only in reference to that section of the proposed decree. Elsewhere, I use the term “rival middleware.”

21. The term “Timely Manner,” which governs the release date of APIs pursuant to Section III.D, means the time Microsoft first releases a beta version of a Windows Operating System Product, either through the MSDN or with a distribution of 150,000 or more copies.

22. See May 1998 Sibley Decl. at ¶ 19.

23. It is worth noting that, even in 1995, within one year of the introduction of the Mosaic browser (the first browser with a graphical user interface) there were some two million users. See Gina Smith, “Inside Silcon Valley: A High Tech Top 10 Computers Technology,”San Francisco Chronicle (Jan. 1, 1995).

24. See Timothy F. Brensnahan, “A Remedy that Falls Short of Restoring Competition” ANTITRUST, at 69 (Fall 2001) (hereinafter “Bresnahan Article”).

25. See Comments of RealNetworks at 14.

26. See definition VI.R in the SRPFJ.

27. See, e.g., Bresnahan Article at 68; and Henderson Comment at 3 and 5-6.

28. See e.g., Bresnahan Article at 69.

29. See generally Stiglitz and Furman Decl.; Comment of Robert E. Litan, Roger D. Noll, and William D. Nordhaus on the Revised Proposed Final Judgment (hereinafter “Litan et al.”) Arrow Decl.; and Bresnahan Article.

30. See, e.g., Arrow Decl. at ¶ 26.

31. Arrow asserts that permitting OEMs to remove Microsoft Middleware icons but not the underlying code would further undermine OEM incentives to carry Non-Microsoft Middleware. (See Arrow Decl. at ¶ 37.) Litan et al. at 44 claim that permitted commingling of code will be fatal to the proposed decree by ensuring universal distribution of Microsoft Middleware code, which when compared to partial distibution of Non-Microsoft Middleware code will encourage continued enhancement of the applications barrier to entry.

32. See, e.g., William J. Baumol, Michael F. Koehn, and Robert D. Willing (1987), “How Arbitrary is ‘Arbitary’?—or Toward the Deserved Demise of Full Cost Allocation,” 120 Public Utilities Fortnightly 16-21.

33. Dell systems shipped with CD-RW capability come with Roxio Easy CD Creator, a CD burner software product. A recent article in Computer Shopper addresses Windows XP's CD mastering capabilities. See Computer Shopper, Feb. 2002, at 131. Another article—“Windows XP Tip: My Pictures Folder,” TechTV, Oct. 26, 2001—reviews the photo managing capabilities Microsoft has bundled into XP. Microsoft also has a separate product, Microsoft Picture It 2002, that provides special effect and other enhanced photo management capabilities.

34. Perhaps a more significant example is RealNetworks' RealOne media player product, comprising RealPlayer and RealJukebox, currently packaged by the OEM Sony in a Windows XP Home Edition Vaio Notebook system sold in the retail channel. In December 2001, it was also announced that Compaq will begin shipping these RealNetworks products as default media players in Presario desktop and notebook models designed for consumers. By mid-2002, compaq will be offering the newest RealOne Player, with a RealOne icon on the desktop and memberships to the RealOne subscription services. See EDP's Weekly It Monitor, Dec. 24, 2001. As discussed elsewhere, Windows XP bundles a similar media player product (Windows Media Player) in the operating system, and yet these OEMs provide the Non-Microsoft Middleware product as well.

35. The Wall Street Journal reported (on Sep. 24, 2001) August 2001 usage figures: “28.8 million users accessed multimedia files on the Web in the RealNetworks format and 13 million did the same in Microsoft's format” (based on Internet measurement firm Netratings Inc. figures).

36. Ibid.

37. In light of the findings in this case overall and of the Court of Appeal's condemnation of Microsoft's conduct toward Apple regarding Office in particular, it is hard to imagine Microsoft attempting the use of the “club” again, let alone a party that would permit it without threats of litigation and complaints to regulators.

38. See Stephen Shankland, Linux Growth Underscores Threat to Microsoft, CNET News.com (Feb. 28, 2001); Information Week, p. 86 (Apr. 21, 1997) (citing 1996 shares as reported by International Data Corp.).

39. Steven Brody, IDC Says Linux Likely to Lead OS Growth, SunWorld (Mar. 31, 1999), reproduced at http://www.linuxworld.com/​linuxworld/​lw-1999-03/​lw-03-idc.html.

40. See Elise Ackerman, Despite a Tough Road, Linux Has Never Been More Popular, San Jose Mercury News (Nov. 25, 2001); Peter Galli, Battle Brews Over Linux Server Share, EWEEK (June 10, 2001), reproduced at http://zdnet.com.com/​2102-11-503810.html (citing also Gartner Dataquest estimates of Linux as having a share of server shipments of 6 to 8.6 percent share in third quarter 2000).

41. Litan et al. at 25.

42. Computerworld (Feb. 26, 2001). See also Stephen Shankland, Linux Sales Surge Past Competitors, CNET News.com (Feb. 9, 2000).

43. According to Gartner figures, worldwide market share for Windows CE has been between 20 percent and 25 percent over the last four years, with no significant trend. See Final 1998 Handheld Computer Market Results, Gartner Dataquest (May 17, 1999); Gartner Dataquest's Worldwide PDA Forecast, Gartner Dataquest (Dec. 11, 2000); and Handheld Computer Shipments Rebound in 4Q01, Gartner Dataquest Alert (Feb. 15, 2002). While Microsoft is expected to improve this position subsequent to the introduction of Pocket PC 2002 in October 2001, Gartner continues to project Windows CE share at no more than 30 percent for 2002. See Microsoft Aims to Dominate With Pocket PC 2002, Gartner Dataquest (Sep. 10, 2001).

1. The United States also filed, simultaneously with this Response, a Memorandum Regarding Modifications Contained in Second Revised Proposed Final Judgment. The SRPFJ is a logical growth of the RPFJ, its incremental modifications responding to public comments, and the overall result further advances the public interest.

2. A full description of the history of this litigation—both procedural and substantive—can be found in Memorandum Of the United States in Support Of Entry Of the Revised Proposed Final Judgment 1-11 (filed Feb. 27, 2002) (“U.S. Memorandum”).

3. In addition, nine State plaintiffs (the “Settling States”) from New York v. Microsoft Corp., No. 98-CV-1233 (D.D.C.) (CKK) (“New York”), agreed to settle their dispute with Microsoft under RPFJ. Ten other plaintiffs from New York (the “Litigating States”) did not agree to the terms of the RPFJ and are continuing their suit in a separate proceeding.

4. The United States also chose to accept and treat as Tunney Act comments various communications from members of the public commenting on the proposed settlement that were received by the Department of Justice beginning on November 5, 2001, the first business day following submission of the initial Proposed Final Judgment to the Court, even though the official 60-day comment period had not yet begun. See 15 U.S.C. 16(b) (60-day period begins upon publication in the Federal Register.)

5. By contrast, the United States' 1994 consent decree with Microsoft generated only five public comments. See 59 FR 59,426, 59,427-29 (1994).

6. See, e.g., http://www.salon.com/​tech/​col/​rose/​2002/​01/​16/​competitor/​index/​html.

7. Porcher. The Response generally uses abbreviations to identify commentors. An index of comments cited, along with unique identifying numbers, is found in Appendix A to this Response.

8. Reid; Karkess.

9. Becker; Gallagher.

10. Daly; Love.

11. The United States provided copies of these detailed comments to the Court on February 14, 2002, and posted copies of these comments on the Department of Justice website on February 15, 2002. These comments may be found at http://www.usdoj.gov/​atr/​cases/​msmajor.htm

12. Thus, unless otherwise noted, citations to specific comments merely are representative of comments on that issue, and should not be interpreted as an indication that other comments were not reviewed.

13. CMDC 1-11; Skinn 1; Wagstaff 1; Lloyd 1; Peterson 1; Bode 1; Poindexter 1; Williams 1.

14. Relpromax 3-4, 18, 20-22, Ex. 10; CCIA 18-34 Decl. Edward Roeder; ProComp 78-86.

15. Commentors also allege that Microsoft has failed adequately to disclose lobbying contacts as required by the Tunney Act, 15 U.S.C. § 16(g). Pursuant to the Court's Order dated February 13, 2002, Microsoft will respond to allegations of deficiencies in its compliance with § 16(g).

16. See, e.g., United States v. Haldeman, 559 F.2d 31, 134 (D.C. Cir. 1976); In re United States, 666 F.2d 690, 695 (1st Circ. 1981) (a judge should ignore “rumors, innuendos, and erroneous information published as fact in the newspapers”); McClelland v. Gronwaldt, 942 F. Supp. 297 (E.D. Tex. 1996).

17. Lobbying activities by the defendant, even though “intensive and gross,” are insufficient to establish corruption on the part of the United States. See, e.g., United States v. Associated Milk Producers, 394 F. Supp. 29, 39-40 (W.D. Mo. 1975), aff'd, 534 F.2d 113 (8th Cir. 1976).

18. AOL 31; Henderson 10; Gifford 8; Litan 58-59; RealNetworks 10; SIIA 7-8, 44-48.

19. Nader/Love 6.

20. ProComp 29-30 (quoting Microsoft, 253 F.3d at 79). Similarly, CCIA complains that one of the chief advantages gained by Microsoft was the ability to control the browser, not just as a source of a alternate OS-neutral APIs, but specifically as the gateway to Internet computing. As such, this commentor defines the fruit as the “suppressed development of competitive threats,” but criticizes the decree as not addressing this concern.

21. Kegel 3.

22. Catavault 9.

23. Certain comments assert that erosion of the applications barrier to entry would be accomplished better through mandatory support of cross-platform Java. Litigating States 17; SIIA 49; Nader/Love 6. For a discussion regarding the United States' decision to promote opportunities for all middleware, rather than a particular competitor, see the discussion of comments that propose a “Java Must Carry” provision, at ¶¶ 428-29 below.

24. Sun 6.

25. SILA 7-8; CCIA 42; Litigating States' Proposal § 17.

26. AOL 31-32.

27. CCC 19-20; Harris 15; Litigating States' Proposal 16-17 (§ 12); PFF 30; SSI 19, 45.

28. CCC 19-20.

29. 19-20; Palm 13.

30. CompTIA 17 (mandatory sharing of source code).

31. Carroll 4 (“It's the external behavior that's important for interoperability, not the internal design.”)

32. See Plaintiff Litigating States' Remedial Proposals (“Litigating States' Proposal”). The Litigating States' Proposal is Exhibit B to the Litigating States' comment. Comments that advocate the Litigating States' Proposal include SBC 131-132; AOL 58-61; Litan 69-74; PFF 29-31; CFA 101; Davis; Pratt.

33. We again note, as discussed in the U.S. Memorandum and elsewhere in this Response, that the Litigating States' Proposal and RPFJ are to be evaluated under different standards, and are properly addressed separately by the Court. We address the Litigating States' Proposal for the sole upurpose of responding to those commentors (including the Litigating States themselves) who contend that the United States should have adopted a remedy identical, or similar, to the proposal by the Litigating States.

34. Nader/Love 6; Holland 1; Brinkerhoff 1; McWilliams 1; Lewis 1; Harris 2; Alexander 2.

35. KDE 17; Maddux ¶ 2; Thomas 2-3.

36. Philips; Wong.

37. See United States v. E.I. du Pont de Nemours Co., 366 U.S. 316 326 (1961); United States v. Oregon State Med. Soc'y, 343 U.S. 326, 333 (1952); United States v. Nat'l Lead Co., 332 U.S. 319, 338 (1947).

38. These comments include ProComp 80-82; CCIA 33-34; AOL 53-56; PFF 10-17; AAI 12; Relpromax 8-9, Ex. 11. Similar issues also were raised in the complaint filed in American Antitrust Institute v. Microsoft, Civ. No. 02-CV-138 (D.D.C.) (CKK), and Motion Intervention filed by Relpromax Antitrust, Inc.

39. Relpromax 8-9.

40. PFF 10-17.

41. AAI 12; PFF 15.

42. ProComp 82; CCIA 33-34.

43. AOL 53-56.

44. Further explanation of the United States' compliance with its obligations under the Tunney Act is contained in the U.S. Memorandum, Part II.

45. The other purpose, Senator Tunney explained, was to focus the attention of the parties during settlement negotiations. Tunney Remarks, 119 Cong. Rec. at 3452.

46. As the CIS makes clear (CIS at 63), it does not describe literally every remedial proposal considered and rejected. The statute should not be interpreted to require that the CIS do so, for such a requirement would be unduly burdensome and serve no useful purpose. As Senator Tunney said, the CIS ought to provide “some of the alternatives that were considered by the Department.” Senate Hearings at 108 (remark of Sen. Tunney) (emphasis added).

47. United States' Motion to Dismiss, AAI v. Microsoft Corp., No. 02-CV-138 (D.D.C.) (CKK), at 16-23 (Feb. 8, 2002) (“Br. Dismiss AAI”); see also U.S. Memorandum at 20-28.

48. ProComp 81-82.

49. See also Br. Dismiss AAI 19-21.

50. ProComp cites United States v. Central Contracting Co., 527 F. Supp. 1101, 1104 (E.D. Va. 1981), in which the court called “almost incredible” the United States' representation that no determinative documents existed. After further review, and acknowledging that in most cases a “smoking gun” document will not exist, the court adopted a broader standard under which, even if documents are individually not determinative, they can be determinative in the aggregate. See United States v. Central Contracting Co., 537 F. Supp. 571, 575 (E.D. Va 1982). The United States does not believe that there are determinative documents in this case even under the standard of Central Contracting. But in any event, Central Contracting's broad definition of determinative documents has not been followed by any Tunney Act court, has been squarely repudiated by one district court, United States v. Alex. Brown Sons, Inc., 169 F.R.D. 532, 541 (S.D.N.Y. 1996) (“Central Contracting's broad definition of ‘determinative doucments’ may conflict with Congress's intent to maintain the viability of consent decrees”) (cited with approval in MSL, 118 F.3d at 785), aff'd sub nom. United States v. Bleznak, 153 F.3d 16 (2d Cir. 1998), and cannot be reconciled with decisions of the Court of Appeals for the District of Columbia Circuit and the Second Circuit. See MSL, 118 F.3d at 784; Bleznak, 153 F.3d at 20 (citing MSL and quoting “ ‘smoking gun’ or exculpatory opposite” with approval). Central Contracting is simply not good law in this regard.

51. ProComp 81.

52. AAI 12; AOL 55-58; Novell 34-35; ProComp 84.

53. CCC 2; ProComp 84-86.

54. AOL 53; Litan 59-60; ProComp 84-86.

55. AAI 11: SIIA 8-9.

56. AOL 58-61; Litan 59-60; Novell 3, 34-35.

57. PFF 4.

58. Although Microsoft has agreed to be bound by much of thye RPFJ pending its entry (Stipulation ¶ 2 (Nov. 6, 2001)), some important provisions become effective only after entry. See, e.g., RPFJ § IV.B (Technical Committee must be created “[w]ithin 30 days of entry of this Final Judgment”); id. § IV.C (Microsoft's internal compliance program beings “within 30 days of entry”).

59. The standard to be applied in this proceeding is discussed in U.S. Memorandum, Part II.

60. RealNetworks 5-10; Red Hat 9-10; SBC 21-32; Litan 4-11, 31-42; Sen. Kohl 2; Kegel 3; KDE 1-2; Elhauge 5-6, 10, 13; Economides 4; CFA 2; CompTIA 4-5; CCIA 9-11, 18-41; AAI 2-13; ACT 2-18; SIIA 9-11; WLF 3-4; PFF 1-9; ProComp 1-25; Novell 30-37; AOL 1-9.

61. WLF 3; CFA 2; Kegel 3; Sen. Kohl 2; KDE 1-2; CompTIA 4-5.

62. ProComp 1-25; ACT 2-18; AAI 2-13; CCIA 9-11; Litan 4-11; SBC 21-32.

63. CCIA 9, 34-38; Red Hat 9; ProComp 2, 16-20; Litan 34; AOL 2-8; Kegel 3; SIIA 9-10.

64. ProComp 2, 12, 20-23 (no deference); AAI 5-9; CCIA 9-10, 19-33: SBC 30.

65. Novell 30-37; RealNetworks 5-10; ProComp 15-23; AOL 4-9; Litan 33-36; SBC 29-32; AAI 4-13; CCIA 19-39.

66. S.Rep. No. 93-298, at 6(1973).

67. For further discussion of these factors, see U.S. Memorandum at 36-42.

68. Nor may relief in a civil antitrust case be punitive. See page 15 n.37 above.

69. Congress intended that the statutory “public interest” concept encompass “compromises made for non-substantive reasons inherent in the process of settling cases through the consent decree procedure.” House Report at 12.

70. Among the goals of an antitrust decree are “terminat[ing] the illegal monopoly” and “deny[ing] to the defendant the fruits of its statutory violation.”Microsoft, 253 F.3d at 103 (internal quotation omitted). But plaintiffs never alleged, and neither the District Court nor the Court of Appeals found, that Microsoft acquired its monopoly unlawfully. See id. at 58 (Microsoft “violated § 2 by engaging in a variety of exclusionary acts . . . to maintain its monopoly”); see also Microsoft I, 56 F.3d at 1452. Thus, whether, and to what extent, Microsoft now has an “illegal monopoly” depends on whether its unlawful conduct increased or extended Microsoft's monopoly—that is, whether the fruits of its statutory violations included increments to the magnitude or duration of its market power. Again, neither the District Court nor the Court of Appeals found this direct causal connection between the conduct and the continuance of the monopoly.

71. See Note, The Scope of Judicial Review of Consent Decrees under the Antitrust Procedures and Penalties Act of 1974, 82 Mich. L. Rev. 153, 175 n.143 (1974) (“The legislative history of the [Tunney Act] should make the courts sensitive to the efficient allocation of the Department's resources in making their public interest determinations.”).

72. See, e.g., United States v. Paramount Pictures, Inc., 334 U.S. 131, 177 (1948); United States v. Borden Corp., 347 U.S. 514, 518 (1954); United States v. Bechtel Corp., 648 F.2d 660, 666 (9th Cir. 1981).

73. Relpromax 21-23; CCC 3; CCIA 26-32.

74. Tr. 2/8/02 at 16-17.

75. Although the statutory language is unambiguous, legislative history also bears out the distinction. The Senate Report notes that the “bill seeks to encourage additional comment and response by providing more adequate notice to the public,” S. Rep. No. 93-298 at 5, and goes on to describe the provision of information to the public. As in the Tunney Act, the Report's description of the lobbying provision is separated from its treatment of the provision of information to the public by another topic entirely, the court's public interest determination. See id. at 6-7. The House Report is to the same effect. See H.R. Rep. No. 93-1463 at 6-7. (information provided to public through Federal Register and newspapers; id. at 9 (lobbying disclosures).

76. For a fuller discussion, see Br. Dismiss AAI at 24-28.

77. Palm 10; Carroll 2.

78. Red Hat 24.

79. AOL, Klain, 9-10, 12.

80. AAI 38; KDE 16; Wang 1.

81. Henderson 5-6; Gifford 3.

82. CCIA 65; AAI 20-21; ProComp 44; NetAction 12; Novell 9-10; Maddux ¶ 19; Kegel 5, 23; SIIA 18.

83. CCIA 65; RealNetworks 12; Maddux ¶ 19.

84. Novell 13-16.

85. Novel 13.

86. CFA 93-94; CCIA 65-67; AOL 49-50; AAI 21; ProComp 44-46; Palm 9-10; Novell 10; Maddux ¶ 19; Litan 51; KDE 16; Gifford 3; Sen. Kohl 2-3; Relpromax 14; SBC 36-38; Giannandrea 6; SIIA 27-28.

87. Palm 9-10; Kegel 13; SBC 38-39; SIIA 17-20, 38-41, 62-64; Johnson 5.

88. Novell 10; Palm 10; Maddux ¶ 19; -Real Networks 11, 28; SBC 37, 39.

89. CCIA 64; Pantin 32; Palm 10: Novell 10-11; Harris 11.

90. CCIA 64; Harris 11.

91. Pantin 12, 32; NetAction 10, 13; Kegel 5; Harris 11; Maddux ¶ 15.

92. SBC 38; AOL 49; Henderson 6.

93. SBC 39 n.7.

94. SBC 158-59.

95. AOL, Klain 6.

96. Palm 10.

97. Litigating States, Ex. A 18.

98. Litigating States, Ex. B at 34-35.

99. SBC 38 n.6; SIIA 18.

100. AOL 49-50, Klain 13; Palm 9-10; SIIA 19.

101. AOL, Klain 13; Palm 9-10; Kegel 6.

102. AAI33-34; Giannandrea 7.

103. Litigating States, Ex. B 17, 28.

104. Gifford 8.

105. SBC 158.

106. Pantin Comment VI.5, VI.3.

107. Palm 9.

108. Giannandrea 7.

109. Stockton 2 (argues that middleware has very little to do with exposing APIs).

110. Thomas 5-6; Sen. Kohl 2; Palm 9; SBC 40-41, 159; ProComp 65-66; AOL 50; AOL, Klain 13-14; PFF 21; Litigating States, Ex. A 17-18; CCIA 85; Litan 50; RealNetworks 13-14; AAI 34; Giannandrea 7.

111. Thomas 5-6; Sen. Kohl 2; Palm 9; SBC 40-41, 159; ProComp 65-66; AOL 50; AOL, Klain 13-14; PFF 21; Litigating States, Ex. A 17-18; CCIA 85; Litan 50; RealNetworks 13-14.

112. Litigating States, Ex. A 18; AOL 50; AOL, Klain 14.

113. AAI 34.

114. Definition VI.A in the SRPFJ now reads: ‘“API' means application programming interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.”

115. Clapes 22; Litigating States 35 (offering own definition); ProComp B-2 (offering own definition).

116. SBC 43, n.10.

117. Maddux ¶ 58; Giannandrea 7.

118. Palm 8-9, 14-15

119. Pantin 34.

120. Maddux ¶ 58; Pantin 34; Alexander (unpaginated).

121. KDE 15-16; Litan 51; ProComp 44-45; CCIA 65-67; SBC 38 n.5; Pantin 36; Giannandrea 6.

122. For a discussion of issues relating to the intersection of the definition of Trademarked with the definitions of Microsoft Middleware and Microsoft Middleware Product, see Sections III(B) and III(C) above.

123. ProComp 44-45; CCIA 65-67; Pantin 36; Giannandrea 6.

124. ProComp 44-45; KDE 15-16; CCIA 65-67; SBC 38 n.5.

125. See CCIA, at 66-67 (“Indeed, Microsoft could plausibly argue that the Windows Media® mark does not come within the ‘Trademarked’ definition as it is, since even that mark consist of no more than the Windows® mark in combination with the generic term ‘media.’ RPFJ § VI(T) may therefore embody Microsoft's disclaim[er of] any trademark rights in such descriptive or generic terms apart from the Microsoft® or Windows® trademarks.’”).

126. AOL 20 n.19; CCIA 53; Harris 12; KDE 12; Litan 43-44; ProComp 7; SBC 42; SIIA 26; TRAC 8.

127. CCIA 53.

128. Litan 9, 43; RealNetworks 11; SIIA 25-27.

129. Indeed, this sentence in Definition U merely confirms what Microsoft already had the power to do—label the package of what it calls its own operating system products. The sentence does not narrow or alter the operative provisions of the RPFJ; those provisions principally rely on other definitions, such as Microsoft Middleware Product, regardless of how Microsoft labels its operating system.

130. AAI 29; CCIA 53; RealNetworks 11.

131. Giannandrea 1-2; NetAction 2, 6-8; Pantin 36.

132. Microsoft's product website indicates that Windows 95 was designated as being in the “Non-Supported phase” (where licenses may no longer be available and support is limited) on November 30, 2001; Windows 98, Windows 98 SE, and Windows 4.0 will all enter the “Extended” phase (where licenses may no longer be available to consumers and support is somewhat limited) on June 30, 2002. See http://www.microsoft.com/​windows/​lifecycleconsumer.asp.

133. Kegel 6; SBC 42-43.

134. SBC 43.

135. ProComp 56-57; CCIA 58-59; CCIA, Stiglitz Furman 32-33; SIIA 56-60.

136. SIIA 56-60.

137. SIIA 16; CCIA 54-55; AOL 15-16; ProComp 60.

138. See Compaq Press Release, Dec. 12, 2001, http://www.compaq.com/​newsroom/​pr/​2001/​pr2001121204.html.

139. RealNetworks 24-25; AAI 25-34; SBC 91-100; Harris 4; Bast 2-3; Thomas 2-3; Red Hat 11-13, 16-18, 22-23; Alexander 2; KDE 13-14; CFA 88-89, 93-95; CompTIA 5; PFF 19; ProComp 55-60; Pantin 4-7; Palm 14-15; CCIA 85-87, and Stiglitz Furman 31-32; AOL 34-38; AOL, Klain 2-3; Nader/Love 1-6; Maddux ¶¶ 2-4; Sen. Kohl 4; Lococo 1.

140. Nader/Love 2; CompTIA 5.

141. SBC 97; Sen. Kohl 3-4; Nader/Love 2; AOL, Klain 2; Pantin 4-7; ProComp 59; PFF 19; AAI 31-33.

142. SBC 95-96, 99; Schulken 1; McBride 1 (should apply to Xbox).

143. Palm 14; Red Hat 22-23; ACT 27.

144. Sen. Kohl 4; Pantin 4-7; ProComp 59; CFA 88-89; Young 1.

145. Pantin 6-7.

146. RealNetworks 24-25; AOL, Klain 3.

147. Pantin 4-7; Harris 4; Alexander 2; Godshall 1 (shipping PCs with a single non-Windows operating system); Miller 2; Hafermalz 1; Scala 1; Schulze 2; Peterson 3; Burke 2.

148. Red Hat 11-13, 16-18, 22-23.

149. AOL, Klain 3; CCIA 85-86; Pantin 6-7; Harris 4.

150. SBC 97; ProComp 59; KDE 13.

151. Maddux ¶ 5; AOL, Klain 3.

152. SBC 96; Red Hat 16-17.

153. Levy 1 (settlement adequate). This would include linking the price or terms of Office to the promotion of rival middleware. Doing so would represent an alteration in Microsoft's commercial relationship with that OEM because of that OEM's promotion of middleware.

154. Section III.F addresses retaliation against ISVs and IHVs.

155. “Consideration” is defined in Section VI.C. Briefly, Consideration includes such things as preferential licensing terms, support, product information, certifications, and permission to display trademarks, icons, or logos.

156. The Internet site Yahoo! lists in its commercial directory a substantial number of retailers offering custom-built PCs, at least some of which will provide a computer without an operating system at a discounted price (for example, Discovery Computers). Many refurbished computers are offered without an operating system, as well. Moreover, component retailers offer replacement hard drives, also without an operating system.

157. See also, RPFJ § III.C.

158. “Covered OEM” is defined in Section VI.D.

159. Economides 12 (“this restriction can help avoid possible retaliation of Microsoft, so in the present context, it may be in the public interest.”)

160. Kegel 9; Schulze 2; Francis 1.

161. SBC 136.

162. SBC 101, 136; Herrmann 1; Timlin 3; Mitchell 2; Weiller 2; Clapes 5.

163. For example, several commentors raise the specter of Microsoft offering OEMs MDA discounts on Windows licenses based on the number of copies of Office shipped by the OEMs. Kegel 9; CFA 12. But such discounts would be barred by the final paragraph of Section III.A, which forbids Microsoft from paying consideration with respect to one product based on an OEM's distribution of a different Microsoft product. Section III.B.3 would then preclude an MDA for such a purpose, since it would be “otherwise inconsistent with any portion of this Final Judgment.” Similarly, the AOL comment erroneously asserts that the MDA provision would allow OEMs that promote Microsoft products to receive MDA discounts that are denied to OEMs that deal with Microsoft's rivals. AOL 35-36.

164. Sony 2, 4. See also Litigating States' Motion for Limited Participation in Light of the Deposition of Mr. Richard Fade, filed February 19, 2002, at 6-7, 19 (“Litigating States' Motion”). In their Motion, the Litigating States seek an order that would permit them to participate in this Tunney Act proceeding for the limited purpose of submitting portions of the transcript of a Microsoft employee, Richard Fade, purportedly relating to the issues of Section III.B, the non assertion of patent provisions, and Section III.I.5. The United States' Response to the Litigating States' Motion did not object to participation in this one instance colely for the narrow purpose identified—adding the proffered information to the Litigating States' public comment—but did object to any broader or continued participation. Microsoft filed its Response (“Microsoft Response”) on February 22, 2002, in which it did not oppose the participation and submission, and to which it attached a declaration of Richard Fade (“Fade Decl.”). Because the Court has not yet ruled on the Motion, the United States will proceed to respond here to the substance of the information proffered in the Litigating States' Motion.

165. Sony 2; Litigating States' Motion 6-7; Microsoft Response 4-5; Fade Decl. ¶¶ 11-16.

166. Sony 4; Litigating States' Motion 7.

167. Sony 4.

168. SBC 102, 136.

169. SBC 102-03; Drew 1.

170. CCIA 87-88; Turk.

171. SBC 101-02, 136-37 (describing Litigating States' § 2(b)).

172. SBC 136-37.

173. SBC 136-37.

174. Pantin 8; Maddux ¶ 5.

175. Levy 1 (Section III.C adequately prohibits Microsoft from preventing OEMs and consumers form installing rival operating systems or removing Microsoft middleware products and installing rival middleware).

176. CIS at 29.

177. CFA 95; Nader/Love 2; Pantin III.13; Novell 8.

178. SIIA 22-23, Pantin 9.

179. ProComp 10, 67.

180. SBC 51, 138-39; Maddux ¶ 6; Pantin 9-11; Litigating States, Ex. A 10; Elhauge 8-9; Clapes 5-6; PFF 20.

181. SBC 52; CCIA 56; Maddux ¶ 7; Miller 2; Hofmeister 2.

182. AOL 37; AOL, Klain 4; CFA 95; RealNetworks 23; Henderson 8-9; Litigating States, Ex. A 10; ProComp 64; CCIA, Stiglitz Furman 28; Maddux ¶ 8; Pantin 9-11; Alexander 2-3; Giannandrea 3; Miller 2; Thiel 2; Schneider 2.

183. Palm 14; AOL 37; AOL, Klain 4; CCIA 60; PFF 20; Pantin 9-11; RealNetworks 22; SBC 140; Waldman 3, 8; CCIA 59-60; Clapes 5; Schneider 1.

184. Litan 46, 50; CFA 95; SBC 52; Litigating States, Ex. A 10; ProComp 64; CCIA, Stiglitz Furman 28; Giannandrea 3; Waldman 3; Hammett 2.

185. ProComp 64; Pantin 9-11; Giannandrea 3; Rovero 3.

186. SBC 52, 140; Godshall 1; Schneider 1-2.

187. KDE 14; Pantin 11-14; Harris 5, CFA 89; CompTIA 5 (supports); Akin 2; Hafermalz 1; Young 1.

188. AOL 37-38, Klain 4; CCIA, Stiglitz Furman 27.

189. SBC 53; Akin 2.

190. Maddux ¶ 9; SBC 52, 141; NetAction 10, 14; Schneider 2.

191. SBC 53, 138.

192. SBC 137.

193. Litigating States' Provision 4 additionally requires that Microsoft disclose all the necessary APIs, Communications Protcols and Technical Information to accomplish such modifications.

194. Palm 15; AOL, Klain 6; SBC 58; Thomas 6-7.

195. SIIA 24; ProComp 62; Schneider 2.

196. CFA 98; Maddux ¶ 23; Clapes 9.

197. Maddux ¶ 24.

198. AOL 49; AOL, Klain 6; Litigating States, Ex. A 10; Pantin III.24; Realnetworks 14, 17, 23; CCIA 55; KDE 14-15.

199. Litan 45; ProComp 57-58; CCIA 55; AAI 15; Litigating States 10.

200. AOL, Klain 6; CFA 98-99 (“consumer must choose the Non-Microsoft product twice to make it the preferred option”); RealNetworks 18; Miller 3; Clapes 9-10.

201. Maddux ¶ 25; Pantin III.24.

202. RealNetworks 17-18; CCIA 56; Maddux ¶ 27; Giannandrea 2; Gifford 4.

203. SBC 58; Harris 7, 8.

204. NetAction 14; Maddux ¶ 27; Gifford 4, Giebel 1; Miller 3; Akin 3; Hammett 2; Youngman 4.

205. Pantin III.26.

206. SBC 59; CCIA 56; Schneider 2.

207. Litan 45; RealNetworks 16; Henderson 9; CCIA 57; CCIA, Stiglitz Furman28; KDE 16; AAI 17-18; Maddux ¶ 26; AOL, Klain 6; CFA 99; SBC 56; Litigating States, Ex. A 10; ProComp 63; SILA 18; Pantin III.25; Gifford 4; Giannandrea 3.

208. SBC 57.

209. Drew 1; Thiel 2; Miller 3.

210. AAI 18.

211. Litan 47; CCIA, Stiglitz Furman 28; Maddux ¶ 21 (suggests 3 months); Giannandrea 1-2.

212. ProComp 65; CCIA, Stiglitz Furman 28.

213. SBC 60.

214. SBC 61-62.

215. RealNetworks 16-17; Henderson 6; CCIA 56; PFF 21; Harris 7-8; Schulze 2.

216. Pantin III.27.

217. Kegell 5.

218. AA1 13-14; AOL 2-3, 17-24; CCIA 45-46; Sen. Kohl 4; Litan 42-45; ProComp 31-33; RealNetworks 20-21; SBC 46; TRAC 9.

219. AOL 17, 20; SBC 45.

220. Some commentors suggest the reason the IFJ did not require actual removal of middleware code from Windows was because the IFJ's conduct restrictions were intended to be merely transitional, until the breakup of Microsoft could be effectuated. As a result, the argument appears to go, the anti-binding provision did not need to be as extensive or invasive as it would have been in the absence of a structural remedy. But the commentors cite no support in the Plaintiff's prior remedy submissions or the IFJ itself for this claim. In fact, the need to remedy Microdoft's integration of middleware in Windows in a non-removable way was just as strong during the interim conduct remedy period of the IFJ as it is under the RPFJ.

221. Professor Felten stated in part in the cited remedy declaration:

To comply with the product Binding provision, Microsoft's future Windows Operating System Products must allow OEMs and end users ready means for removing End-User Access to any Middleware Product. I will use the term ‘Unbinding’ to refer to the development of the means of removing End-User Access to a Bound product.Declaration of Edward Felten (“Felten Decl.”) ¶92 (filed April 28, 2000)(emphasis added).

222. Various commentors also seek to draw contrasts between the RPFJ and the so-called “Mediator's Draft #18” from the Spring 2000 mediation process with Judge Posner. See e.g., AOL“ 17 n.14. Such attempts at comparison or contrast are fundamentally flawed and therefore of no value in assessing the RPFJ. First, that mediation process was and remains confidential; there has been no authentication of any of the documents now available publicly that purport to represent mediation drafts. Second, the draft in question is itself styled as a “Mediator's Draft;” there is no basis on which to conclude, other than unsubstantiated newspaper articles cited in the comments, that it reflects an actual proposal approved or submitted by any party or that any party ever was willing to agree to it. Third, purported settlement positions from early 2000 indicate nothing about the adequacy of the RPFJ today. The litigation was at a fundamentally different stage. The District Court had issued extensive Findings of Fact that highly favored the United States' presentation of evidence, but the District Court had not yet issued its Conclusions of Law, let alone had the Court of Appeals reviewed and modified the District Court's liability determination.

223. See, e.g., Findings of Fact,¶159 (“the inability to remove Internet Explorer made OEMs less disposed to pre-install Navigator . . . Pre-installing more than one product in a given category . . . can significantly increase an OEM's support costs, for the redundancy can lead to confusion among novice users. In addition, pre-installing a second product in a given software category can increase an OEM's product testing costs.”).

224. AOL 22-23; Litan 45.

225. Litan 44; RealNetworks 20-21.

226. AAI 14-O15; AOL 21-22; CCIA 49-51; Litan 44; ProComp 61-62.

227. Some comments correctly note that a flat ban on commingling might prevent Microsoft from adding new, innovative features to Windows, a result that would not be in the public interest. Economides 9; Johnson 3-4.

228. AAI 15-16.

229. CCC 22; Elhauge 1-2; Sen. Kohl 4.

230. Elhauge 6.

231. Moreover, as Professor Felten testified in his prior remedy declaration, requiring that end users and OEMs be able to remove end-user access to Microsoft Middleware Products would itself result in improvements in the efficiency and reliability of Window. Felten Decl. ¶ 97 (“Section 3.g would require Microsoft to undo the illegal product Binding in which it has already engaged, and to refrain from further Binding of Middleware Products to Operating Systems. This will lead to improvements in the efficiency and reliability of Windows.”).

232. SBC 48-49. SBC notes that IFJ § 3.g.ii contained a such a provision. Id.

233. 253 F.3d at 96.

234. Id. at 68.

235. Relpromax 17-18; Economides 12 (disagrees with this concern).

236. ACT 25, 29 (Section III.F adequately forbids retaliation against ISV's and IHVs).

237. Sun 15-16.

238. SBC 96-97; CCIA 87 (addressing only specific type of retaliation, e.g., Microsoft's threat to discontinue porting Office to Mac OS unless Apple stopped supporting Netscape).

239. Palm 14; ProComp 34.

240. ProComp 34.

241. Red Hat 7-8, 10-13; see also the discussion of the concerns of the open source community, below.

242. On a side note, the commentor is mistaken in asserting that Section III.F.3 expressly permits Microsoft to sue for infringement if an ISV or IHV takes any of the actions protected from retaliation under Section III.F.1. Red Hat 7. Section III.F.3 simply says that Microsoft may enforce agreements or intellectual property rights so long as by doing so it does not violate any provision in the RPFJ.

243. Litigating States, Ex. A 13-14; SBC 95-96; Pantin 14-15.

244. SBC 97; Pantin III.17; CCIA 86; PFF 18-19; Akin 3.

245. Harris 6.

246. SBC 99; Litigating States, Ex. A 16.

247. SBC 98; CFA 97; Maddux ¶ 1; Pantin III.17; CCIA 82; Akin 3.

248. AAI 26-27, 35-36.

249. Litan 47-48; see generally CCIA 88; Elhauge 12.

250. Harris 6.

251. SBC 98-99.

252. SBC 98; also see the discussion in Section III.F.1, supra.

253. SBC 98-99.

254. SBC 105-06; 152; RealNetworks 30-31; Harris 7; Clapes 7.

255. SBC 106-07, 153.

256. One commentor's concern appears to reflect a misunderstanding of the purpose of Section III.G.2. Observing that the provision prohibits Microsoft from granting placement to an IAP or ICP on the condition that the IAP or ICP refrain from activities with any software “that competes with” Microsoft Middleware, the commentor questions whether the provision would have protected Netscape's Navigator during the period before Microsoft introduced Internet Explorer. See PFF 19-20. By implication, the commentor questions whether Section III.G.2 adequately will protect future nascent middleware. But Section III.G.2. prohibits certain conditioned contracts; if Navigator did not compete with IE because IE did not exist, then Microsoft would have no reason to give an IAP benefits on the condition that the IAP not use Navigator. And that is what the historical record shows: Microsoft did not impose the unlawful IAP contracts in the early, pre-IE days of Navigator, but rather started to impose them in late 1996 at a time when Microsoft was trying to build IE's usage share. See Findings of Fact, ¶¶ 256-62. The current wording of Section III.G.2 adequately prohibits Microsoft from taking action against threatening products.

257. SBC 104-05, 151-52; CCIA 59 n.12.

258. Economides 11.

259. SBC 107; Litigating States, Ex. A 12 (point 14).

260. CFA 97.

261. SBC 152.

262. AAI 26; Harris 7.

263. Pantin 16.

264. CCIA 89.

265. Litan 48.

266. CCIA 88-89; AOL 36; AOL, Klain 5.

267. CFA 98; Litigating States, Ex. A 12 (point 14); RealNetworks 30-31.

268. ProComp 67-88; SBC 53; Maddux, Point 20; Harris 6.

269. SBC 107.

270. Pantin 17.

271. SBC 153; RealNetworks 31; Pantin 17-18; Giannandrea 5; Harris 6.

272. Litan 51; NetAction 12; ProComp 42-43; CFA 96; RealNetworks 11; CCIA, Stiglitz Furman 30; CCIA 63.

273. AAI 20.

274. Alexander 3, 4; Carroll 4; Johnson 5; Gifford 5, 9; Litan 51; Kegel 18; Pantin 12; PFF 20; ProComp 38; CCIA 62.

275. KDE 13.

276. AAI 19; CCIA 62; CCIA, Stiglitz Furman 29; SIIA 31-32.

277. Economides 11.

278. ProComp, Arrow A-29.

279. CCIA 60-61.

280. CCIA 62; ProComp 38; CFA 96.

281. Litigating States, Ex. A 8; Palm 6-7; Pantin 12-13; ProComp 39; AOL 39-40; CCIA, Stiglitz Furman 43.

282. Giannandrea 2; Moglen 3-4.

283. Moglen 2; Kegel 8; Maddux ¶ 11; ProComp 39.

284. CCC 11; Kegel 14-18.

285. AAI 34.

286. Kegel 5, 8, 12; Maddux ¶ 12; Litigating States, Ex. B 31; Carroll 2, 4, 5; Johnson 2, 5-6l SBC 78; KDE 13; Pantin 30.

287. ProComp 46.

288. Kegel 18; SIIA 30-31.

289. RealNetworks 27.

290. Palm 10 (hardwiring); AOL, Klain 4 (handwiring).

291. Litigating States, Ex. A 7, 9, Ex. B 36; Pantin 12; SIIA 29-30; SBC 79; RealNetworks 15; CCIA 70-71; PRoComp 47; AOL, Klain 5.

292. Maddux ¶ 13 (Microsoft should be required to publish on Slashdot (slashdot.org) and Freshmeat (www.freshmeat.org).

293. Pantin 11-13.

294. Johnson 6; Novell 18.

295. Maddux ¶ 12.

296. Litigating States' Proposal § 4; Litan 53; CCIA 70.

297. KDE 13; Waldman 5; Kegel 8.

298. SBC 81; Kegel 7-8; Sen. Kohl 5; Litan 57; Maddux ¶ 10; Litigating States, Ex. A 8-9; Palm 13; ProComp 51-52; Alexander 2; AAI 23; CCIA 83; CCIA, Stiglitz Furman 30; CFA 96; RealNetworks 29-30.

299. ProComp 48.

300. AAI 22; Litan 50; Kegel 7-8; Pantin 12; NetAction 10, 13; Alexander 3; Novell 19; Maddux ¶ 14; SBC 81-82; CFA 96.

301. AOLl, Klain 14; AAI22; ProComp 48; SIIA 31; Litan 50; CCIA 84; CFA 96; Giannandrea 7.

302. ProComp 48; Palm 13; SIIA 31; Novell 19; Relpromax 12; RealNetworks 12.

303. Henderson 6-7; Novell 19; Litan 50; Palm 13; CFA 96; CCIA 84-85; AAI 22; Litigating States, Ex. A 7-9; Alexander 3.

304. AOL, Klain 14; Litigating States, Ex. A 7-8.

305. Kegel 12-13; Burke 1; Peterson 2.

306. AAI 36-37; SBC 72-73; Giannandrea 4; Alexander 003; Palm 7; ProComp 54.

307. Alexander 003.

308. KDE 10-11.

309. ProComp 54; SIIA 34; CFA 96-97; CCIA 69-70; AAI 37.

310. See http://www.microsoft.com/​windows2000/​server/​default.asp.

311. See http://www.microsoft.com/​server/​.

312. ProComp 52; Palm 5.

313. Moglen 2-3; Kegel 15; Maddux ¶ 16.

314. AOL, Klain 9-10; SBC 76.

315. CCIA, Stiglitz Furman 43; Litigating States, Ex. A 8; SBC 77; Palm 6-7.

316. CCIA 69; ProComp 53; SIIA 33; AOL, Klain 9; Alexander 4; Giannandrea 4, 6; CCC 17-18; Maddux ¶ 17.

317. AOL, Klain 9 (limited to Windows 2000 server, excludes the Internet); Maddux ¶ 16 (remote administration protocols excluded).

318. CCIA 69; SIIA 34; Sn 26-30; Palm 10.

319. Sun 28-29.

320. Litigating States, Ex. A9.

321. The CIS sets forth some non-exhaustive examples where Communications Protocols must be made available to permit seamless interoperability, including the Communications Protocols used between Microsoft Internet Information Services web server or Active Directory directory server and Internet Explorer or other functionality in the Windows Operating System Product; between server networking services such as Windows server message block protocol/common Internet file system protocol, and the Windows Operating System Product; and between server-hosted code and a runtime environment in the Windows Operating System Product, such as Java virtual machines or Microsoft's common language runtime. It also permits interoperability between Microsoft servers and the digital rights management and other security mechanisms utilizing Microsoft's implementation of Kerberos in the Windows Operating System Product, subject to a narrow exception in Section III.J.1.a, permitting limited withholding of information necessary to protect particular installations (e.g., keys and tokens particular to a given installation). See CIS at 38-40; see also discussion of Section III.J.1.a, infra.

322. SBC 70-72.

323. ProComp 52-53; Harris 6.

324. Thomas 4-5; Waldman 5; Maddux ¶ 16.

325. ProComp 55; Giannandrea 1; SIIA 35.

326. Palm 13; Litan 57; Litigating States, Ex. A 8-9; RealNetworks 29; Maddux ¶ 15; CCIA 83-84; Sun 36.

327. Sun 36-37.

328. CCIA 83-84.

329. Litan 53.

330. See e.g., RPFJ §§ III.D and III.E.

331. SBC 85-86; Litigating States, Ex. A 15; CCIA 81; Sun 35; Giannandrea 5; Moglen 2; Waldman 4.

332. AOL, Klain 7; CCIA 81; Moglen 2; Giannandrea 5; Harris 8.

333. Henderson 8; SBC 87-88; CFA 88; ProComp 51; AOL, Ex, B. at 7; SIIA 36-37; Litigating States 15; AAI 28-29; CCIA 81-82; Sun 38; RealNetworks 29; Giannandrea 5; Alexander 3; Harris 8; Maddux ¶ 10.

334. Kegel 8; Maddux ¶ 9.

335. Sun 35-36.

336. SBC 85-86.

337. SBC 86.

338. The other allegedly inconsistent prior statements cited by this commentor (SBC 86) do not withstand scrutiny. These statements concerning royalty-free licenses all were made in the narrow context of providing divested entities access to necessary technical information. See United States Reply Memo at 27-29 (discussing Western Electric for the proposition that was precedent to support the United States' divestiture request; relying on ATT as an example of a prior structural remedy in a monopolization case that did not involve mergers); United States v. Western Elec. Co., 569 F. Supp. 1057, 1118 (D.D.C. 1983), aff'd sub nom. California v. United States, 464 U.S. 1013 (1983) (discussion of royalty-free licenses centered around effectuating the divestiture of the Regional Bell Operating Companies and ensuring that the divestitures did not result in “balkanized regional networks” and “fragmentation” to the “detriment of all users”); United States v. General Electric, 115 F. Supp. 835, 844 (D. N.J. 1953) (“General Electric's attempt to maintain control over the lamp industry has been largely by way of extending its basic patents on lamps and lamp parts. To compel the completely free use of these patents is not to impose upon General Electric and other defendants penalties for misuse of patents and violation of the antitrust laws, but rather to check the intrusion of advantages thereby gained into the mechanics of competition in the lamp industry.”). Here, the United States does not believe that the circumstances support royalty-free licensing. Compulsory licensing, but with a reasonable royalty, will be sufficient to achieve the remedial goal of ensuring access to necessary information for interoperability.

339. AOL, Klain 7; CCIA; Moglen 2; Ginnandrea 5; Harris 8; Pantin 22.

340. Giannandrea 5; Harris 8.

341. Pantin 22.

342. Henderson 8; SBC 87-88; CFA 88; ProComp 51; AOL Ex. B at 7; SIIA 36-37; Litigating States 15; AAI 28-29; CCIA 81; Sun 38; RealNetworks 29; Giannandrea 5; Alexander 3; Harris 8; Maddux ¶ 10.

343. Kegel (unpaginated).

344. Red Hat 11-12.

345. Id.

346. Maddux ¶ 9.

347. Litigating States' Proposal § 15(b).

348. AAI 22; AOL 40-41; AOL, Klain 7-8, 10; Catavault 12-13; CCIA 16, 72-77; CCIA, Stiglitz Furman 30; CFA 99; Elhauge 12; Red Hat 25-28; SBC 88-89; SIIA 35-36; Sun 32-33; Alexander 3; Giannandrea 4; Gifford 5; Harris 8-9; Johnson 8; Moglen 4-5; Waldman 6; KDE 14; Litan 52; Litigating States, Ex. A 16, Ex. C 18; Nader/Love 2-5; Maddux ¶ 30; NetAction 11; Novell 20-21; ProComp 49-50, 55.

349. Alexander 3.

350. Harris 9.

351. AAI 23; CCIA 77-81; CFA 100; Henderson 7-8; Red Hat 28-29; SBC 88-91; SIIA 36; Alexander 3; Giannandrea 4-5; Carrol 2; Harris 9; Moglen 4-5; Waldman 6; KDE 12; Sen. Kohl 3; Litan 52; Litigating States, Ex. A 16-17; Nader/Love 2-5; Maddux ¶ 31; Pantin III.33-34; ProComp 50-51.

352. AOL 41-42

353. Kegel 8; Naver/Love 1; Pantin 12; SBC 79; CCC 21; Johnson 2; Alexander 5; Carroll 4; Maddux ¶ 14.

354. CCC 17; SIIA 38, 39.

355. CCIA 89-92; AOL 50-53; ProComp 75-77; Litan 54-55; RealNetworks 31-32; Red Hat 30-31; Nader 5; Waldman 5, Sen. Kohl 5; SBC 111-13, 157-58.

356. AAI 42; Maddux ¶ 35.

357. The RPFJ's discussions of additional factors such as “systematic” or “knowing” violations are not intended to change the scienter or other elements that must be shown in actions to enforce the RPFJ through contempt charges. See, e.g., United States v. NYNEX Corp., 8 F.3d 52, 54-55 (D.C. Cir. 1993) (setting forth the elements of contempt, applied to antitrust decree). In particular, it is clear that a party to a decree may be found guilty of criminal contempt if its contumacious behavior was “willful.” Willful intent for purposes of contempt may be shown by proof that a defendant “acted with deliberate or reckless disregard of [its] obligation under the” order. United States v. Young, 107 F.3d 903, 909 (D.C. Cir. 1997); see also United States v. Greyhound Corp., 508 F.2d 529, 532 (7th Cir. 1974) (in context of antitrust decree, holding that willful element can be proven by evidence of either deliberate or reckless conduct).

358. CCIA 89-92; AOL 50-52; ProComp 75-77; Litan 54-55; RealNetworks 32; Palm 15-16; Red Hat 30-31; Nader/Love 5; Waldman 5; Sen. Kohl 5; TRAC 9-10; Drew 1; Young 3; Clabaugh 1; Schulken 2.

359. One comment erroneously implies that permitting Microsoft to have counsel present when its employees are questioned by the TC somehow would allow Microsoft to thwart the discovery of violations. See Nader/Love 5. To the contrary, this right is also present in conjunction with informal interviews or “on the record” depositions by Plaintiffs; is a standard part of all such provisions in antitrust consent decrees in recent years; protects against impermissible ex parte contacts; and protects Microsoft's legitimate privileges and basic principles of due process.

360. As some comments point out, the TC cannot share confidential Microsoft information with third parties. E.g., Gifford 5; Gianndrea 6. This will prevent third parties from using the TC as a way to in essence improperly expand Microsoft's disclosure obligations under the RPFJ. For example, the TC will have access to all of Microsoft's source code, including source code for software products not directly at issue in the case, and will be able to evaluate all APIs, even those not necessarily related to middleware. If the TC was free to disclose such items to third parties, it would in essence permit the wholesale looting of Microsoft's intellectual property, thus changing the fundamental nature of the carefully limited, negotiated settlement that led to the submission of the RPFJ to the Court.

361. CCIA 91; AOL 51; Litan 55; ProComp 76; Harris 10; Gifford 5; Alexander 4; Waldman 5; Clapes 19; Godshall 2; Hammett 1.

362. As one commenter supporting the RPFJ noted in observing that the TC will “also have the authrity [sic] to resolve disputes about Microsoft's compliance,” “this panel should not be used as a regulatory body.” Economides 11.

363. CCIA 90; Red Hat 30.

364. Nader/Love 5; Litan 55; AOL 51; Alexander 4; Gifford 6; Young 3; Morrissey 2; Clabaugh 1; Cheetham 1; Spotswood 1; Akin 4; Godshall 1-2.

365. Harris 9-10; Gifford 5.

366. Nader/Love 5 (suggesting that the TC might be “playing golf” with Microsoft executives instead of investigating anticompetitive activities); Young 3.

367. One comment (Gifford 6) questions whether, in the event of disagreement on the TC as to whether violations have occurred or been adequately cured, an individual member could submit dissenting views to Plaintiffs. The RPFJ does not require that the TC's reports be unanimous or reflect only the majority's views and conclusions. Further, there is no bar to an individual TC member communicating directly with Plaintiffs at any time.

368. Palm 16.

369. SBC 158; Clapes 18.

370. RealNetworks 32.

371. SBC 112-13; AOL 51-53; TRAC 9; Novell 30; RealNetworks 32; Red Hat 30-31; SBC 157.

372. See, e.g., United States v. Smith Int'l, 2000-1 Trade Cas. (CCH) ¶ 72,763 (D.D.C. 2000) (criminal and civil contempt); United States v. Microsoft Corp., 147 F.3d 935 (D.C. Cir. 1998) (“Microsoft II”) (civil contempt and preliminary injunction in enforcement of earlier Microsoft decree, inter alia, finding nonconsensual referral to special master to be abuse of discretion); United States v. NYNEX Corp., 814 F. Supp. 133 (D.D.C.) (criminal contempt of ATT decree) rev'd, 8 F.3d 52 (D.C. Cir. 1993); United States v. Twentieth-Century Fox Film Corp. 1990-1 Trade Cas. (CCH) ¶ 69,060 (S.D.N.Y. 1990) (criminal contempt); United States v. Western Elec. Co., 1989-1 Trade Cas. (CCH) ¶ 68,421 (D.D.C. 1989) (civil enforcement consent order to resolve allegations of ATT decree violations in lieu of contempt).

373. Indeed, it is not clear from the Litigating States' Proposal whether the delegation to the special master of fact-finding powers its sufficiently circumscribed. Cf. Microsoft II, 147 F.3d at 953-56 (mandamus appropriate for court's overbroad special master referral violative of both U.S. Const. Art. III and Fed. R. Civ. P. 53(b)).

374. Novell 30; Nader/Love 5; Sen. Kohl 5.

375. RealNetworks 32; ProComp 76; Litan 55; AOL 50-53; AAI 40-41 (generally).

376. Specifically, the Litigating States' Proposal requires Microsoft to provide 60-days written notice of direct or indirect acquisitions or investments by Microsoft or any of its subsidiaries, as well as notice of any exclusive intellectual property licenses granted to Microsoft or any of its subsidiaries. The requirement applies to transactions involving businesses of which Microsoft did not own 33% or more prior to December 1, 2001, and which fall into one of several categories related to computer software and equipment, computer systems design, telecommunications, and network industries. See Litigating States' Proposal § 20.

377. CCC 26; CCIA 83; Giannandrea 6; Litigating States, Ex. A 18; Nader/Love; Relpromax 15; SBC 157; Thomas 2, 5.

378. Some commentors agree with this proposed term. ACT 31; Economides 5-6.

379. AAI 39; CCIA 83; Nader/Love 5; Pantin 28.

380. CCIA 83 n.17; SBC 157; Young 3; Hammett 1.

381. See, e.g. United States v. Delta Dental Plan of Ariz., Inc., 1995-1 Trade Cas. (CCH) ¶ 71,048, 1995 WL 454769 (D. Ariz. 1995) (health care); United States v. Topa Equities, “Public Comments and Response on Proposed Final Judgment,” 60 FR 28,168, 28,170 (May 30, 1995) (noting that industry characteristics made quick entry likely), entered by, 1995-2 Trade Cas. (CCH) ¶ 71,061, 1995 WL 481368 (D. V.I. July 14, 1995); Oregon v. Mulkey, 1997-1 Trade Cas. (CCH) ¶ 71,859, 1997 WL, 599410 (D. Or. June 16, 1997) (commercial crab fishing); United States v. Motor Vehicle Mfr. Ass'n, 1982 Trade Cas. (CCH) ¶ 65,175, 1982 WL 1934 (C.D. Cal. Oct. 28, 1982) (modifying judgment in decree regarding development and installation of motor vehicle emission control devices).

382. See, e.g., United States v. Tele-Communications, Inc., “Comment and Response on Proposed Final Judgment,” 59 Fed. Reg. 39,783, 39,784 (Aug. 4, 1994) (recognizing that the telecommunications industry is “one that has experienced major changes in MTSD technologies that are ongoing”); United States v. Agri-Mark, Inc., “Competitive Impact Statements and Proposed Consent Judgments,” 45 Fed. Reg. 79,186, 79,189 (Nov. 28, 1980) (arguing that “the dairy industry is constantly evolving as a result of technological changes”).

383. We note that the suggestion of an open-ended decree, subject to review after five years (see Gifford 9; Litan 73), or contingent upon Microsoft's market share decreasing (see Thomas 6), would create undesirable uncertainty in the market and would be contrary to the United States' mission to enforce the federal antitrust laws and to remedy specific violations thereof.

384. Several comments argue that the two-year extension does not provide a meaningful check on Microsoft's behavior. AAI 40; Alexander 4; CCC 27; CFA 84; Gifford 9; Harris 11, 14; Litigating States, Ex. A 17; Litan 55; Maddux ¶ 17; ProComp 76; Schneider 1; RealNetworks 32; TRAC 11. Some argue that the United States should have included sanctions for violations similar to those contained in the Litigating States' proposed remedy. SBC 157. The Litigating States' proposed remedy spells out a series of possible penalties that may be imposed if Microsoft violates the decree, including source code licensing, additional conduct remedies, and civil penalties. See Litigating States' Proposal § 19. The Litigating States' proposal also provides that if Microsoft brings or threatens to bring a groundless claim of intellectual property infringement for the purpose of impairing interoperability of non-Microsoft products, Microsoft may be enjoined from asserting or enforcing any intellectual property rights in related APIs, communications interfaces or technical information.

Contrary to these commentors' assertions, the possibility of the two-year extension of the RPFJ's requirements and prohibitions will help dissuade Microsoft from violating its terms and conditions. The United States believes that this potential sanction, which is supplemented by its traditional enforcement and contempt authority, will provide a significant incentive for Microsoft to comply.

385. In addition, the RPFJ requires an independent, full-time, on-site compliance team that will monitor compliance with the decree, report violations, and attempt to resolve technical disputes under the disclosure provisions. This ongoing supervision provides added assurance that Microsoft will comply with the obligations and restrictions imposed by the decree and that competitive conditions will be restored to the greatest extent possible during the five-year term of the proposed RPFJ.

386. Waldman 6-7.

387. CCIA 83; Elhauge 13; Sen. Kohl 5; RealNetworks 29-30.

388. RealNetworks 30.

389. PFF 24-29; Litan 65-69; ProComp 77-78.

390. ProComp 77.

391. SIIA 22-25; AOL 24-31; Matthewson Winter 25-26.

392. SIIA 8, 64.

393. Palm 14.

394. IFJ § 3.c.

395. SIIA 64-65; SBC 45-46.

396. The Litigating States proposes a very-similar provision. Section 11 of the Litigating States' Proposal provides: “Microsoft shall not offer, agree to provide, or provide any consideration to any actual or potential platform software competitor in exchange for such competitor's agreeing to refrain or refraining in whole or in part from developing, licensing, promoting or distributing any Operating System Software Product or any Middleware produce competitive with any Windows Operating System Product or Microsoft Middleware Product.”

397. See Plaintiffs' Reply Memorandum in Support of Proposed Final Judgment at 64 (May 17, 2000).

398. At least two comments express concern that the RPFJ does not contain language similar to that of Section 3.h of the IFJ. RealNetwork 30-31; SBC 98-99. For a complete discussion of how Sections III.F and III.G address this concern, see Sections V and VI, above.

399. Palm 11-12.

400. Kegel 9-10.

401. SIIA 49; Nader/Love 6.

402. CCC 13-17; SIIA 49-51; ProComp 30; ProComp, Arrow 20-21; PFF 30-31; SBC 135; Hargraves 9; CCIA 38; CFA 11; Ltan 71-72.

403. Litigating States' Proposal § 14, see also Litigating States, Ex. A 14-15.

404. Indeed, the plaintiff States originally alleged that Microsoft engaged in unlawful monopolization, the violation of Section 2, with respect to Microsoft Office. However, the States dropped this claim prior to the trial.

405. CompTIA 19 (porting Office would interfere with natural market forces); ACT 24 (porting Office requirement beyond the scope of the case).

406. PFF 30; SBC 143; CCIA, Stiglitz Furman 40-41.

407. ACT 29; CompTIA 16.

408. PFF 30; SBC 143.

409. SBC 143.

410. CCIA, Stiglitz Furman 40-41.

411. See discussion of RPFJ § III.C at Section IV(D), above.

412. See discussion of Section III.A (Section IV(B), above); see also Sections III.D. and VI.U, which require Microsoft to provide actual and potential competitiors with full access to the same APIs and related information as Microsoft middleware has to interoperate with the current, and future Windows operating systems, offering the potential of a seamless fit and greater possibility for incorporation of competing middleware.

413. SIIA 61; Novell 5; Sun 23-24.

414. AAI 25; Novell 25; SBC 146; ProComp 35, 74.

415. SIIA 61-62.

416. SIIA 61-62 (Kerberos); Johnson 5 (Kerberos).

417. Litigating States' Proposal § 16; ProComp 35 (referring to Litigating States' Proposal).

418. CIS at 62.

419. Litigating States, Ex. A 15.

420. CCIA 59 n.12; Kegel 27-28; KDE 13; Novell 26-29; CFA 90.

421. KDE 13.

422. Kegel 27-28.

423. Novell 26-29.

424. CCIA 59 n.12.

425. SBC 99.

426. Litigating States' Proposal § 9.

427. SIIA 41-44; CFA 55-65; Palm 7-8; Catavault 3-11; KDE 9-10.

428. See generally [http://www.microsoft.com/​net/​];​; Huwalt 3.

429. See generally http://www.sun.com/​software/​sunone/​liberty/​.

430. CCIA 39-41.

431. ProComp 26-29; ProComp, Arrow ¶¶4, 32-34; AOL 45; Elhauge 4, 10; SIIA 44-51; Litan 58-59; Henderson 4, 10; Litigating States, Ex. A 13-14; CCIA 10, 35-36, 42-44; Gifford 8; Pantin 37.

432. Sun 7; Litigating Sates, Ex. C at 1.

433. See, e.g., Litigating States, Ex. C at RFAs 2, 5, 10, 12-13, 23, 28-35, 39-45.

434. RFAs 2-4, 10, 32.

435. Litigating States, Ex. C at RFAs 34, 39, 40, 41, 42, 43, 45.

436. Red Hat 3-4.

437. Red Hat 24; AAI 37-38; CCIA 77-82; Waldman 5.

438. Red Hat 28-29; Henderson 7-8; Alexander 3-4; Carroll 2-3; Harris 9; Moglen 3, 5; Waldman 6; Litan 52; Pantin 24-25; AAI 23; Waldman 6.

439. Red Hat 7-21.

440. Kegel 8-9.

441. Kegel 11; Koppe 1; Tilwalli 1; Kasten 5; Carroll 3; Johnson 2.

442. Kegel 9; CompTIA 5 (pro-settlement); Pantin 5-6.

443. See CCIA 41-42; AOL 1, Klain 8-9; Litan 47-49; WLF 6; Waldman 4; ProComp 74-77; Sun 36-37. The RPFJ measures Microsfoft's conduct against this standard in, for example, Section III.B.2 (“reasonable volume discounts”), Section III.C.5 (“reasonable technical specifications”), Section III.E (“reasonable and non-discriminatory terms”), Section III.F.2 (“limitations reasonably necessary to and of reasonable scope and duration”), and Section III.G (“reasonable period of time”).

444. CCIA 41-42; ProComp 74-77; Litan 49; AOL, Klain 8-9.

445. AOL 1; Litan 47.

446. Thus, for example, the defendant in United States v. First Multiple Listing Service, Inc., 1998 WL 417, at *1-*2 (N.D. Ga. 1984), was enjoined from refusing to provide services to any person who agrees to pay “reasonable set-up costs,” a “reasonable security deposit,” and “reasonable and non-discriminatory fees . . . reflecting reasonable expenses . . . provid[ing] for a reasonable minimum annual fee . . . [and] reflecting a reasonable approximation of the cost[s].” The final judgment there further provided that “[n]othing in this final judgment shall prohibit Defendant from (i) imposing delivery or service charges . . . reflecting reasonable approximations of actual costs, including reasonable deposits for keys or books . . ..” Id. at *2.

447. See, e.g., Litan 47-49; CCIA 41-42.

448. See, e.g., Response to Comments on Sections III.B.2, III.F.2, III.G.2.

449. An order need not list the components of a term which is understood by common parlance, particularly when considering the persons to whom the order is directed. United States v. PATCO, 678 F.2d 1, 3 (1st Cir. 1982), citing Village of Hoffman Estates v. Flipside, 455 U.S. 489, 495 n.7 (1982) (“[t]he rationale is evident: to sustain such a challenge, the complainant must prove that the enactment is vague ‘not in the sense that it requires a person to conform his conduct to an imprecise but comprehensible normative standard, but rather in the sense that no standard of conduct is specified at all” ’ (quoting Coates v. City of Cincinnati, 402 U.S. 611, 614 (1971)).

450. Litan 47-49.

1. For the Court's convenience, the United States also submits a red-lined version of the SRPFJ, attached hereto as Exhibit A, which compares the SRPFJ to the RPFJ.

2. The Settling States also agreed to the RPFJ. Following the submission of the RPFJ to the Court on November 6, 2001, the Court deconsolidated United States v. Microsoft Corp. from New York, et al. v. Microsoft Corp., in which the Settling States, nine other states and the District of Columbia are parties.

3. The public comment period officially ran from November 28, 2001, the date that the RPFJ and the United States' Competitive Impact Statement (“CIS”) were published in the Federal Register. 66 F.R. 59,452 (Nov. 28, 2001). Out of an abundance of caution, the United States also chose to accept and treat as Tunney Act comments various communications from members of the public commenting on the proposed settlement that were received by the DOJ beginning on November 5 2001, the first business day following submission of the initial Proposed Final Judgment to the Court.

4. Of course, the United States retains the right to withdraw its consent to the proposed decree at any time prior to entry, based on the public comments or otherwise. Stipulation, November 6, 2001, at 1; Stipulation, February 27, 2002, at 1.

5. See, e.g., United States v. Allied Waste Indus., Response to Public Comments on Antitrust Consent Decree and Joint Motion for Entry of a Modified Judgment, 65 F.R. 36,224 (June 7, 2000) (parties modified divestiture requirements as a result of objections raised in comments); United States v. Thomson Corp., 949 F. Supp. 907, 915 (D.D.C. 1996) (parties proposed modifications to final judgment in response to public comment, among other things); see also Antitrust Procedures and Penalties Act: Hearings on S. 782 and S. 1088 Before the Subcomm. on Antitrust and Monopoly of the Senate Comm. on the Judiciary, 93rd Cong., 1st Sess. 146 (1973) (Testimony of the Hon. J. Skelly Wright) (“The Department itself has modified consent decrees on a number of occasions as a result of public comment”).

6. The Order stated, inter alia, that “the parties shall address . . . whether, in response to the comments received by the Department of Justice in accordance with 15 U.S.C. section 16(b), the United States and Microsoft are considering any modifications” to the RPFJ. Order at 1.

7. See Section II.E., infra at 8-9, discussing Section III.I.5. of the RPFJ.

8. Entry of a decree following modification without a new round of notice and comment is conventional in Tunney Act practice. For example, After notice and comment in ATT, the court said it would enter the decree as in the public interest if the parties agreed to a number of modifications, and the Court entered the modified decree without a new round of notice and comment once the parties did so. United States v. ATT, 552 F. Supp. 131, 225-26 (D.D.C. 1982); see also Mass. Sch. of Law v. United States, 118 F.3d 776, 778 (D.C. Cir. 1997).