Skip to Content

Notice

United States

Document Details

Information about this document as published in the Federal Register.

Published Document

This document has been published in the Federal Register. Use the PDF linked in the document sidebar for the official electronic format.

Start Preamble Start Printed Page 12090

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: (202) 514-2481, Fax: (202) 514-3763. 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, (202) 514-8276.

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 IllusoryStart Printed Page 12091

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 withStart Printed Page 12092both 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 toStart Printed Page 12093discourage 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 ofStart Printed Page 12094the 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 readingStart Printed Page 12095of 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 promptlyStart Printed Page 12096notify 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 theStart Printed Page 12097congressional 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 invokedStart Printed Page 12098by 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.Start Printed Page 12099Intended 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.Start Printed Page 12100

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 andStart Printed Page 12101enforceability, 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]

Start Printed Page 12102

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. SwiftStart Printed Page 12103Co., 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 theStart Printed Page 12104fencing-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.Start Printed Page 12105

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 meansStart Printed Page 12106by 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 disclosuresStart Printed Page 12107that 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 theStart Printed Page 12108former 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.Start Printed Page 12109

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 anStart Printed Page 12110evidentiary 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 bringsStart Printed Page 12111adversary 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.

Start Printed Page 12112

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, (202) 514-8276.

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 exclusivelyStart Printed Page 12113and 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 uponStart Printed Page 12114completion 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) microsoft.atr@usdoj.gov 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.Start Printed Page 12115

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 byStart Printed Page 12116Microsoft'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]

Start Printed Page 12117

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 courtAppellate court
Agreements With OEMs
1. Prohibition on OEM removing desktop icons, folders, or Start Menu entriesYes.
2. Prohibition on OEM altering initial boot sequenceYes.
3. Prohibition on OEM allowing alternative user interface to launch automaticallyNo.
4. Prohibition on OEM adding icons or folders in different size or shapeYes.
5. Prohibition on OEM using Active Desktop to promote others' productsYes.
Binding of IE to Windows
6. Excluding IE from the “Add/Remove” utilityYes.
7. Designing Windows to override users' choice of default browser other than IENo.
8. Commingling code to eliminate OEM choice of removal of IE from WindowsYes.
Agreements With IAPs
9. Licensing IE for freeNo.
10. Payment for use of IE with IAP service signupNo.
11. Developing IE Access Kits and offering them for freeNo.
12. Placement of IAP's product on desktop in return for IE exclusivity (or limit to Navigator shipments)Yes.
Start Printed Page 12118
Agreements With ICPs, ISVs, and Apple
13. Exclusive agreements with ICPsNo.
14. Agreements With ISVs to make IE the default hypertext interfaceYes.
15. Threat to end support of Office on MAC platform as “a club” to coerce Apple to use IE as default browser with MAC OSYes.
Efforts To Contain and Subvert Java
16. Design of Java Virtual Machine (“JVM”) that was incompatible with Sun's productNo.
17. Exclusive agreements to promote Microsoft's JVMYes.
18. Deceived Java developers about Windows-specific nature in Microsoft JavaYes.
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 ActNo.

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

ProvisionSection in SRPFJ
Remedy To Stop Offending Conduct
Prohibits retaliatory conductIII.A.1-3, III.F.1
Broadly bans exclusive dealingII.F.2, III.G.1-2
Provides OEMs more control of desktop and initial boot sequenceIII.C.1-6
Remedy To Prevent Recurrence
Non-discrimination and non-retaliation provisionsIII.A.1-3,
Remedy To Restore Competitive Conditions
If Microsoft middleware products rely on an API, then that API must be disclosedIII.D, III.I
Microsoft required to create and preserve default settings, such that certain ofIII.H.2
Microsoft required to create add/delete functionality that makes it easier for OEMsIII.H.1
Microsoft required to license communications protocols embedded in the OS, butIII.E, III.I
Start Printed Page 12119

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 CourtAppellateAddressed in
Agreements With OEMs
1. Prohibition on OEM removing desktop icons, folders, or StartYesIII.H.1
2. Prohibition on OEM altering initial boot sequence.YesIII.C.3-5
3. Prohibition on OEM allowing alternative user interface toNo
4. Prohibition on OEM adding icons or folders in different size orYesIII.C.1-2
5. Prohibition on OEM using Active Desktop to promote others'YesIII.C.1-2
Binding of IE to Windows
6. Excluding IE from the “Add/Remove” utilityYesIII.H.1
7. Designing Windows to override users' choice of defaultNoIII.H.2
8. Commingling code to eliminate OEM choice of removal of IEYesIII.C.1
Agreements with IAPs
9. Licensing IE for freeNo
10. Payment for use of IE with IAP service signupNo
11. Developing IE Access Kits and offering them for freeNo
12. Placement of IAP's product on desktop in return for IE Exclusivity (or limit to Navigator shipments)YesIII.G.1-2
Agreements With ICPs, ISVs, and Apple
13. Exclusive agreements with ICPsNoIII.G.1-2
14. Agreements with ISVs to make IE the default hypertext userYesIII.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 OSYesIII.F.1-2 III.G.1
Start Printed Page 12120
Efforts To Contain and Subvert Java
16. Design of Java Virtual Machine (“JVM”) that wasNo
17. Exclusive agreements to promote Microsoft's JVMYesIII.F.2
18. Deceived Java developers about Windows-specific nature inYesIII.D
19. Coerced Intel to stop aiding Sun by threats to support AMDYes
Course of Conduct
20. Apart from specific acts, Microsoft's general course of conduct violated Section 2 of the Sherman ActNo

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 thatStart Printed Page 12121preferential 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 ofStart Printed Page 12122middleware 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 conductStart Printed Page 12123authorized 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 orStart Printed Page 12124group 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 millionStart Printed Page 12125copy 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-Start Printed Page 12126setting 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 XPStart Printed Page 12127Home 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”Start Printed Page 12128over 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 fullyStart Printed Page 12129resolve 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: (512) 475-8545, Fax: (512) 471-8899.

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.Start Printed Page 12130

“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 HearingStart Printed Page 12131

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

(202) 514-8276.

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,Start Printed Page 12132Disclosure 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.

Start Printed Page 12133

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 mustStart Printed Page 12134allegations 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 beStart Printed Page 12135required 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.Start Printed Page 12136

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),Start Printed Page 12137vacated, 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).Start Printed Page 12138Instead, 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 thatStart Printed Page 12139case 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.Start Printed Page 12140v. 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,Start Printed Page 12141Tunney 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.Start Printed Page 12142

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 thatStart Printed Page 12143they 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 asStart Printed Page 12144being 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 somewhatStart Printed Page 12145broader 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 theStart Printed Page 12146case.[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 ofStart Printed Page 12147the 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 technicalStart Printed Page 12148provisions, 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-MicrosoftStart Printed Page 12149Middleware 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.Start Printed Page 12150The 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 compensatedStart Printed Page 12151for 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 licenseStart Printed Page 12152terms 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-Start Printed Page 12153Microsoft 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 requiringStart Printed Page 12154that 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 otherwiseStart Printed Page 12155does 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] ItStart Printed Page 12156is 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,Start Printed Page 12157making 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 haveStart Printed Page 12158largely 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, bothStart Printed Page 12159in 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).Start Printed Page 12160Section 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.Start Printed Page 12161

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, orStart Printed Page 12162support 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.

Start Printed Page 12163

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—Start Printed Page 12164narrowing 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 GuidelinesStart Printed Page 12165for 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, shouldStart Printed Page 12166be 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 FinalStart Printed Page 12167Judgment 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 toStart Printed Page 12168disclose 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 ofStart Printed Page 12169certainty 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 subscriptionStart Printed Page 12170offering 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 itStart Printed Page 12171might 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 thirdStart Printed Page 12172parties. 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 serverStart Printed Page 12173operating 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] SeveralStart Printed Page 12174commentors 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 thatStart Printed Page 12175licenses 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 notStart Printed Page 12176obligated 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 disclosedStart Printed Page 12177because 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 asStart Printed Page 12178inadequate,[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 toStart Printed Page 12179behave 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 educationStart Printed Page 12180and 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 transactionStart Printed Page 12181reporting 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 fromStart Printed Page 12182seeking 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 orStart Printed Page 12183adversely 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 aStart Printed Page 12184Microsoft 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, allowingStart Printed Page 12185consumers, 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 ProvisionStart Printed Page 1218616.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.[