United States of America et al v. Microsoft Corporation

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

D.D.C.February 27, 2002

IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF COLUMBIA UNITED STATES OF AMERICA, Plaintiff, Civil Action No. 98-1232 (CKK) v. MICROSOFT CORPORATION, Defendant. Next Court Deadline: March 6, 2002 Tunney Act Hearing RESPONSE OF THE UNITED STATES TO PUBLIC COMMENTS ON THE REVISED PROPOSED FINAL JUDGMENT CHARLES A. JAMES Assistant Attorney General DEBORAH P. MAJORAS Deputy Assistant Attorney General PHILLIP R. MALONE RENATA B. HESSE DAVID BLAKE-THOMAS PAULA L. BLIZZARD KENNETH W. GAUL ADAM D. HIRSH JACQUELINE S. KELLEY STEVEN J. MINTZ BARBARA NELSON DAVID SEIDMAN DAVID P. WALES Attorneys U.S. Department of Justice Antitrust Division 601 D Street N.W., Suite 1200 Washington, D.C. 20530-0001 (202) 514-8276 PHILIP S. BECK February 27, 2002 Special Trial Counsel UNITED STATES OF AMERICA et al v. MICROSOFT CORPORATION Doc. 699 Dockets.Justia.com TABLE OF CONTENTS Page INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 I. GENERAL COMMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 A. Should Never Have Brought Suit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 B. Allegations Of Political Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 C. Removing The “Fruits” Of Microsoft’s Anticompetitive Conduct . . . . . . . . . . . . . . . 9 D. The Litigating States’ Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 E. Fines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 F. Senate Hearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 II. TUNNEY ACT ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 A. Adequacy Of The United States’ Competitive Impact Statement . . . . . . . . . . . . . . . 17 1. The CIS Complies With The Requirements Of The Tunney Act . . . . . . . . . . . . 18 2. The CIS Recites “A Description And Evaluation Of Alternatives To Such Proposal Actually Considered By The United States” . . . . . . . . . . . . . . . . . . . . 20 B. The United States Fully Complied With All Tunney Act Requirements Regarding Determinative Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 C. Timing And Process Of Hearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1. The Court Has Discretion To Determine The Nature And Format Of The Tunney Act Proceedings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2. An Evidentiary Hearing Is Not Required In This Case . . . . . . . . . . . . . . . . . . . 24 3. The Court Is Not Required To Permit Any Third-Party Participation . . . . . . . . 26 4. Allowing Third-Party Participation Through An Evidentiary Hearing Would Unnecessarily Delay And Complicate These Proceedings . . . . . . . . . . . . . . . . . 27 ii 5. The Tunney Act Proceedings Should Not Be Held In Conjunction With, Or Rely Upon Evidence From, The Litigating States’ Remedy Hearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 D. Standard Of Review Under The Tunney Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 1. The Tunney Act Requires That Entry Of The RPFJ Be “In the Public Interest” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2. The Court Should Grant Deference to the Judgment of the United States . . . . . 33 E. Microsoft’s Compliance With Section 16(g) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 III. DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 A. Definition Of “ISV” (RPFJ § VI.I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B. “Microsoft Middleware” (RPFJ § VI.J) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 1. Distributed Separately To Update A Windows Operating System Product . . . . 44 2. Trademarked Or A Major Version Of Any Microsoft Middleware Product . . . 46 3. Same Or Substantially Similar Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4. Includes At Least The Software Code That Controls Most Or All Of The User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 5. Major Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 C. “Microsoft Middleware Product” (RPFJ § VI.K) . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 D. “Non-Microsoft Middleware” (RPFJ § VI.M) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 E. “Non-Microsoft Middleware Product” (RPFJ § VI.N) . . . . . . . . . . . . . . . . . . . . . . . 58 F. “Personal Computer” (RPFJ § VI.Q) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 G. “Trademarked” (RPFJ § VI.T) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 H. “Windows Operating System Product” (RPFJ § VI.U) . . . . . . . . . . . . . . . . . . . . . . . 65 1. Microsoft’s Discretion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 iii 2. Prior Windows Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3. Operating Systems for Other Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 IV. OEM PROVISIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 A. Overreliance On OEMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 B. Non-Retaliation (RPFJ § III.A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 1. Section III.A Is Sufficiently Broad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 2. Section III.A Properly Allows Microsoft To Enforce Intellectual Property Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 3. Section III.A Protects OEMs From Arbitrary Termination Of Their Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4. Requiring Proof Of Knowledge Is Necessary And Can Be Met . . . . . . . . . . . . 78 5. Microsoft’s Permitted Use Of “Consideration” Is Appropriate . . . . . . . . . . . . . 78 6. The RPFJ Uses The Common Language Definition Of “Retaliate” . . . . . . . . . 79 C. Uniform Terms (RPFJ § III.B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 1. Top Twenty OEMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 2. MDAs Or Other Discounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3. OEMs Should Be Able To Negotiate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4. Volume Discounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5. Termination — Cause, Materiality, And Notice . . . . . . . . . . . . . . . . . . . . . . . . 85 6. Servers Or Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7. Key License Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 8. Prohibition On Enforcing Agreements Inconsistent With The RPFJ . . . . . . . . . 87 iv D. Freedom Of OEMs To Configure Desktop (RPFJ § III.C) . . . . . . . . . . . . . . . . . . . . 87 1. Section III.C.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 2. Section III.C.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3. Section III.C.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 4. Section III.C.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5. Section III.C.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6. Comparison To Litigating States’ Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 E. Microsoft’s Obligations To Provide Add/Remove Functionality And Automatic Invocations (RPFJ § III.H) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 1. Obligation To Provide Add/Remove Functionality . . . . . . . . . . . . . . . . . . . . . . 98 2. Obligation To Provide Automatic Invocations And Exceptions . . . . . . . . . . . 100 a. Obligations To Provide Automatic Invocations . . . . . . . . . . . . . . . . . . . . 100 b. Exceptions To The Obligation To Provide Automatic Invocations . . . . . 104 3. Microsoft’s Ability To Change Configurations . . . . . . . . . . . . . . . . . . . . . . . . 106 4. Timing Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 F. Commingling Of Operating System Code And Middleware Code . . . . . . . . . . . . . 114 V. RETALIATION AGAINST ISVs OR IHVs (RPFJ § III.F) . . . . . . . . . . . . . . . . . . . . . . . 122 A. Comments On Section III.F.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 B. Comments On Section III.F.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 C. Comments On Section III.F.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 VI. EXCLUSIONARY AGREEMENTS (RPFJ § III.G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 A. Omissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 v B. Exemptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 VII. DISCLOSURE PROVISIONS (RPFJ §§ III.D, III.E) . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 A. Disclosure Of APIs (RPFJ § III.D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 1. Product Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 a. Microsoft’s Ability To Manipulate The Definitions To Avoid Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 b. Products Other Than Microsoft Middleware . . . . . . . . . . . . . . . . . . . . . . 139 c. Products Other Than Windows Operating System Products . . . . . . . . . . 142 2. API Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 a. Definition Of “API” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 b. Definition Of “Documentation” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 c. Source Code Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 d. Intellectual Property Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 3. Timing Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 a. First Disclosures: Windows XP Service Pack 1 Or No Later Than November 2002 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 b. Triggered By New Version Of Microsoft Middleware: Last Major Beta Test Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 c. Triggered By New Version Of Windows Operating System Product: Timely Manner (RPFJ § VI.R) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 B. Disclosure Of Communications Protocols (RPFJ § III.E) . . . . . . . . . . . . . . . . . . . . 157 1. Product Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 a. Windows Operating System Product . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 b. Microsoft Server Operating System Product . . . . . . . . . . . . . . . . . . . . . . 159 vi c. Non-Microsoft Client Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . 160 d. Server-To-Server Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 e. Other Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 2. Communications Protocols, Disclosure And Licensing . . . . . . . . . . . . . . . . . . 163 a. Definition Of “Communications Protocols” (RPFJ § VI.B) . . . . . . . . . . . 163 b. The Meaning Of “Interoperate” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 c. License For Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 d. The Meaning Of “Natively” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 e. Licensing On “Reasonable And Non-Discriminatory Terms” . . . . . . . . . 168 3. Timing Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 C. Compulsory Licensing (RPFJ § III.I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 1. Reasonable And Non-Discriminatory Royalty . . . . . . . . . . . . . . . . . . . . . . . . . 172 2. Restriction On Sublicenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 3. Cross-Licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 4. Scope Of Intellectual Property Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 5. Comparison To Litigating States’ Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 D. Security Carve-Outs (RPFJ § III.J) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 1. Limitation On Obligations To Document, Disclose Or License . . . . . . . . . . . 178 2. Conditioning Licenses On Certain Requirements . . . . . . . . . . . . . . . . . . . . . . 181 E. Disclosure Of File Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 vii VIII. ENFORCEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 A. The Enforcement Powers Of Plaintiffs And The Court . . . . . . . . . . . . . . . . . . . . . . 186 B. The Technical Committee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 1. Technical Committee Powers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 2. Composition And Control Of The Technical Committee . . . . . . . . . . . . . . . . 191 C. Internal Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 D. Voluntary Dispute Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 E. Proposals For A Special Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 F. Proposed Reporting Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 IX. TERMINATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 X. COMPARING THE RPFJ TO THE IFJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 A. Structural Relief vs. Conduct Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 B. Anti-Tying Provisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 C. Intentionally Disabling Rival Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 D. Agreements Limiting Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 XI. OTHER PROPOSED REMEDIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 A. Restrictions On Software Development Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 B. Java Must-Carry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 C. Porting Microsoft Office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 D. Licensing Of Predecessor Versions Of Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 217 E. Industry Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 F. Protection For Large End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 viii G. Non-Retaliation For Participation In Litigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 XII. MISCELLANEOUS COMMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 A. Microsoft’s “.Net” Initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 B. Course Of Conduct . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 C. Restoring Java/Netscape Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 D. Microsoft’s Responses To The Litigating States’ RFAs . . . . . . . . . . . . . . . . . . . . . 229 1. Meeting Of The Minds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 2. Objections To Language In The CIS As “Vague And Ambiguous” . . . . . . . . 231 E. “Open Source” Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 F. “Reasonableness” Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 G. Computers For Schools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 The United States also filed, simultaneously with this Response, a Memorandum1 Regarding Modifications Contained in Second Revised Proposed Final Judgment. The SRPFJ is a logical growth of the RPFJ, its incremental modifications responding to public comments, and the overall result further advances the public interest. IN THE UNITED STATES DISTRICT COURT FOR THE DISTRICT OF COLUMBIA UNITED STATES OF AMERICA, Plaintiff, Civil Action No. 98-1232 (CKK) v. MICROSOFT CORPORATION, Defendant. Next Court Deadline: March 6, 2002 Tunney Act Hearing RESPONSE OF THE UNITED STATES TO PUBLIC COMMENTS ON THE REVISED PROPOSED FINAL JUDGMENT 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. Because every comment addresses the RPFJ, this Response1 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. A full description of the history of this litigation — both procedural and substantive —2 can be found in Memorandum Of The United States In Support Of Entry Of The Revised Proposed Final Judgment 1-11 (filed Feb. 27, 2002) (“U.S. Memorandum”). In addition, nine State plaintiffs (the “Settling States”) from New York v. Microsoft3 Corp., No. 98-CV-1233 (D.D.C.) (CKK) (“New York ”), agreed to settle their dispute with Microsoft under the RPFJ. Ten other plaintiffs from New York (the “Litigating States”) did not agree to the terms of the RPFJ and are continuing their suit in a separate proceeding. The United States also chose to accept and treat as Tunney Act comments various4 communications from members of the public commenting on the proposed settlement that were received by the Department of Justice beginning on November 5, 2001, the first business day following submission of the initial Proposed Final Judgment to the Court, even though the official 60-day comment period had not yet begun. See 15 U.S.C. § 16(b) (60-day period begins upon publication in the Federal Register). 2 INTRODUCTION2 3. The United States and Microsoft filed the RPFJ on November 6, 2001, thereby3 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 Fed. Reg. 59,452 (2001). The United States also posted information on those procedures on the Department of Justice website. See < >. 4. The 60-day public comment period began on November 28, 2001, and ended on January 28, 2002. During that period, the United States received 32,329 public comments. This4 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 AT&T case — which completely restructured the telecommunications industry — by more By contrast, the United States’ 1994 consent decree with Microsoft generated only five5 public comments. See 59 Fed. Reg. 59,426, 59,427-29 (1994). See, e.g., .6 Porcher. The Response generally uses abbreviations to identify commentors. An index7 of comments cited, along with unique identifying numbers, is found in Appendix A to this Response. 3 than an order of magnitude. United States v. AT&T, 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 Fed. Reg. 21,214-24 (1982) (listing name and address of each commentor on proposed AT&T 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. Most of these comments address only the proposed settlement of the7 private, class action against Microsoft, and not the RPFJ; erring on the side of over- Reid; Karkess.8 Becker; Gallagher.9 Daly; Love.10 The United States provided copies of these detailed comments to the Court on11 February 14, 2002, and posted copies of these comments on the Department of Justice website on February 15, 2002. These comments may be found at . 4 inclusiveness, the United States has filed these latter unrelated comments with the Court and will publish them. 7. Approximately 22,750 comments express an overall view of the RPFJ. Of these, roughly 5,700 do not, for example, attempt to analyze the substance of the RPFJ, do not address any of its specific provisions, and do not describe any particular strengths or shortcomings of it. 8 Approximately 16,700 comments can be characterized as containing some generally limited analysis of the RPFJ. These comments typically are one-to-two pages and contain limited discussion of issues related to the RPFJ. The remaining 350 comments expressing an overall9 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. There is10 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. There is also considerable duplication of the issues addressed and11 arguments raised among these “detailed” comments. Thus, unless otherwise noted, citations to specific comments merely are representative12 of comments on that issue, and should not be interpreted as an indication that other comments were not reviewed. 5 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; other comments may raise the same12 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 CMDC 1-11; Skinn 1; Wagstaff 1; Lloyd 1; Peterson 1; Bode 1; Poindexter 1;13 Williams 1. 6 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 Relpromax 3-4, 18, 20-22, Ex. 10; CCIA 18-34 & Decl. Edward Roeder; ProComp 78-14 86. Commentors also allege that Microsoft has failed adequately to disclose lobbying15 contacts as required by the Tunney Act, 15 U.S.C. § 16(g). Pursuant to the Court’s Order dated February 13, 2002, Microsoft will respond to allegations of deficiencies in its compliance with § 16(g). 7 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. By citation to Microsoft’s lobbying and15 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. See, e.g., United States v. Haldeman, 559 F.2d 31, 134 (D.C. Cir. 1976); In re United16 States, 666 F.2d 690, 695 (1st Cir. 1981) (a judge should ignore “rumors, innuendos, and erroneous information published as fact in the newspapers”); McClelland v. Gronwaldt, 942 F. Supp. 297 (E.D. Tex. 1996). Lobbying activities by the defendant, even though “intensive and gross,” are17 insufficient to establish corruption on the part of the United States. See, e.g., United States v. Associated Milk Producers, 394 F. Supp. 29, 39-40 (W.D. Mo. 1975), aff’d, 534 F.2d 113 (8th Cir. 1976). 8 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, so too must allegations of16 corruption on the part of Department of Justice attorneys be supported by something more than supposition and innuendo. Actual evidence of corruption is required in order to support17 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. AOL 31; Henderson 10; Gifford 8; Litan 58-59; RealNetworks 10; SIIA 7-8, 44-48.18 Nader/Love 6.19 9 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, and that the decree must go further than simply barring18 Microsoft from further bad behavior. Such criticism is not well-taken. As the United States19 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 ProComp 29-30 (quoting Microsoft, 253 F.3d at 79). Similarly, CCIA complains that20 one of the chief advantages gained by Microsoft was the ability to control the browser, not just as a source of alternate OS-neutral APIs, but specifically as the gateway to Internet computing. As such, this commentor defines the fruit as the “suppressed development of competitive threats,” but criticizes the decree as not addressing this concern. Kegel 3.21 Catavault 9.22 Certain comments assert that erosion of the applications barrier to entry would be23 accomplished better through mandatory support of cross-platform Java. Litigating States 17; SIIA 49; Nader/Love 6. For a discussion regarding the United States’ decision to promote opportunities for all middleware, rather than a particular competitor, see the discussion of comments that propose a “Java Must Carry” provision, at ¶¶ 428-29 below. 10 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,” and20 does not sufficiently remove the applications barrier to entry. In the phrasing of one21 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. As22 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. It also restricts23 Microsoft’s conduct toward OEMs and others, and thus opens the door for competing middleware to obtain necessary support, promotion, and distribution. Sun 6.24 SIIA 7-8; CCIA 42; Litigating States’ Proposal § 17.25 11 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. But the United States never alleged in this case that Microsoft24 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. Other criticism is directed toward the25 AOL 31-32.26 CCC 19-20; Harris 15; Litigating States’ Proposal 16-17 (§ 12); PFF 30; SSI 19, 45.27 CCC 19-20.28 CCC 19-20; Palm 13.29 12 decree’s failure to ban contractual tying. A number of commentors, including the Litigating26 States, propose that Microsoft be required to offer open source licenses to Internet Explorer source code without royalty. These commentors claim that, because Microsoft’s intent in27 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. Similarly, certain commentors propose that Microsoft be required to port28 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 CompTIA 17 (mandatory sharing of source code).30 Carroll 4 (“It's the external behavior that's important for interoperability, not the internal31 design.”). See Plaintiff Litigating States’ Remedial Proposals (“Litigating States’ Proposal”). The32 Litigating States’ Proposal is Exhibit B to the Litigating States’ comment. Comments that advocate the Litigating States’ Proposal include SBC 131-132; AOL 58-61; Litan 69-74; PFF 29- 31; CFA 101; Davis; Pratt. 13 ensuring a level playing field for all participants in the software industry. Most importantly for30 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. The goal of the RPFJ is to restore the opportunity for31 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. The United States’ primary consideration when crafting the RPFJ was32 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 We again note, as discussed in the U.S. Memorandum and elsewhere in this Response,33 that the Litigating States’ Proposal and the RPFJ are to be evaluated under different standards, and are properly addressed separately by the Court. We address the Litigating States’ Proposal for the sole purpose of responding to those commentors (including the Litigating States themselves) who contend that the United States should have adopted a remedy identical, or similar, to the proposal by the Litigating States. Nader/Love 6; Holland 1; Brinkerhoff 1; McWilliams 1; Lewis 1; Harris 2;34 Alexander 2. KDE 17; Maddux ¶ 2; Thomas 2-3.35 14 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.” Others similarly complain that the proposed decree does not contain any34 provision for the disgorgement of illegal profits. Still others complain that the decree should35 Philips; Wong.36 See United States v. E.I. du Pont de Nemours & Co., 366 U.S. 316, 326 (1961); United37 States v. Oregon State Med. Soc’y, 343 U.S. 326, 333 (1952); United States v. Nat’l Lead Co., 332 U.S. 319, 338 (1947). 15 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), 16 Charles F. Rule (counsel to Microsoft), Professor Lawrence Lessig (Stanford Law School), Dr. Mark N. Cooper (Consumer Federation of America), Jonathan Zuck (Association for Competitive Technology), Matthew Szulick (Red Hat, Inc.), and Mitchell E. Kertzman (Liberate Technologies); (5) written statements submitted for the record of Ralph Nader and James Love (Consumer Project on Technology), Mark Havlicek (Digital Data Resources, Inc.), Jerry Hilburn (Catfish Software, Inc.), Lars H. Liebeler (Computing Technology Industry Association), and Dave Baker (EarthLink, Inc.); (6) the RPFJ; (7) News Statement of Citizens Against Government Waste; (8) letter from Senator Hatch to Assistant Attorney General James; (9) letter from Assistant Attorney General James to Senator Hatch; (10) letter from Robert H. Bork to Senators Leahy and Hatch; (11) letter from James L. Barksdale to Senators Leahy and Hatch; (12) letter from Vermont Attorney General William H. Sorrell to Steven A. Ballmer; (13) written questions of Senators Leahy, Hatch, Kohl, DeWine, Durbin, and McConnell; and (14) answers to written questions from Assistant Attorney General James, Professor Lawrence Lessig, Mitchell Kertzman, Matthew Szulik, Charles F. Rule, Jonathan Zuck, and Jay L. Himes. 29. The materials submitted by the Senate Judiciary Committee constitute a self- contained record of the Committee’s comments on the settlement (in the form of both questions and written and oral statements) submitted to the Department of Justice, and the Department’s responses to those comments. As such, the United States does not respond again here to those comments specifically. The United States notes, however, that many of the Committee’s comments on the settlement are identical to or overlap with other comments (including an individual comment from Senator Kohl), to which the United States does respond. These comments include ProComp 80-82; CCIA 33-34; AOL 53-56; PFF 10-17; AAI 38 12; Relpromax 8-9, Ex. 11. Similar issues also were raised in the complaint filed in American Antitrust Institute v. Microsoft, Civ. No. 02-CV-138 (D.D.C.) (CKK), and Motion for Intervention filed by Relpromax Antitrust, Inc. Relpromax 8-9.39 PFF 10-17.40 AAI 12; PFF 15.41 ProComp 82; CCIA 33-34.42 AOL 53-56.43 17 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. Thus,38 one commentor contends that the CIS is deficient for failing to include substantive economic analysis. Another contends that the CIS is too terse, and therefore does not meet the39 requirements of the statute, the standard set by the CIS filed by the United States in AT&T (47 Fed. Reg. 7170-01), or requirements of agency rulemakings. Other commentors assert that the40 CIS is inadequate for failing to provide a detailed explanation for rejection of alternative remedies. Still other commentors fault the CIS for allegedly misstating or adding terms to the41 RPFJ. One commentor specifically criticizes the CIS’ lack of explanation of (1) the use of a42 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 Further explanation of the United States’ compliance with its obligations under the44 Tunney Act is contained in the U.S. Memorandum, Part II. 18 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; The other purpose, Senator Tunney explained, was to focus the attention of the parties45 during settlement negotiations. Tunney Remarks, 119 Cong. Rec. at 3452. 19 (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”). The purpose could be achieved,45 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 As the CIS makes clear (CIS at 63), it does not describe literally every remedial46 proposal considered and rejected. The statute should not be interpreted to require that the CIS do so, for such a requirement would be unduly burdensome and serve no useful purpose. As Senator Tunney said, the CIS ought to provide “some of the alternatives that were considered by the Department.” Senate Hearings at 108 (remark of Sen. Tunney) (emphasis added). 20 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, and describes the reasons why they were rejected. It explains why the46 United States viewed the RPFJ as a superior alternative to continued litigation; why the United States decided not to continue to seek a break-up of Microsoft; and the reasons for differences between the interim conduct provisions of the Initial Final Judgment (IFJ), United States v. Microsoft Corp., 97 F. Supp. 2d 59, 66-69 (D.D.C. 2000), vacated, 253 F.3d 34, 46 (D.C. Cir. 2001) (en banc) (per curiam), and the provisions of the RPFJ. It also lists a number of other remedy proposals, the criteria used to evaluate them, and the results of that evaluation. The recitations contained in the CIS are fully consistent with providing “basic data about the decree to enable [members of the public with a direct interest] to understand what is happening and make informed comments o[r] objections to the proposed decree,” 119 Cong. Rec. 3452 (1973) United States’ Motion to Dismiss, AAI v. Microsoft Corp., No. 02-CV-138 (D.D.C.)47 (CKK), at 16-23 (Feb. 8, 2002) (“Br. Dismiss AAI”); see also U.S. Memorandum at 20-28. ProComp 81-82.48 21 (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, the recital complied with47 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, but it is mistaken.48 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 See also Br. Dismiss AAI 19-21.49 ProComp cites United States v. Central Contracting Co., 527 F. Supp. 1101, 1104 (E.D.50 Va. 1981), in which the court called “almost incredible” the United States’ representation that no determinative documents existed. After further review, and acknowledging that in most cases a “smoking gun” document will not exist, the court adopted a broader standard under which, even if documents are individually not determinative, they can be determinative in the aggregate. See United States v. Central Contracting Co., 537 F. Supp. 571, 575 (E.D. Va. 1982). The United States does not believe that there are determinative documents in this case even under the standard of Central Contracting. But in any event, Central Contracting’s broad definition of determinative documents has not been followed by any Tunney Act court, has been squarely repudiated by one district court, United States v. Alex. Brown & Sons, Inc., 169 F.R.D. 532, 541 (S.D.N.Y. 1996) (“Central Contracting’s broad definition of ‘determinative documents’ may conflict with Congress’s intent to maintain the viability of consent decrees”) (cited with approval in MSL, 118 F.3d at 785), aff’d sub nom. United States v. Bleznak, 153 F.3d 16 (2d Cir. 1998), and cannot be reconciled with decisions of the Court of Appeals for the District of Columbia Circuit and the Second Circuit. See MSL, 118 F.3d at 784; Bleznak, 153 F.3d at 20 (citing MSL and quoting “‘smoking gun’ or exculpatory opposite” with approval). Central Contracting is simply not good law in this regard. 22 government’s files. The United States there said the statute referred to documents “‘that49 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 ProComp 81.51 23 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 AAI 12; AOL 55-58; Novell 34-35; ProComp 84.52 24 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. But the Tunney Act does not mandate a hearing or52 trial. See United States v. Airline Tariff Publ’g Co., 836 F. Supp. 9, 11 n.2 (D.D.C. 1993); United States v. NBC, 449 F. Supp. 1127 (C.D. Cal. 1978). Indeed, such a hearing could largely defeat the principal considerations behind the RPFJ: to avoid the uncertainty of a trial and to obtain “prompt relief in a case in which illegal conduct has long gone unremedied.” CIS at 60. The legislative history “clearly and expressly establishes that ‘[i]t [was] not the intent of the committee to compel a hearing or trial on the public interest issue.’” NBC, 449 F. Supp. at 1143- 44 (quoting Senate Antitrust Report, quoted with approval in House Antitrust Report at 8-9). Instead, the “Tunney Act expressly allows the court to make its public interest determination on 25 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 AT&T, 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. AT&T, 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, 26 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 CCC 2; ProComp 84-86.53 AOL 53; Litan 59-60; ProComp 84-86.54 27 parties, they have already had a full and effective mechanism to present to the Court any53 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 or that could be addressed through briefing and oral argument, should54 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 AAI 11; SIIA 8-9.55 AOL 58-61; Litan 59-60; Novell 3, 34-35.56 PFF 4.57 28 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. Others assert that the Court should hold a hearing on the55 RPFJ, if at all, only after the Litigating States’ hearing. Finally, at least one commentor56 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 that case in this proceeding, therefore, would be Although Microsoft has agreed to be bound by much of the RPFJ pending its entry58 (Stipulation ¶ 2 (Nov. 6, 2001)), some important provisions become effective only after entry. See, e.g., RPFJ § IV.B (Technical Committee must be created “[w]ithin 30 days of entry of this Final Judgment”); id. § IV.C (Microsoft’s internal compliance program begins “within 30 days of entry”). 29 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. The Court therefore should not postpone entry58 of the RPFJ. The standard to be applied in this proceeding is discussed in U.S. Memorandum,59 Part III. RealNetworks 5-10; Red Hat 9-10; SBC 21-32; Litan 4-11, 31-42; Sen. Kohl 2; Kegel60 3; KDE 1-2; Elhauge 5-6, 10, 13; Economides 4; CFA 2; CompTIA 4-5; CCIA 9-11, 18-41; AAI 2-13; ACT 2-18; SIIA 9-11; WLF 3-4; PFF 1-9; ProComp 1-25; Novell 30-37; AOL 1-9. WLF 3; CFA 2; Kegel 3; Sen. Kohl 2; KDE 1-2; CompTIA 4-5.61 ProComp 1-25; ACT 2-18; AAI 2-13; CCIA 9-11; Litan 4-11; SBC 21-32.62 CCIA 9, 34-38; Red Hat 9; ProComp 2, 16-20; Litan 34; AOL 2-8; Kegel 3; SIIA 9-10.63 ProComp 2, 12, 20-23 (no deference); AAI 5-9; CCIA 9-10, 19-33; SBC 30.64 Novell 30-37; RealNetworks 5-10; ProComp 15-23; AOL 4-9; Litan 33-36; SBC 29-32;65 AAI 4-13; CCIA 19-39. 30 D. Standard Of Review Under The Tunney Act59 52. Numerous comments address the standard of review applicable under the Tunney Act to the RPFJ. These comments range from brief references to the language of the Tunney Act60 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. Second,63 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. And finally, many argue, again because of the procedural64 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. Although the65 S. Rep. No. 93-298, at 6 (1973).66 31 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 For further discussion of these factors, see U.S. Memorandum at 36-42.67 32 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 Nor may relief in a civil antitrust case be punitive. See page 15 & n.37 above.68 33 remedy must be clearly related to the anticompetitive effects of the illegal conduct. Microsoft I, 56 F.3d at 1460 (quoting International Salt Co. v. United States, 332 U.S. 392, 401 (1947)). Although an antitrust conduct remedy is not limited to enjoining precisely the conduct found to be unlawful, e.g., United States v. Hartford-Empire Co. v. United States, 323 U.S. 386, 409 (1945); AT&T, 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 Congress intended that the statutory “public interest” concept encompass “compromises69 made for non-substantive reasons inherent in the process of settling cases through the consent decree procedure.” House Report at 12. Among the goals of an antitrust decree are “terminat[ing] the illegal monopoly” and 70 “deny[ing] to the defendant the fruits of its statutory violation.” Microsoft, 253 F.3d at 103 (internal quotation omitted). But plaintiffs never alleged, and neither the District Court nor the Court of Appeals found, that Microsoft acquired its monopoly unlawfully. See id. at 58 (Microsoft “violated § 2 by engaging in a variety of exclusionary acts . . . to maintain its monopoly”); see also Microsoft I, 56 F.3d at 1452. Thus, whether, and to what extent, Microsoft now has an “illegal monopoly” depends on whether its unlawful conduct increased or extended Microsoft’s monopoly — that is, whether the fruits of its statutory violations included increments to the magnitude or duration of its market power. Again, neither the District Court nor the Court of Appeals found this direct causal connection between the conduct and the continuance of the monopoly. 34 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 See Note, The Scope of Judicial Review of Consent Decrees under the Antitrust71 Procedures and Penalties Act of 1974, 82 Mich. L. Rev. 153, 175 n.143 (1974) (“The legislative history of the [Tunney Act] should make the courts sensitive to the efficient allocation of the Department’s resources in making their public interest determinations.”). 35 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. See, e.g., United States v. Paramount Pictures, Inc., 334 U.S. 131, 177 (1948); United72 States v. Borden Corp., 347 U.S. 514, 518 (1954); United States v. Bechtel Corp., 648 F.2d 660, 666 (9th Cir. 1981). 36 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 AT&T 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’ 37 views, Tunney Act proceedings will become equivalent to the proceedings that lead to adjudicated judgments with adjudicated remedies. 65. Commentors are also incorrect in their assertion that the procedural posture of the case requires the District Court to fashion and impose an adjudicated judgment. The District Court’s role in making this public interest determination differs from its role in formulating an adjudicated judgment. Because the District Court “is evaluating a settlement, it is not as free to exercise its discretion in fashioning a remedy,” AT&T, 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 38 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.” AT&T, 552 F. Supp. at 151. 67. Thus, even in the AT&T 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”). Relpromax 21-23; CCC 3; CCIA 26-32.73 Tr. 2/8/02 at 16-17.74 39 E. Microsoft’s Compliance With Section 16(g) 68. Several comments question whether Microsoft made adequate disclosures under 15 U.S.C. § 16(g). At the February 8, 2002, Status Conference, the Court directed Microsoft to73 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.” The United States therefore supplies the following74 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, Although the statutory language is unambiguous, legislative history also bears out the75 distinction. The Senate Report notes that the “bill seeks to encourage additional comment and response by providing more adequate notice to the public,” S. Rep. No. 93-298 at 5, and goes on to describe the provision of information to the public. As in the Tunney Act, the Report’s description of the lobbying provision is separated from its treatment of the provision of information to the public by another topic entirely, the court’s public interest determination. See id. at 6-7. The House Report is to the same effect. See H.R. Rep. No. 93-1463 at 6-7 (information provided to public through Federal Register and newspapers); id. at 9 (lobbying disclosures). For a fuller discussion, see Br. Dismiss AAI at 24-28.76 40 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. Thus, even if Microsoft failed to satisfy the75 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 Palm 10; Carroll 2.77 Red Hat 24.78 AOL, Klain 9-10, 12.79 41 III. DEFINITIONS A. Definition Of “ISV” (RPFJ § VI.I) 71. Several comments address Section VI.I, which defines “ISV” as “an entity other than Microsoft that is engaged in the development or marketing of software products.” All of the comments concern the breadth of the definition. 72. Several commentors misread the definition, contending that “ISV” inappropriately covers only companies creating software that runs on Windows Operating System Products. 77 The definition shows on its face that this concern is misplaced: any “software product” is covered, whether or not it runs on Windows. 73. Several commentors suggest expanding the definition of “ISV” explicitly to include developers of particular categories of products. One commentor worries that Microsoft could construe the definition to exclude developers or marketers of non-Microsoft operating systems, and suggests that the definition be modified to include them explicitly. Another worries that78 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. These concerns are misplaced and, therefore, the proposed modifications79 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 AAI 38; KDE 16; Wang 1.80 Henderson 5-6; Gifford 3.81 42 (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. The RPFJ, however, sets no minimum80 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. To review, Microsoft81 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 43 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. CCIA 65; AAI 20-21; ProComp 44; NetAction 12; Novell 9-10; Maddux ¶ 19; Kegel 82 5, 23; SIIA 18. 44 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. They argue that there is82 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 CCIA 65; RealNetworks 12; Maddux ¶ 19.83 45 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 that they 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 Novell 13-16.84 Novell 13.85 46 from a Windows Operating System Product. As this commentor notes, however, directory84 services “have become competitively critical links between the desktop and network computing.” Accordingly, directory services are most protected under Section III.E, which85 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.). CFA 93-94; CCIA 65-67; AOL 49-50; AAI 21; ProComp 44-46; Palm 9-10; Novell 10;86 Maddux ¶ 19; Litan 51; KDE 16; Gifford 3; Sen. Kohl 2-3; Relpromax 14; SBC 36-38; Giannandrea 6; SIIA 27-28. 47 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. Turning to the latter, several argue that products such as Internet86 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 Palm 9-10; Kegel 13; SBC 38-39; SIIA 17-20, 38-41, 62-64; Johnson 5.87 48 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 Novell 10; Palm 10; Maddux ¶ 19; RealNetworks 11, 28; SBC 37, 39.88 49 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 as being 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. Commingling of code, as discussed by the Court of88 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 CCIA 64; Pantin 32; Palm 10; Novell 10-11; Harris 11.89 CCIA 64; Harris 11.90 50 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. Commentors point out that the interfaces between user interface89 elements and the Windows Operating System Product are unlikely to be competitively significant. This modification does not substantively change this definition, but instead makes90 Pantin 12, 32; NetAction 10, 13; Kegel 5; Harris 11; Maddux ¶ 15.91 51 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 52 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 SBC 38; AOL 49; Henderson 6.92 SBC 39 n.7.93 SBC 158-59.94 AOL, Klain 6.95 53 development. This critique ignores the second part of the definition, which explains what92 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. It thus is93 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 somewhat broader 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. Some commentors claim95 Palm 10.96 Litigating States, Ex. A 18.97 Litigating States, Ex. B at 34-35.98 SBC 38 n.6; SIIA 18. 99 AOL 49-50, Klain 13; Palm 9-10; SIIA 19.100 54 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. The nature97 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. Others object to99 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. The reasons for the omission of these products from the definition vary. 100 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, AOL, Klain 13; Palm 9-10; Kegel 6.101 AAI 33-34; Giannandrea 7.102 55 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. And some lack the competitive101 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. These commentors point102 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 Litigating States, Ex. B 17, 28.103 Gifford 8.104 SBC 158.105 56 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. Another commentor suggests that “non-Microsoft software product” be replaced105 Pantin Comment VI.5, VI.3.106 Palm 9.107 Giannandrea 7.108 Stockton 2 (argues that middleware has very little to do with exposing APIs).109 57 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. The107 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. Nevertheless, the United States finds108 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 the case. Moreover, whether or not software has109 published APIs is completely within the control of the software developer. Thomas 5-6; Sen. Kohl 2; Palm 9; SBC 40-41, 159; ProComp 65-66; AOL 50; AOL,110 Klain 13-14; PFF 21; Litigating States, Ex. A 17-18; CCIA 85; Litan 50; RealNetworks 13-14; AAI 34; Giannandrea 7. Thomas 5-6; Sen. Kohl 2; Palm 9; SBC 40-41, 159; ProComp 65-66; AOL 50; AOL,111 Klain 13-14; PFF 21; Litigating States, Ex. A 17-18; CCIA 85; Litan 50; RealNetworks 13-14. Litigating States, Ex. A 18; AOL 50; AOL, Klain 14.112 AAI 34.113 58 E. “Non-Microsoft Middleware Product” (RPFJ § VI.N) 107. Several comments raise issues relating to the definition of Non-Microsoft Middleware Product. The majority of these comments relate to subsection (ii) of the110 definition, which requires that “at least one million copies” of the product have been distributed in the United States within the previous year. Other commentors complain that the definition111 does not include web-based software. Finally, one commentor questions whether Netscape112 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 59 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 Definition VI.A in the SRPFJ now reads: “‘API’ means application programming114 interface, including any interface that Microsoft is obligated to disclose pursuant to III.D.” Clapes 22; Litigating States 35 (offering own definition); ProComp B-2 (offering own115 definition). 60 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, Netscape Navigator would qualify as a Non-Microsoft114 Middleware Product. F. “Personal Computer” (RPFJ § VI.Q) 112. A few commentors raise concerns about the RPFJ’s definition of “Personal Computer.” See RPFJ § VI.Q. This definition is referenced in RPFJ Sections III.A115 (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 SBC 43, n.10.116 Maddux ¶ 58; Giannandrea 7.117 61 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. This concern is unwarranted. What Windows XP allows is116 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.” Apple’s machines do not contain “Intel x86117 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 of the RPFJ fully addresses this conduct by prohibiting such exclusive arrangements with certain entities, including ISVs — a category that unquestionably includes Palm 8-9, 14-15.118 Pantin 34.119 Maddux ¶ 58; Pantin 34; Alexander (unpaginated).120 62 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, which118 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. The United States disagrees with119 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. Moreover, such a change would be inconsistent with the120 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. KDE 15-16; Litan 51; ProComp 44-45; CCIA 65-67; SBC 38 n.5; Pantin 36;121 Giannandrea 6. For a discussion of issues relating to the intersection of the definition of Trademarked122 with the definitions of Microsoft Middleware and Microsoft Middleware Product, see Sections III(B) and III(C) above. ProComp 44-45; CCIA 65-67; Pantin 36; Giannandrea 6.123 63 G. “Trademarked” (RPFJ § VI.T) 116. A number of commentors address the scope of the definition of “Trademarked” in the RPFJ. Most of these commentors suggest that the definition is too broad and would permit121 Microsoft to evade its disclosure obligations under the RPFJ by manipulating its use of trademarks. Several commentors complain that basing the determination of whether a product122 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 ProComp 44-45; KDE 15-16; CCIA 65-67; SBC 38 n.5.124 See CCIA, at 66-67 (“Indeed, Microsoft could plausibly argue that the Windows125 Media® mark does not come within the ‘Trademarked’ definition as it is, since even that mark consists of no more than the Windows® mark in combination with the generic term ‘media.’ RPFJ § VI(T) may therefore embody Microsoft’s ‘disclaim[er of] any trademark rights in such descriptive or generic terms apart from the Microsoft® or Windows® trademarks.’”). 64 exempt many products from coverage by the RPFJ. The exception for generic and descriptive124 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. But this portion of the definition of Trademarked does not operate in that125 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 AOL 20 n.19; CCIA 53; Harris 12; KDE 12; Litan 43-44; ProComp 7; SBC 42; SIIA126 26; TRAC 8. 65 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. Microsoft could, these commentors126 CCIA 53.127 Litan 9, 43; RealNetworks 11; SIIA 25-27.128 Indeed, this sentence in Definition U merely confirms what Microsoft already had the129 power to do — label the package of what it calls its own operating system products. The sentence does not narrow or alter the operative provisions of the RPFJ; those provisions principally rely on other definitions, such as Microsoft Middleware Product, regardless of how Microsoft labels its operating system. 66 hypothesize, essentially “decide for purposes of the decree obligations where the OS stops and where middleware begins,” and thereby evade the decree’s technical provisions, including the127 disclosure provisions of Section III.D or the removal provisions of Section III.H.128 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. Thus, for129 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, AAI 29; CCIA 53; RealNetworks 11.130 Giannandrea 1-2; NetAction 2, 6-8; Pantin 36.131 67 or somehow to immunize Microsoft from potential liability for illegal tying. Such a reading is130 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 suggest that Definition U. also should include — in addition to131 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 Microsoft’s product website indicates that Windows 95 was designated as being in the132 “Non-Supported phase” (where licenses may no longer be available and support is limited) on November 30, 2001; Windows 98, Windows 98 SE, and Windows 4.0 will all enter the “Extended” phase (where licenses may no longer be available to consumers and support is somewhat limited) on June 30, 2002. See . 68 enter a phase of restricted availability. Windows Millennium Edition (ME), though much132 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. Kegel 6; SBC 42-43.133 SBC 43.134 69 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, and even operating systems used in “an extensive set of devices,” most with little or133 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. ProComp 56-57; CCIA 58-59; CCIA, Stiglitz & Furman 32-33; SIIA 56-60.135 SIIA 56-60.136 70 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-Microsoft Middleware Products. To correct this perceived problem in the RPFJ, one commentor135 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 SIIA 16; CCIA 54-55; AOL 15-16; ProComp 60.137 See Compaq Press Release, Dec. 12, 2001,138 . 71 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. Second, other OEMs may have been reluctant to start customizing their138 72 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. RealNetworks 24-25; AAI 25-34; SBC 91-100; Harris 4; Bast 2-3; Thomas 2-3; Red139 Hat 11-13, 16-18, 22-23; Alexander 2; KDE 13-14; CFA 88-89, 93-95; CompTIA 5; PFF 19; ProComp 55-60; Pantin 4-7; Palm 14-15; CCIA 85-87, and Stiglitz & Furman 31-32; AOL 34- 38; AOL, Klain 2-3; Nader/Love 1-6; Maddux ¶¶ 2-4; Sen. Kohl 4; Lococo 1. Nader/Love 2; CompTIA 5.140 SBC 97; Sen. Kohl 3-4; Nader/Love 2; AOL, Klain 2; Pantin 4-7; ProComp 59; PFF141 19; AAI 31-33. SBC 95-96, 99; Schulken 1; McBride 1 (should apply to Xbox).142 Palm 14; Red Hat 22-23; ACT 27.143 Sen. Kohl 4; Pantin 4-7; ProComp 59; CFA 88-89; Young 1.144 Pantin 6-7.145 RealNetworks 24-25; AOL, Klain 3.146 Pantin 4-7; Harris 4; Alexander 2; Godshall 1 (shipping PCs with a single non-147 Windows operating system); Miller 2; Hafermalz 1; Scala 1; Schulze 2; Peterson 3; Burke 2. 73 134. Commentors express several concerns about Section III.A. Although some139 commentors congratulate the United States for provisions that are procompetitive, represent real benefits to consumers, and take the club out of Microsoft’s hand, others believe that this140 section is not broad enough. Some commentors propose, for example, that the section be expanded to cover: (1) all software, including Microsoft Office; (2) entities other than141 OEMs; (3) threats of retaliation; (4) all forms of retaliation; (5) retaliation for any lawful142 143 144 acts undertaken by an OEM; (6) existing forms of non-monetary consideration and all145 monetary consideration; and (7) shipping PCs without an operating system. One commentor146 147 seeks to eliminate from Section III.A Microsoft’s ability to enforce its intellectual property rights Red Hat 11-13, 16-18, 22-23.148 AOL, Klain 3; CCIA 85-86; Pantin 6-7; Harris 4.149 SBC 97; ProComp 59; KDE 13.150 Maddux ¶ 5; AOL, Klain 3.151 SBC 96; Red Hat 16-17.152 Levy 1 (settlement adequate). This would include linking the price or terms of Office153 to the promotion of rival middleware. Doing so would represent an alteration in Microsoft’s commercial relationship with that OEM because of that OEM’s promotion of middleware. Section III.F addresses retaliation against ISVs and IHVs.154 74 through patent infringement suits. Commentors also believe that the Section does not protect148 OEMs from arbitrary termination of their Windows licenses. Commentors further claim that149 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. Finally, some commentors151 object to the RPFJ’s failure to define “retaliation.”152 1. Section III.A Is Sufficiently Broad 135. Section III.A is designed to prevent Microsoft from undertaking actions against OEMs that have the purpose and effect of impairing an OEM’s ability freely to choose to distribute and support middleware that may threaten Microsoft’s operating system monopoly. 153 See also CIS at 25. The Section is logically limited to retaliation against OEMs, as no154 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. “Consideration” is defined in Section VI.C. Briefly, Consideration includes such155 things as preferential licensing terms, support, product information, certifications, and permission to display trademarks, icons, or logos. 75 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 also drew155 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 The Internet site Yahoo! lists in its commercial directory a substantial number of156 retailers offering custom-built PCs, at least some of which will provide a computer without an operating system at a discounted price (for example, Discovery Computers). Many refurbished computers are offered without an operating system, as well. Moreover, component retailers offer replacement hard drives, also without an operating system. See also RPFJ § III.C.157 76 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 and sees no reason for156 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 “Covered OEM” is defined in Section VI.D.158 77 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. The RPFJ states expressly that158 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. 78 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 compensated for 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 Economides 12 (“this restriction can help avoid possible retaliation of Microsoft, so in159 the present context, it may be in the public interest.”). 79 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. By removing any mechanism for Microsoft to use such leverage, this provision will159 further permit OEMs to make their own independent choices without fear of retribution. Kegel 9; Schulze 2; Francis 1.160 SBC 136.161 80 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. The top twenty OEMs, however, together account for a substantial percentage, in160 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.” There is no rational basis161 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. SBC 101, 136; Herrmann 1; Timlin 3; Mitchell 2; Weiller 2; Clapes 5.162 For example, several commentors raise the specter of Microsoft offering OEMs MDA163 discounts on Windows licenses based on the number of copies of Office shipped by the OEMs. Kegel 9; CFA 12. But such discounts would be barred by the final paragraph of Section III.A, which forbids Microsoft from paying consideration with respect to one product based on an OEM’s distribution of a different Microsoft product. Section III.B.3 would then preclude an MDA for such a purpose, since it would be “otherwise inconsistent with any portion of this Final Judgment.” Similarly, the AOL comment erroneously asserts that the MDA provision would 81 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. This approach would be unnecessarily162 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. To avoid the risk of Microsoft163 allow OEMs that promote Microsoft products to receive MDA discounts that are denied to OEMs that deal with Microsoft’s rivals. AOL 35-36. Sony 2, 4. See also Litigating States’ Motion for Limited Participation in Light of the164 Deposition of Mr. Richard Fade, filed February 19, 2002, at 6-7, 19 (“Litigating States’ Motion”). In their Motion, the Litigating States seek an order that would permit them to participate in this Tunney Act proceeding for the limited purpose of submitting portions of the transcript of a Microsoft employee, Richard Fade, purportedly relating to the issues of Section III.B, the non assertion of patent provisions, and Section III.I.5. The United States’ Response to the Litigating States’ Motion did not object to participation in this one instance solely for the narrow purpose identified — adding the proffered information to the Litigating States’ public comment — but did object to any broader or continued participation. Microsoft filed its Response (“Microsoft Response”) on February 22, 2002, in which it did not oppose the 82 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 license terms 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. In these covenants,164 participation and submission, and to which it attached a declaration of Richard Fade (“Fade Decl.”). Because the Court has not yet ruled on the Motion, the United States will proceed to respond here to the substance of the information proffered in the Litigating States’ Motion. Sony 2; Litigating States’ Motion 6-7; Microsoft Response 4-5; Fade Decl. ¶¶ 11-16.165 Sony 4; Litigating States’ Motion 7.166 Sony 4.167 83 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. One of the commentors, Sony, urges a modification or166 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 SBC 102, 136.168 84 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. But such a regulatory168 mechanism is not necessary under the RPFJ. It requires that any volume discounts must be SBC 102-03; Drew 1.169 85 “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. The commentors argue that Microsoft169 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 CCIA 87-88; Turk.170 SBC 101-02, 136-37 (describing Litigating States’ § 2(b)).171 86 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. To the extent the commentors intend to assert that this170 limitation in Section III.B leaves Microsoft free to use discriminatory licensing terms or conditions for Office or other important Microsoft products in order to reward or punish OEMs for their actions regarding Microsoft and non-Microsoft Middleware, that assertion is wrong. Although Section III.B is limited to Windows Operating System licenses, the general anti- retaliation provisions of Section III.A are not so limited. See Section IV(B) above. Any attempt by Microsoft to alter the terms of any (not just the top twenty) OEM’s license for Office or any other product (or any other commercial relationship with that OEM) because that OEM is working with rival Platform Software or any product or service that distributes or promotes non- Microsoft middleware will be prohibited by § III.A. 7. Key License Terms 164. One commentor argues that the RPFJ should require Microsoft to provide OEMs and other licensees with equal access to "licensing terms, discounts, technical, marketing and sales support, product and technical information, information about future plans, developer tools or support, hardware certification and permission to display trademarks or logos." Otherwise, the171 commentor claims, Microsoft can keep such information secret and take advantage of licensees' SBC 136-37.172 SBC 136-37.173 87 ignorance about what terms are available. With respect to the top twenty Covered OEMs,172 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. But such a provision is both173 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 Pantin 8; Maddux ¶ 5.174 Levy 1 (Section III.C adequately prohibits Microsoft from preventing OEMs and175 consumers from installing rival operating systems or removing Microsoft middleware products and installing rival middleware). CIS at 29.176 CFA 95; Nader/Love 2; Pantin III.13; Novell 8.177 88 agreements. The United States believes that the limitation to agreements is appropriate in this174 section. The most obvious and effective means for Microsoft to restrict an OEM’s conduct is175 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. Use of other means by Microsoft to influence, limit, or reward the options of176 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 SIIA 22-23, Pantin 9.178 89 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 ProComp 10, 67.179 SBC 51, 138-39; Maddux ¶ 6; Pantin 9-11; Litigating States, Ex. A 10; Elhauge 8-9;180 Clapes 5-6; PFF 20. 90 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. To the179 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 requiring that 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. As explained in the CIS (at 30), “functionality” is180 SBC 52; CCIA 56; Maddux ¶ 7; Miller 2; Hofmeister 2.181 91 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.” Section III.C.2 applies only to shortcuts, but181 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 AOL 37; AOL, Klain 4; CFA 95; RealNetworks 23; Henderson 8-9; Litigating States,182 Ex. A 10; ProComp 64; CCIA, Stiglitz & Furman 28; Maddux ¶ 8; Pantin 9-11; Alexander 2-3; Giannandrea 3; Miller 2; Thiel 2; Schneider 2. Palm 14; AOL 37; AOL, Klain 4; CCIA 60; PFF 20; Pantin 9-11; RealNetworks 22;183 SBC 140; Waldman 3, 8; CCIA 59-60; Clapes 5; Schneider 1. 92 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.” This is not the intent182 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. Others say183 Litan 46, 50; CFA 95; SBC 52; Litigating States, Ex. A 10; ProComp 64; CCIA,184 Stiglitz & Furman 28; Giannandrea 3; Waldman 3; Hammett 2. ProComp 64; Pantin 9-11; Giannandrea 3; Rovero 3.185 93 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. Still others criticize that Section III.C.3 limits automatic launches to the boot-up184 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 SBC 52, 140; Godshall 1; Schneider 1-2.186 KDE 14; Pantin 11-14; Harris 5, CFA 89; CompTIA 5 (supports); Akin 2; Hafermalz187 1; Young 1. 94 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. The United States186 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 otherwise does not assist the OEMs’ ability to promote non- Microsoft operating systems. The United States partially agrees and partially disagrees with187 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 AOL 37-38, Klain 4; CCIA, Stiglitz & Furman 27.188 SBC 53; Akin 2.189 Maddux ¶ 9; SBC 52, 141; NetAction 10, 14; Schneider 2.190 95 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. At least one commentor notes that the Windows XP initial boot sequence offers a188 wide range of Microsoft products and services, including Passport, Hotmail, Instant Messenger, and Internet telephony. Some commentors predict that Microsoft will use the “reasonable189 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 SBC 53, 138.191 SBC 137.192 96 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. The191 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. The192 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. Litigating States’ Provision 4 additionally requires that Microsoft disclose all the193 necessary APIs, Communications Protocols and Technical Information to accomplish such modifications. 97 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. The breadth of this provision appears to require that Microsoft allow, and193 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. Palm 15; AOL, Klain 6; SBC 58; Thomas 6-7.194 SIIA 24; ProComp 62; Schneider 2.195 98 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. The United States believes that194 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. It is incorrect that195 exclusivity, at least as to icons and other visible means of end-user access, cannot be provided to CFA 98; Maddux ¶ 23; Clapes 9.196 99 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. Functionality is intended only to capture broad categories of products and not to196 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 Maddux ¶ 24.197 AOL 49; AOL, Klain 6; Litigating States, Ex. A 10; Pantin III.24; RealNetworks 14,198 17, 23; CCIA 55; KDE 14-15. 100 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. This is incorrect. The concept of non-discriminatory includes the concept of non-197 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, simply by198 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 Litan 45; ProComp 57-58; CCIA 55; AAI 15; Litigating States 10.199 101 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. More specifically,199 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 AOL, Klain 6; CFA 98-99 (“consumer must choose the Non-Microsoft product twice200 to make it the preferred option”); RealNetworks 18; Miller 3; Clapes 9-10. 102 that it did not have to respect default settings where Windows functionality enabled users to move seamlessly from one function to another in the same window. Microsoft, 253 F.3d at 67. 197. Moreover, these limitations are designed to ensure that access to defaults exists whenever the alternative Microsoft product would be launched as the full “product” (e.g., Internet Explorer as the Internet browser), rather than when just a portion of the product’s underlying functionality is launched to perform functions in Windows itself (such as code also used by Internet Explorer being used to display part of the Windows user interface), or otherwise where the end user might not necessarily be aware that he or she is using a specific Microsoft Middleware Product. 198. One of the most important functions of this Section III.H.2 is to provide certainty and a bright line regarding when Microsoft is obligated to provide and respect a default setting. Previously, Microsoft was under no obligation to provide for automatic invocations of competing products in any circumstances; Microsoft at its option provided for automatic invocations in some circumstances and not in others. Although commentors allege that there are numerous cases where Microsoft will not have to provide a default setting, the RPFJ does provide a clear line and a requirement, that did not exist before, that in some cases defaults must exist and must be respected. 199. Several commentors allege that Non-Microsoft Middleware Products are subject to a requirement that the end-user confirm his/her choice, but the Microsoft Middleware Product is not, making it effectively harder for users to choose Non-Microsoft Middleware Products. 200 103 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 Maddux ¶ 25; Pantin III.24.201 RealNetworks 17-18; CCIA 56; Maddux ¶ 27; Giannandrea 2; Gifford 4.202 SBC 58; Harris 7, 8.203 104 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. At least one commentor misreads this exception to infer that202 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 NetAction 14; Maddux ¶ 27; Gifford 4, Giebel 1; Miller 3; Akin 3; Hammett 2;204 Youngman 4. Pantin III.26.205 SBC 59; CCIA 56; Schneider 2.206 105 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. Concern also is raised204 that Microsoft is not required to document the “reasonable technical requirement” in advance in MSDN. Several commentors predict extreme and drastic results from the example of205 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.” Litan 45; RealNetworks 16; Henderson 9; CCIA 57; CCIA, Stiglitz & Furman28; KDE207 16; AAI 17-18; Maddux ¶ 26; AOL, Klain 6; CFA 99; SBC 56; Litigating States, Ex. A 10; ProComp 63; SIIA 18; Pantin III.25; Gifford 4; Giannandrea 3. 106 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. Some commentors207 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 107 “initial boot” before shipping a PC and hence the 14-day period could have largely 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 SBC 57.208 Drew 1; Thiel 2; Miller 3.209 108 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. The 14-day delay, after a new209 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 AAI 18.210 Litan 47; CCIA, Stiglitz & Furman 28; Maddux ¶ 21 (suggests 3 months); Giannandrea211 1-2. ProComp 65; CCIA, Stiglitz & Furman 28.212 109 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. The United States finds it unlikely that Microsoft would go to the210 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. Some commentors compare the 12-month delay to the less than 2 months it took211 Microsoft to remove the icons for Internet Explorer after the Court of Appeals’ decision.212 110 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 SBC 60.213 SBC 61-62.214 111 and did not remove many of the means of end-user access. To comply with the RPFJ, both in 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. The same commentor argues that, in contrast, the interim213 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 112 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 RealNetworks 16-17; Henderson 6; CCIA 56; PFF 21; Harris 7-8; Schulze 2.215 Pantin III.27.216 113 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. These commentors suggest that215 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 Kegel 5.217 114 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. This217 comment incorrectly commingles the seven-month timing requirement with exception (b) to Section III.H.2. The seven-month timing requirement relates solely to the issue of which Microsoft Middleware Products exist at a certain time; it does not have anything to do with whether any Non-Microsoft Middleware Products meet certain technical requirements. The seven-month timing requirement determines when a default setting is required to exist; exception (b) concerns the limited circumstances where, given that the default setting exists, the Windows Operating System Product may nevertheless ignore a designated Non-Microsoft Middleware Product. F. Commingling Of Operating System Code And Middleware Code 225. Sections III.C and III.H of the RPFJ remedy Microsoft’s anticompetitive commingling of browser and Windows operating system code by requiring Microsoft to redesign its Windows Operating System Products to permit OEMs and end users effectively to remove access to Microsoft Middleware Products (Section III.H.1) and to allow competing middleware to be featured in its place (Section III.C). Section III.H also requires Microsoft to create a AAI 13-14; AOL 2-3, 17-24; CCIA 45-46; Sen. Kohl 4; Litan 42-45; ProComp 31-33;218 RealNetworks 20-21; SBC 46; TRAC 9. AOL 17, 20; SBC 45.219 115 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. They note218 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. In fact, however, the IFJ’s anti-binding provision, Section 3.g, only required that219 Some commentors suggest the reason the IFJ did not require actual removal of220 middleware code from Windows was because the IFJ’s conduct restrictions were intended to be merely transitional, until the breakup of Microsoft could be effectuated. As a result, the argument appears to go, the anti-binding provision did not need to be as extensive or invasive as it would have been in the absence of a structural remedy. But the commentors cite no support in the Plaintiffs’ prior remedy submissions or the IFJ itself for this claim. In fact, the need to remedy Microsoft’s integration of middleware in Windows in a non-removable way was just as strong during the interim conduct remedy period of the IFJ as it is under the RPFJ. Professor Felten stated in part in the cited remedy declaration:221 To comply with the product Binding provision, Microsoft’s future Windows Operating System Products must allow OEMs and end users ready means for removing End-User Access to any Middleware Product. I will use the term ‘Unbinding’ to refer to the development of the means of removing End-User 116 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 Access to a Bound product. Declaration of Edward Felten (“Felten Decl.”) ¶ 92 (filed April 28, 2000) (emphasis added). Various commentors also seek to draw contrasts between the RPFJ and the so-called222 “Mediator’s Draft #18" from the Spring 2000 mediation process with Judge Posner. See, e.g., AOL 17 & n.14. Such attempts at comparison or contrast are fundamentally flawed and therefore of no value in assessing the RPFJ. First, that mediation process was and remains confidential; there has been no authentication of any of the documents now available publicly that purport to represent mediation drafts. Second, the draft in question is itself styled as a “Mediator’s Draft;” there is no basis on which to conclude, other than unsubstantiated newspaper articles cited in the comments, that it reflects an actual proposal approved or submitted by any party or that any party ever was willing to agree to it. Third, purported settlement positions from early 2000 indicate nothing about the adequacy of the RPFJ today. The litigation was at a fundamentally different stage. The District Court had issued extensive Findings of Fact that highly favored the United States’ presentation of evidence, but the District Court had not yet issued its Conclusions of Law, let alone had the Court of Appeals reviewed and modified the District Court’s liability determination. 117 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 See, e.g., Findings of Fact, ¶ 159 ("the inability to remove Internet Explorer made223 OEMs less disposed to pre-install Navigator . . . Pre-installing more than one product in a given category . . . can significantly increase an OEM's support costs, for the redundancy can lead to confusion among novice users. In addition, pre-installing a second product in a given software category can increase an OEM's product testing costs."). AOL 22-23; Litan 45.224 118 concern primarily with the confusion and exclusion caused by the visible presence of Microsoft’s middleware and rival middleware. For example, in describing Microsoft’s initial commingling223 in Windows 95, the District Court found: Although users were not able to remove all of the routines that provided Web browsing from OSR 2 and successive versions of Windows 95, Microsoft still provided them with the ability to uninstall Internet Explorer by using the “Add/Remove” panel, which was accessible from the Windows 95 desktop. The Add/Remove function did not delete all of the files that contain browsing specific code, nor did it remove browsing-specific code that is used by other programs. The Add/Remove function did, however, remove the functionalities that were provided to the user by Internet Explorer, including the means of launching the Web browser. Accordingly, from the user’s perspective, uninstalling Internet Explorer in this way was equivalent to removing the Internet Explorer program from Windows 95. Findings of Fact, ¶ 159 (emphasis added). The District Court went on to find that, even with commingling of code, “[i]f OEMs removed the most visible means of invoking Internet Explorer, and preinstalled Navigator with facile methods of access, Microsoft’s purpose in forcing OEMs to take Internet Explorer — capturing browser usage share from Netscape — would be subverted.” Id. ¶ 203. 230. In spite of this clear basis for the District Court’s and Court of Appeals’ conclusions, some commentors assert that the mere fact of commingling itself deters OEMs from installing rival middleware. Other commentors ignore the basis of the courts’ commingling analyses and224 argue that the competitively significant component of Microsoft’s integration is the resulting Litan 44; RealNetworks 20-21.225 AAI 14-15; AOL 21-22; CCIA 49-51; Litan 44; ProComp 61-62.226 119 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. They argue that Microsoft’s ability to obtain, through integration225 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. Usage is only a means to an end, they argue, with the end being the widespread226 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 Some comments correctly note that a flat ban on commingling might prevent Microsoft227 from adding new, innovative features to Windows, a result that would not be in the public interest. Economides 9; Johnson 3-4. AAI 15-16.228 120 software design that could have adverse implications for consumers. Moreover, changes to the227 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. But this228 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, CCC 22; Elhauge 1-2; Sen. Kohl 4.229 Elhauge 6.230 Moreover, as Professor Felten testified in his prior remedy declaration, requiring that231 end users and OEMs be able to remove end-user access to Microsoft Middleware Products would itself result in improvements in the efficiency and reliability of Windows. Felten Decl. ¶ 97 (“Section 3.g would require Microsoft to undo the illegal product Binding in which it has already engaged, and to refrain from further Binding of Middleware Products to Operating Systems. This will lead to improvements in the efficiency and reliability of Windows.”). 121 by causing decreased reliability or increased susceptibility to security risks. As one commentor229 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. Rather, the exclusionary character of commingling in a non-removable fashion230 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 SBC 48-49. SBC notes that IFJ § 3.g.ii contained a such a provision. Id.232 253 F.3d at 96.233 Id. at 68.234 122 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. There is no basis for such a provision under the232 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. Second, the Court233 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. Relpromax 17-18; Economides 12 (disagrees with this concern).235 ACT 25, 29 (Section III.F adequately forbids retaliation against ISVs and IHVs).236 Sun 15-16.237 SBC 96-97; CCIA 87 (addressing only specific type of retaliation, e.g., Microsoft’s238 threat to discontinue porting Office to Mac OS unless Apple stopped supporting Netscape). 123 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, or support 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. The United States235 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. Injunctive relief cannot turn back the clock, but it236 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. But238 Palm 14; ProComp 34.239 ProComp 34.240 124 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. But because the RPFJ prohibits retaliation itself,239 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. Such a provision would be inappropriately240 vague, making the legality of Microsoft’s actions dependent in part on the perceptions of the “coerced” ISV or IHV. Red Hat 7-8, 10-13; see also the discussion of the concerns of the open source241 community, below. On a side note, the commentor is mistaken in asserting that Section III.F.3 expressly242 permits Microsoft to sue for infringement if an ISV or IHV takes any of the actions protected from retaliation under Section III.F.1. Red Hat 7. Section III.F.3 simply says that Microsoft may enforce agreements or intellectual property rights so long as by doing so it does not violate any provision in the RPFJ. Litigating States, Ex. A 13-14; SBC 95-96; Pantin 14-15.243 125 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. The241 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. Such additions are243 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. SBC 97; Pantin III.17; CCIA 86; PFF 18-19; Akin 3.244 Harris 6.245 126 244. Fourth, commentors suggest the prohibition should ban retaliation related to a broader class of software than that contemplated in Section III.F.1. They argue that Microsoft244 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. The RPFJ does, in fact, give firms such protection: Section III.A.3245 (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. SBC 99; Litigating States, Ex. A 16.246 SBC 98; CFA 97; Maddux ¶ 1; Pantin III.17; CCIA 82; Akin 3.247 127 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. For a discussion of the merits of including a provision that246 prohibits retaliation for participation in this litigation, see Section XI(G) below. B. Comments On Section III.F.2 247. Section III.F.2 prohibits agreements relating to Windows Operating System Products that condition the grant of Consideration (a defined term in the RPFJ that encompasses both monetary and nonmonetary benefits) on an ISV’s refraining from developing, using, distributing, or promoting the same kinds of software addressed in Section III.F.1 — software that competes with a Windows Operating System Product or a Microsoft Middleware Product or software that runs on any such competitive software. A limited exception permits Microsoft to enter such agreements if they are “reasonably necessary to and of reasonable scope and duration in relation to a bona fide contractual obligation of the ISV to use, distribute or promote any Microsoft software or to develop software for, or in conjunction with, Microsoft.” 248. Several commentors argue that the language of this exception is vague and subject to abuse by Microsoft, allowing it to prevent ISVs from entering partnership and other agreements with rival firms. Microsoft, however, may only enter agreements that limit the ISV’s activities247 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, AAI 26-27, 35-36.248 Litan 47-48; see generally CCIA 88; Elhauge 12.249 128 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. There is a necessary trade-off in an injunctive provision, and in exemptions249 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. Harris 6.250 SBC 98-99.251 129 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. It is correct that Section III.F.2 only applies to agreements signed after the250 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. The commentor’s concern is addressed not in Section III.G, but here in251 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. SBC 98; also see the discussion in Section III.F.1, supra. 252 SBC 98-99.253 130 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. Section III.F.3252 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. Although Section III.G does not cover such253 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- SBC 105-06, 152; RealNetworks 30-31; Harris 7; Clapes 7.254 SBC 106-07, 153.255 One commentor’s concern appears to reflect a misunderstanding of the purpose of256 Section III.G.2. Observing that the provision prohibits Microsoft from granting placement to an IAP or ICP on the condition that the IAP or ICP refrain from activities with any software “that competes with” Microsoft Middleware, the commentor questions whether the provision would have protected Netscape’s Navigator during the period before Microsoft introduced Internet Explorer. See PFF 19-20. By implication, the commentor questions whether Section III.G.2 adequately will protect future nascent middleware. But Section III.G.2 prohibits certain conditioned contracts; if Navigator did not compete with IE because IE did not exist, then Microsoft would have no reason to give an IAP benefits on the condition that the IAP not use Navigator. And that is what the historical record shows: Microsoft did not impose the unlawful IAP contracts in the early, pre-IE days of Navigator, but rather started to impose them in late 1996 at a time when Microsoft was trying to build IE’s usage share. See Findings of Fact, ¶¶ 256-62. The current wording of Section III.G.2 adequately prohibits Microsoft from taking action against threatening products. 131 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). In a similar vein, one of the same254 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. Since the time of the June 2000 IFJ, of course, the Court of255 Appeals has ruled on liability — narrowing the District Court’s ruling and vacating the IFJ itself. The language of RPFJ Section III.G does prohibit the kinds of agreements — e.g., between Microsoft and IAPs — that the Court of Appeals found to be unlawful.256 257. Several commentors contend that, unlike the Litigating States’ Proposal (§ 6), RPFJ Section III.G covers Microsoft’s contracts with only named categories of trading partners and SBC 104-05, 151-52; CCIA 59 n.12.257 Economides 11.258 SBC 107; Litigating States, Ex. A 12 (point 14).259 CFA 97.260 132 may omit others who are important, e.g., large corporate end-user purchasers. Section III.G.1257 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. End users, including258 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. The representation of “commercial practicability” by a260 SBC 152.261 AAI 26; Harris 7.262 Pantin 16.263 133 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. The provision merely describes the261 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. But262 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. Further, the “good faith” requirement ensures both that Microsoft cannot263 make a representation of commercial practicability a standard part of its license agreements and CCIA 89.264 Litan 48.265 134 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. Section III.G.1, however, makes it logically impossible for Microsoft to seek —264 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. This contention, however, overlooks the exemption’s265 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 CCIA 88-89; AOL 36; AOL, Klain 5.266 CFA 98; Litigating States, Ex. A 12 (point 14); RealNetworks 30-31.267 135 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. What constitutes a “significant” resource is not spelled out in267 the RPFJ because it is a familiar term and concept in antitrust enforcement. For example, the Antitrust Guidelines for 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 ProComp 67-88; SBC 53; Maddux, Point 20; Harris 6.268 SBC 107.269 Pantin 17.270 136 merely by characterizing the agreements as “joint” activities. As the Court of Appeals found268 (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 that the United States objected in June 2000 to269 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. Both the United States and the courts consistently have270 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 SBC 153; RealNetworks 31; Pantin 17-18; Giannandrea 5; Harris 6.271 137 property in from a third party.” The exception permits Microsoft, in licensing new technology271 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 Litan 51; NetAction 12; ProComp 42-43; CFA 96; RealNetworks 11; CCIA, Stiglitz &272 Furman 30; CCIA 63. 138 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. a. 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. Some misunderstand the272 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. AAI 20.273 Alexander 3, 4; Carroll 4; Johnson 5; Gifford 5, 9; Litan 51; Kegel 18; Pantin 12; PFF274 20; ProComp 38; CCIA 62. KDE 13.275 AAI 19; CCIA 62; CCIA, Stiglitz & Furman 29; SIIA 31-32.276 Economides 11.277 139 274. Another commentor argues that Microsoft can evade disclosure by removing the APIs from a Windows Operating System Product. This is illogical. If the APIs are not in273 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. Some argue that all Microsoft applications that run on Windows, for instance,274 Office, should be covered. Others argue that software that never has been distributed275 separately should be covered. Still others phrase the argument in terms of disclosing “all Windows APIs.” Others find the limitation to Microsoft Middleware to be appropriate.276 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 ProComp, Arrow A-29.278 CCIA 60-61.279 140 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.” The278 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. Microsoft’s disclosure of APIs is what279 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 CCIA 62; ProComp 38; CFA 96.280 141 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. To the contrary, there is no requirement that any Non-280 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. Litigating States, Ex. A 8; Palm 6-7; Pantin 12-13; ProComp 39; AOL 39-40; CCIA,281 Stiglitz & Furman 43. Giannandrea 2; Moglen 3-4.282 Moglen 2; Kegel 8; Maddux ¶ 11; ProComp 39.283 CCC 11; Kegel 14-18.284 142 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. Specifically, some opine that interfaces to other devices, such as handhelds or set-281 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. For instance, some commentors argue that the disclosure should be282 for any purpose, and not just “for the sole purpose of interoperating with a Windows Operating System Product.” Some focus on the potential use of these APIs by other operating system283 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 AAI 34.285 143 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. Specifically, the definitions of Non-Microsoft285 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 Final Judgment to the Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs, for the sole purpose of interoperating with a Windows Operating System Product, via the Microsoft Developer Network (“MSDN”) or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to Kegel 5, 8, 12; Maddux ¶ 12; Litigating States, Ex. B 31; Carroll 2, 4, 5; Johnson 2, 5-286 6; SBC 78; KDE 13; Pantin 30. ProComp 46.287 144 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. In particular, several argue that it should include file and document formats. As286 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. In general, this is correct — the definition was designed to287 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. Kegel 18; SIIA 30-31.288 RealNetworks 27.289 Palm 10 (hardwiring); AOL, Klain 4 (hardwiring).290 145 286. Some commentors believe that APIs should include calls from a Windows Operating System Product to Microsoft Middleware, instead of the other way around. For instance, one288 commentor argues that the “Play All” and “Burn CD” interfaces in Windows XP should be disclosed. These concerns are more appropriately addressed under the default provisions in289 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 Litigating States, Ex. A 7, 9, Ex. B 36; Pantin 12; SIIA 29-30; SBC 79; RealNetworks291 15; CCIA 70-71; ProComp 47; AOL, Klain 5. 146 should be broader. Despite the many comments on this issue, the United States believes the291 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. Maddux ¶ 13 (Microsoft should be required to publish on Slashdot (slashdot.org) and292 Freshmeat (www.freshmeat.org). Pantin 11-13.293 147 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. Taking the opposite approach, another commentor argues that Microsoft only292 should be allowed to disclose via MSDN. MSDN at present is widely used by developers who293 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. Johnson 6; Novell 18. 294 Maddux ¶ 12.295 148 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. The United States believes that the enforcement mechanisms of the294 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. Several other295 commentors complain that the RPFJ provides no access to source code for competitors, as was Litigating States’ Proposal § 4; Litan 53; CCIA 70.296 149 previously contained in the interim conduct remedies in the form of a “secure facility” provision. Instead, source code access is granted to the Technical Committee, accomplishing296 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 KDE 13; Waldman 5; Kegel 8.297 150 [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. These commentors argue, for instance, that297 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., SBC 81; Kegel 7-8; Sen. Kohl 5; Litan 57; Maddux ¶ 10; Litigating States, Ex. A 8-9;298 Palm 13; ProComp 51-52; Alexander 2; AAI 23; CCIA 83; CCIA, Stiglitz & Furman 30; CFA 96; RealNetworks 29-30. 151 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 of certainty 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 152 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 ProComp 48.299 153 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, the phrase “last major beta test” has a specific meaning to Microsoft in terms of its299 testing and release schedule. AAI 22; Litan 50; Kegel 7-8; Pantin 12; NetAction 10, 13; Alexander 3; Novell 19;300 Maddux ¶ 14; SBC 81-82; CFA 96. 154 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. As a300 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. AOL, Klain 14; AAI 22; ProComp 48; SIIA 31; Litan 50; CCIA 84; CFA 96;301 Giannandrea 7. 155 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 to150,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 subscription offering 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 ProComp 48; Palm 13; SIIA 31; Novell 19; Relpromax 12; RealNetworks 12.302 Henderson 6-7; Novell 19; Litan 50; Palm 13; CFA 96; CCIA 84-85; AAI 22;303 Litigating States, Ex. A 7-9; Alexander 3. AOL, Klain 14; Litigating States, Ex. A 7-8.304 156 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. Microsoft,302 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. Some note that the slow release of Windows 95303 APIs to Netscape is precisely how the district court found that Microsoft retaliated against Netscape for refusing Microsoft’s market division proposal in 1995. In the extreme, at least304 one commentor contends that Microsoft could delay disclosure until after the deadline for third- Kegel 12-13; Burke 1; Peterson 2.305 157 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 AAI 36-37; SBC 72-73; Giannandrea 4; Alexander 003; Palm 7; ProComp 54.306 158 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. This is incorrect. Section III.E encompasses Communications Protocols306 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 Alexander 003.307 KDE 10-11.308 ProComp 54; SIIA 34; CFA 96-97; CCIA 69-70; AAI 37.309 See .310 159 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. Such308 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. b. 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. The RPFJ’s phrase “Microsoft server operating system product” was a change from309 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, and its successors. And310 although it was intended to encompass all software functionality that was shipped within the See .311 160 Windows 2000 Server product, including such software as IIS and Active Directory, arguably it might 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, a much broader class of server products. 311 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”). c. 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 ProComp 52; Palm 5.312 Moglen 2-3; Kegel 15; Maddux ¶ 16.313 161 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, AOL, Klain 9-10; SBC 76.314 CCIA, Stiglitz & Furman 43; Litigating States, Ex. A 8; SBC 77; Palm 6-7.315 162 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. d. 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. Pure server-to-server314 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. e. 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. For all of the reasons discussed above concerning server-to-server315 communications, and communications to non-Microsoft client operating systems, communications to devices such as handhelds are outside the scope of the case. CCIA 69; ProComp 53; SIIA 33; AOL, Klain 9; Alexander 4; Giannandrea 4, 6; CCC316 17-18; Maddux ¶ 17. AOL, Klain 9 (limited to Windows 2000 server, excludes the Internet); Maddux ¶ 16317 (remote administration protocols excluded). 163 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.” Several comments appear to focus on the previous definition in316 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, CCIA 69; SIIA 34; Sun 26-30; Palm 10.318 Sun 28-29.319 164 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 third parties. 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. Specifically, one commentor318 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 165 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 Litigating States, Ex. A 9.320 The CIS sets forth some non-exhaustive examples where Communications Protocols321 must be made available to permit seamless interoperability, including the Communications Protocols used between Microsoft Internet Information Services web server or Active Directory directory server and Internet Explorer or other functionality in the Windows Operating System Product; between server networking services such as Windows server message block protocol/common Internet file system protocol, and the Windows Operating System Product; and between server-hosted code and a runtime environment in the Windows Operating System Product, such as Java virtual machines or Microsoft’s common language runtime. It also permits interoperability between Microsoft servers and the digital rights management and other security mechanisms utilizing Microsoft’s implementation of Kerberos in the Windows Operating System Product, subject to a narrow exception in Section III.J.1.a, permitting limited withholding of information necessary to protect particular installations (e.g., keys and tokens particular to a given installation). See CIS at 38-40; see also discussion of Section III.J.1.a, infra. 166 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. Because the320 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 SBC 70-72.322 167 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. This is incorrect. The parenthetical expression that begins with “i.e.” is an explanation322 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 server operating system product,” discussed ProComp 52-53; Harris 6.323 Thomas 4-5; Waldman 5; Maddux ¶ 16.324 168 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. Allowing324 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. ProComp 55; Giannandrea 1; SIIA 35.325 Palm 13; Litan 57; Litigating States, Ex. A 8-9; RealNetworks 29; Maddux ¶ 15; CCIA326 83-84; Sun 36. 169 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. To the contrary, Section III.E covers in part “any325 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. The purpose of this delay is to allow Microsoft to326 Sun 36-37.327 CCIA 83-84.328 170 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. Although this might be true in some cases, the effect is lessened here327 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. This criticism is largely incorrect in that the nine months began running as of328 November 6, 2001, meaning that the disclosure and licensing must occur by not later than Litan 53.329 See, e.g., RPFJ §§ III.D and III.E.330 SBC 85-86; Litigating States, Ex. A 15; CCIA 81; Sun 35; Giannandrea 5; Moglen 2;331 Waldman 4. 171 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. To the contrary, the lack of a329 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. The goal of330 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. Another group of commentors takes issue with Section III.I.3’s restrictions on331 AOL, Klain 7; CCIA 81; Moglen 2; Giannandrea 5; Harris 8.332 Henderson 8; SBC 87-88; CFA 88; ProComp 51; AOL, Ex, B. at 7; SIIA 36-37;333 Litigating States 15; AAI 28-29; CCIA 81-82; Sun 38; RealNetworks 29; Giannandrea 5; Alexander 3; Harris 8; Maddux ¶ 10. Kegel 8; Maddux ¶ 9.334 Sun 35-36.335 SBC 85-86.336 172 sublicenses. Many commentors raise concerns relating to Section III.I.5 and Microsoft’s332 ability to require a cross-license of certain intellectual property rights pursuant to that subsection. Several commentors also argue, to varying degrees, that the scope of Microsoft’s333 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 notes that in June 2000,336 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 SBC 86.337 The other allegedly inconsistent prior statements cited by this commentor (SBC 86) do338 not withstand scrutiny. These statements concerning royalty-free licenses all were made in the narrow context of providing divested entities access to necessary technical information. See United States Reply Memo at 27-29 (discussing Western Electric for the proposition that was precedent to support the United States’ divestiture request; relying on AT&T as an example of a prior structural remedy in a monopolization case that did not involve mergers); United States v. Western Elec. Co., 569 F. Supp. 1057, 1118 (D.D.C. 1983), aff’d sub nom. California v. United States, 464 U.S. 1013 (1983) (discussion of royalty-free licenses centered around effectuating the divestiture of the Regional Bell Operating Companies and ensuring that the divestitures did not result in “balkanized regional networks” and “fragmentation” to the “detriment of all users”); United States v. General Electric, 115 F. Supp. 835, 844 (D. N.J. 1953) (“General Electric’s attempt to maintain control over the lamp industry has been largely by way of extending its basic patents on lamps and lamp parts. To compel the completely free use of these patents is not to impose upon General Electric and other defendants penalties for misuse of patents and violation of the antitrust laws, but rather to check the intrusion of advantages thereby gained into the mechanics of competition in the lamp industry.”). Here, the United States does not believe that the circumstances support royalty-free licensing. Compulsory licensing, but with a reasonable royalty, will be sufficient to achieve the remedial goal of ensuring access to necessary information for interoperability. 173 Information (as such terms were defined in the IFJ). See Summary Response to Microsoft’s337 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, AOL, Klain 7; CCIA; Moglen 2; Giannandrea 5; Harris 8; Pantin 22.339 Giannandrea 5; Harris 8.340 Pantin 22.341 174 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. These comments suggest that the restriction on sublicenses339 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. Another340 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 Henderson 8; SBC 87-88; CFA 88; ProComp 51; AOL Ex. B at 7; SIIA 36-37;342 Litigating States 15; AAI 28-29; CCIA 81; Sun 38; RealNetworks 29; Giannandrea 5; Alexander 3; Harris 8; Maddux ¶ 10. 175 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. The United States and Microsoft have agreed to delete this342 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 Kegel (unpaginated).343 Red Hat 11-12.344 Id.345 Maddux ¶ 9.346 176 APIs . . . .” Another commentor objects to the portion of Section III.I.2 that clarifies the scope343 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. This commentor suggests that Microsoft should be precluded from344 bringing infringement suits against an entity that licenses Microsoft intellectual property under the RPFJ, even when that licensee infringes other Microsoft intellectual property to which the entity does not have a license. Finally, one commentor expresses skepticism that Microsoft345 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. Litigating States’ Proposal § 15(b).347 177 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. AAI 22; AOL 40-41; AOL, Klain 7-8, 10; Catavault 12-13; CCIA 16, 72-77; CCIA,348 Stiglitz & Furman 30; CFA 99; Elhauge 12; Red Hat 25-28; SBC 88-89; SIIA 35-36; Sun 32-33; Alexander 3; Giannandrea 4; Gifford 5; Harris 8-9; Johnson 8; Moglen 4-5; Waldman 6; KDE 14; Litan 52; Litigating States, Ex. A 16, Ex. C 18; Nader/Love 2-5; Maddux ¶ 30; NetAction 11; Novell 20-21; ProComp 49-50, 55. 178 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. Commentors argue that348 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 179 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 Alexander 3. 349 Harris 9.350 180 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 not obligated 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. This section is appropriate and important for public security purposes, and350 limited to cases in which a government agency of competent jurisdiction directs Microsoft not to document, disclose or license specified information. AAI 23; CCIA 77-81; CFA 100; Henderson 7-8; Red Hat 28-29; SBC 88-91; SIIA 36;351 Alexander 3; Giannandrea 4-5; Carroll 2; Harris 9; Moglen 4-5; Waldman 6; KDE 12; Sen. Kohl 3; Litan 52; Litigating States, Ex. A 16-17; Nader/Love 2-5; Maddux ¶ 31; Pantin III.33-34; ProComp 50-51. AOL 41-42.352 181 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. One commentor, in contrast, finds that Microsoft’s legitimate security351 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 182 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. Kegel 8; Nader/Love 1; Pantin 12; SBC 79; CCC 21; Johnson 2; Alexander 5; Carroll353 4; Maddux ¶ 14. CCC 17; SIIA 38, 39.354 183 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). A file354 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 184 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 disclosed because 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 CCIA 89-92; AOL 50-53; ProComp 75-77; Litan 54-55; RealNetworks 31-32; Red Hat355 30-31; Nader 5; Waldman 5, Sen. Kohl 5; SBC 111-13, 157-58. 185 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. These allegations are meritless.355 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 186 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., AT&T, 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. AAI 42; Maddux ¶ 35.356 The RPFJ’s discussions of additional factors such as “systematic” or “knowing”357 violations are not intended to change the scienter or other elements that must be shown in actions to enforce the RPFJ through contempt charges. See, e.g., United States v. NYNEX Corp., 8 F.3d 52, 54-55 (D.C. Cir. 1993) (setting forth the elements of contempt, applied to antitrust decree). In particular, it is clear that a party to a decree may be found guilty of criminal contempt if its contumacious behavior was “willful.” Willful intent for purposes of contempt may be shown by proof that a defendant “acted with deliberate or reckless disregard of [its] obligation under the” order. United States v. Young, 107 F.3d 903, 909 (D.C. Cir. 1997); see also United States v. Greyhound Corp., 508 F.2d 529, 532 (7th Cir. 1974) (in context of antitrust decree, holding that willful element can be proven by evidence of either deliberate or reckless conduct). 187 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. To the356 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 ), or systematic violations357 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 CCIA 89-92; AOL 50-52; ProComp 75-77; Litan 54-55; RealNetworks 32; Palm 15-358 16; Red Hat 30-31; Nader/Love 5; Waldman 5; Sen. Kohl 5; TRAC 9; Harris 9-10; Drew 1; Young 3; Clabaugh 1; Schulken 2. 188 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 as inadequate, a detailed358 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 One comment erroneously implies that permitting Microsoft to have counsel present359 when its employees are questioned by the TC somehow would allow Microsoft to thwart the discovery of violations. See Nader/Love 5. To the contrary, this right is also present in conjunction with informal interviews or “on the record” depositions by Plaintiffs; is a standard part of all such provisions in antitrust consent decrees in recent years; protects against impermissible ex parte contacts; and protects Microsoft’s legitimate privileges and basic principles of due process. As some comments point out, the TC cannot share confidential Microsoft information360 with third parties. E.g., Gifford 5; Gianndrea 6. This will prevent third parties from using the TC as a way to in essence improperly expand Microsoft’s disclosure obligations under the RPFJ. For example, the TC will have access to all of Microsoft’s source code, including source code for software products not directly at issue in the case, and will be able to evaluate all APIs, even those not necessarily related to middleware. If the TC was free to disclose such items to third parties, it would in essence permit the wholesale looting of Microsoft’s intellectual property, thus changing the fundamental nature of the carefully limited, negotiated settlement that led to the submission of the RPFJ to the Court. 189 plaintiff States in their enforcement investigations and actions. The TC even has the right to359 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 CCIA 91; AOL 51; Litan 55; ProComp 76; Harris 10; Gifford 5; Alexander 4;361 Waldman 5; Clapes 19; Godshall 2; Hammett 1. As one commentor supporting the RPFJ noted in observing that the TC will “also have362 the authrity [sic] to resolve disputes about Microsoft’s compliance,” “this panel should not be used as a regulatory body.” Economides 11. 190 385. Some comments criticize the restriction on direct use of the TC’s reports and conclusions in enforcement actions. This direct use restriction has two purposes: First, by361 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. Rather, the TC has a “dispute362 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- CCIA 90; Red Hat 30.363 Nader/Love 5; Litan 55; AOL 51; Alexander 4; Gifford 6; Young 3; Morrissey 2;364 Clabaugh 1; Cheetham 1; Spotswood 1; Akin 4; Godshall 1-2. 191 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. The RPFJ sets forth a baseline of technical expertise because it is essential that the363 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. Many of these comments fail to appreciate that Plaintiffs, not364 Microsoft, control the TC. Harris 9-10; Gifford 5.365 192 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 to behave 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, TC members are subject to365 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. Nader/Love 5 (suggesting that the TC might be “playing golf” with Microsoft366 executives instead of investigating anticompetitive activities); Young 3. One comment (Gifford 6) questions whether, in the event of disagreements on the TC367 as to whether violations have occurred or been adequately cured, an individual member could submit dissenting views to Plaintiffs. The RPFJ does not require that the TC’s reports be unanimous or reflect only the majority’s views and conclusions. Further, there is no bar to an individual TC member communicating directly with Plaintiffs at any time. 193 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. The hiring of additional367 194 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 Palm 16.368 SBC 158; Clapes 18.369 195 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. The RPFJ provides the TC with the ability to receive and evaluate368 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. See RPFJ369 § IV.C.3; Litigating States’ Proposal § 17. Although a provision similar to the Litigating States’ 196 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 education and 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 RealNetworks 32.370 SBC 112-13; AOL 51-53; TRAC 9; Novell 30; RealNetworks 32; Red Hat 30-31; SBC371 157. 197 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. Compare RPFJ § IV.B.8, with Litigating States’ Proposal § 18. 371 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. 198 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. See, e.g., United States v. Smith Int’l, 2000-1 Trade Cas. (CCH) ¶ 72,763 (D.D.C.372 2000) (criminal and civil contempt); United States v. Microsoft Corp., 147 F.3d 935 (D.C. Cir. 1998) (“Microsoft II ”) (civil contempt and preliminary injunction in enforcement of earlier Microsoft decree, inter alia, finding nonconsensual referral to special master to be abuse of discretion); United States v. NYNEX Corp., 814 F. Supp. 133 (D.D.C.) (criminal contempt of AT&T decree), rev’d, 8 F.3d 52 (D.C. Cir. 1993); United States v. Twentieth-Century Fox Film Corp. 1990-1 Trade Cas. (CCH) ¶ 69,060 (S.D.N.Y. 1990) (criminal contempt); United States v. Western Elec. Co., 1989-1 Trade Cas. (CCH) ¶ 68,421 (D.D.C. 1989) (civil enforcement consent order to resolve allegations of AT&T decree violations in lieu of contempt). Indeed, it is not clear from the Litigating States’ Proposal whether the delegation to the373 special master of fact-finding powers is sufficiently circumscribed. Cf. Microsoft II, 147 F.3d at 953-56 (mandamus appropriate for court’s overbroad special master referral violative of both U.S. Const. Art. III and Fed. R. Civ. P. 53(b)). Novell 30; Nader/Love 5; Sen. Kohl 5.374 RealNetworks 32; ProComp 76; Litan 55; AOL 50-53; AAI 40-41 (generally).375 199 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. Likewise, no court has successfully372 delegated its inherent powers of antitrust judgment enforcement as completely as proposed here. The comments supporting this radical deviation from established practice cite no373 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. The TC and other supplemental dispute375 resolution processes, however, are not mandatory; they in no way constrain the ability of the Specifically, the Litigating States’ Proposal requires Microsoft to provide 60-days376 written notice of direct or indirect acquisitions or investments by Microsoft or any of its subsidiaries, as well as notice of any exclusive intellectual property licenses granted to Microsoft or any of its subsidiaries. The requirement applies to transactions involving businesses of which Microsoft did not own 33% or more prior to December 1, 2001, and which fall into one of several categories related to computer software and equipment, computer systems design, telecommunications, and network industries. See Litigating States’ Proposal § 20. 200 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 transaction reporting 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 201 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. CCC 26; CCIA 83; Giannandrea 6; Litigating States, Ex. A 18; Nader/Love;377 Relpromax 15; SBC 157; Thomas 2, 5. Some commentors agree with this proposed term. ACT 31; Economides 5-6.378 AAI 39; CCIA 83; Nader/Love 5; Pantin 28.379 202 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. As the Court of Appeals noted, the characteristics of the market in378 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, but that would have provided an379 unreliable measuring stick for evaluating the amount of time necessary to restore competitive CCIA 83 n.17; SBC 157; Young 3; Hammett 1.380 See, e.g., United States v. Delta Dental Plan of Ariz., Inc., 1995-1 Trade Cas. (CCH)381 ¶ 71,048, 1995 WL 454769 (D. Ariz. 1995) (health care); United States v. Topa Equities, “Public Comments and Response on Proposed Final Judgment,” 60 Fed. Reg. 28,168, 28,170 (May 30, 1995) (noting that industry characteristics made quick entry likely), entered by, 1995-2 Trade Cas. (CCH) ¶ 71,061, 1995 WL 481368 (D. V.I. July 14, 1995); Oregon v. Mulkey, 1997-1 Trade Cas. (CCH) ¶ 71,859, 1997 WL 599410 (D. Or. June 16, 1997) (commercial crab fishing); United States v. Motor Vehicle Mfr. Ass’n, 1982 Trade Cas. (CCH) ¶ 65,175, 1982 WL 1934 (C.D. Cal. Oct. 28, 1982) (modifying judgment in decree regarding development and installation of motor vehicle emission control devices). See, e.g., United States v. Tele-Communications, Inc., “Comment and Response on382 Proposed Final Judgment,” 59 Fed. Reg. 39,783, 39,784 (Aug. 4, 1994) (recognizing that the telecommunications industry is “one that has experienced major changes in MTSD technologies that are ongoing”); United States v. Agri-Mark, Inc., “Competitive Impact Statements and Proposed Consent Judgments,” 45 Fed. Reg. 79,186, 79,189 (Nov. 28, 1980) (arguing that “the dairy industry is constantly evolving as a result of technological changes”). 203 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.” Antitrust Division Manual at IV-54 (3d ed. Feb.380 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, including in industries,381 like this one, that are characterized by rapid technological change. In this case, in an evolving382 market, the five-year term, particularly as augmented by a potential two-year extension, is long We note that the suggestion of an open-ended decree, subject to review after five years383 (see Gifford 9; Litan 73), or contingent upon Microsoft’s market share decreasing (see Thomas 6), would create undesirable uncertainty in the market and would be contrary to the United States’ mission to enforce the federal antitrust laws and to remedy specific violations thereof. Several comments argue that the two-year extension does not provide a meaningful384 check on Microsoft’s behavior. AAI 40; Alexander 4; CCC 27; CFA 84; Gifford 9; Harris 11, 14; Litigating States, Ex. A 17; Litan 55; Maddux ¶ 17; ProComp 76; Schneider 1; RealNetworks 32; TRAC 11. Some argue that the United States should have included sanctions for violations similar to those contained in the Litigating States’ proposed remedy. SBC 157. The Litigating States’ proposed remedy spells out a series of possible penalties that may be imposed if Microsoft violates the decree, including source code licensing, additional conduct remedies, and civil penalties. See Litigating States’ Proposal § 19. The Litigating States’ proposal also provides that if Microsoft brings or threatens to bring a groundless claim of intellectual property infringement for the purpose of impairing interoperability of non-Microsoft products, Microsoft may be enjoined from asserting or enforcing any intellectual property rights in related APIs, communications interfaces or technical information. Contrary to these commentors’ assertions, the possibility of the two-year extension of the RPFJ’s requirements and prohibitions will help dissuade Microsoft from violating its terms and conditions. The United States believes that this potential sanction, which is supplemented by its traditional enforcement and contempt authority, will provide a significant incentive for Microsoft to comply. In addition, the RPFJ requires an independent, full-time, on-site compliance team that385 will monitor compliance with the decree, report violations, and attempt to resolve technical disputes under the disclosure provisions. This ongoing supervision provides added assurance that Microsoft will comply with the obligations and restrictions imposed by the decree and that competitive conditions will be restored to the greatest extent possible during the five-year term of the proposed RPFJ. 204 enough. Because Microsoft will be eager to be released from the decree as soon as possible,383 the prospect of an extension should deter any violations and provide an extra incentive to comply. Moreover, wholly apart from seeking the two-year extension, the United States may384 seek civil and criminal contempt sanctions against Microsoft and its personnel if violations of the decree warrant that action. See RPFJ § IV.A. Nothing in the RPFJ undermines or erodes the385 Waldman 6-7.386 CCIA 83; Elhauge 13; Sen. Kohl 5; RealNetworks 29-30. 387 RealNetworks 30.388 205 United States’ existing and powerful contempt and enforcement authority. Therefore, in the386 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. At least one commentor387 complains that Microsoft has relied upon this provision as the basis for not yet disclosing certain APIs. We note foremost that Microsoft’s obligations under the disclosure provisions are388 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. PFF 24-29; Litan 65-69; ProComp 77-78.389 ProComp 77.390 206 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, arguing that “divestiture remains the most389 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 207 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, SIIA 22-25; AOL 24-31, Matthewson & Winter 25-26.391 SIIA 8, 64.392 Palm 14.393 208 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 and the Litigating States urge that the Court impose a remedy391 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 or adversely affecting the operation of competing products.” They392 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.” And they correctly observe that the IFJ contained an interim393 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 IFJ § 3.c.394 SIIA 64-65; SBC 45-46.395 209 performance of the rival software. One comment also criticizes the RPFJ for omitting a394 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 The Litigating States propose a very-similar provision. Section 11 of the Litigating396 States’ Proposal provides: “Microsoft shall not offer, agree to provide, or provide any consideration to any actual or potential platform software competitor in exchange for such 210 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. The United States initially proposed396 competitor’s agreeing to refrain or refraining in whole or in part from developing, licensing, promoting or distributing any Operating System Software Product or any Middleware product competitive with any Windows Operating System Product or Microsoft Middleware Product.” See Plaintiffs’ Reply Memorandum in Support of Proposed Final Judgment at 64 (May397 17, 2000). 211 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. The RPFJ seeks this same goal, but also expressly recognizes that under397 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 At least two comments express concern that the RPFJ does not contain language398 similar to that of Section 3.h of the IFJ. RealNetworks 30-31; SBC 98-99. For a complete discussion of how Sections III.F and III.G address this concern, see Sections V and VI, above. 212 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 a Microsoft 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 Palm 11-12.399 Kegel 9-10.400 213 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 SIIA 49; Nader/Love 6.401 214 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. The commentors correctly401 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 215 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 CCC 13-17; SIIA 49-51; ProComp 30; ProComp, Arrow 20-21; PFF 30-31; SBC 135;402 Hargraves 9; CCIA 38; CFA 11; Litan 71-72. Litigating States’ Proposal § 14; see also Litigating States, Ex. A 14-15.403 Indeed, the plaintiff States originally alleged that Microsoft engaged in unlawful404 monopolization, in violation of Section 2, with respect to Microsoft Office. However, the States dropped this claim prior to the trial. CompTIA 19 (porting Office would interfere with natural market forces); ACT 24405 (porting Office requirement beyond the scope of the case). 216 limited to the Macintosh OS, as a means to erode the applications barrier to entry. The402 Litigating States also have advanced this proposal, but the proposal is unwarranted.403 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. Second, the imposition of such a porting requirement is404 substantially outside the scope of the underlying case. Any remedy must be tailored to the405 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, allowing consumers, 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 PFF 30; SBC 143; CCIA, Stiglitz & Furman 40-41.406 ACT 29; CompTIA 16.407 PFF 30; SBC 143.408 217 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. Others object to this proposal, arguing that it would406 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. The407 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; offer a version of Windows that408 SBC 143.409 CCIA, Stiglitz & Furman 40-41.410 See discussion of RPFJ § III.C at Section IV(D), above.411 See discussion of Section III.A (Section IV(B), above); see also Sections III.D. and412 VI.U, which require Microsoft to provide actual and potential competitors with full access to the same APIs and related information as Microsoft middleware has to interoperate with the current, and future Windows operating systems, offering the potential of a seamless fit and greater possibility for incorporation of competing middleware. 218 has less Microsoft middleware and greater reliance on industry standards; and provide greater409 incentives for Microsoft to innovate, because it would have to offer a substantially better operating system in order to sell new releases. Commentors also argue that requiring410 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. A provision mandating the licensing of predecessor versions412 of Windows is therefore unnecessary and would do little or nothing to enhance these goals. SIIA 61; Novell 5; Sun 23-24.413 AAI 25; Novell 25; SBC 146; ProComp 35, 74.414 219 E. Industry Standards 437. Several commentors express concern that the RPFJ imposes no requirement on Microsoft to support industry standards for interoperability. By industry standards, the413 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. The commentors correctly point out that the Court of414 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. SIIA 61-62.415 SIIA 61-62 (Kerberos); Johnson 5 (Kerberos).416 Litigating States’ Proposal § 16; ProComp 35 (referring to Litigating States’ Proposal).417 220 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. The United415 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). Nor would it constrain in any way Microsoft’s actions with respect to industry416 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. Litigating States Provision 16.a (“Compliance with Standards”) would417 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 CIS at 62.418 221 nonproprietary industry version in its operating systems. The United States considered a provision substantially similar to Litigating States Provision 16.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 Litigating States, Ex. A 15.419 CCIA 59 n.12; Kegel 27-28; KDE 13; Novell 26-29; CFA 90.420 222 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. Throughout most of its history, Sun’s Java419 has neither been a technical standard approved by, submitted to, or under consideration by a standard-setting body (the criterion for protection under Provision 16.a) nor a “variation” from such a standard (the criterion under Provision 16.b), but rather a widely-used proprietary technology under the control of its owner, Sun. F. Protection For Large End Users 444. A few commentors lament the lack of special protection in the RPFJ for large end user purchasers of Microsoft products. These commentors express several concerns regarding420 large corporations, universities, or federal, state, or local government purchasers: (1) Microsoft KDE 13.421 Kegel 27-28.422 Novell 26-29.423 CCIA 59 n.12.424 223 may retaliate against end users purchasing competing middleware; (2) Microsoft continues to421 charge license fees to these purchasers for all machines capable of running a Microsoft operating system (a “per processor fee”), thereby removing incentives to purchase competing operating systems; (3) Microsoft imposes other coercive licenses directed at end users; and422 423 (4) Microsoft, without some restraint, can undo all of the RPFJ provisions applying to OEMs upon the first license renewal with an end user.424 445. The commentors’ proposed relief is outside the scope of the underlying case. The United States did not allege, or prove, that Microsoft engaged in anticompetitive conduct involving its large end user customers. Although the United States proved that Microsoft illegally maintained its PC operating system monopoly through actions directed at eliminating the middleware threat, it presented no evidence — and the District Court made no finding — that purchasers large and sophisticated enough to deal directly with Microsoft were in need of special protection. 446. Nevertheless, certain provisions of the RPFJ do apply to end users. Pursuant to Section III.H.1-2, end users are able (1) to configure the desktop to enable or remove access to each Microsoft Middleware Product as described, and (2) to designate a Non-Microsoft Middleware Product to be invoked in place of a Microsoft Middleware Product as described. SBC 99.425 Litigating States’ Proposal § 9.426 224 And, pursuant to Section III.H.3, Microsoft cannot alter those configurations without permission from the end user. G. Non-Retaliation For Participation In Litigation 447. At least one comment has advocated inclusion of the Litigating States’ proposal425 specifically to prohibit retaliation by Microsoft against those who participated in litigation in either of the now de-consolidated actions. Such a provision is unnecessary because the Court426 retains ample authority, regardless of whether such a provision is included in the RPFJ, to sanction such conduct if and when it arises. 448. Thus, should retaliation of the sort described by the comment arise, the United States may petition the Court to exercise its continuing jurisdiction to issue “further orders as may be necessary or appropriate to carry out or construe this Final Judgment . . . to modify . . . any of its provisions, to enforce compliance, and to punish violations thereof.” RPFJ §VII. Under both its inherent powers and Section VII of the RPFJ, the Court could take whatever action is necessary to prevent, halt, and remedy any such retaliation against participants in this litigation. Further, depending on the facts of any such retaliation, Microsoft also could face criminal liability under a number of statutes. See, e.g., 18 U.S.C. § 1503 (“whoever . . . corruptly or by threats or force, or by any threatening letter or communication, influences, obstructs, or impedes, or endeavors to influence, obstruct, or impede the due administration of justice . . .”); 18 U.S.C. § 1512 (witness tampering, generally). A specific anti-retaliation provision of the sort proposed here is therefore unnecessary and unwarranted. SIIA 41-44; CFA 55-65; Palm 7-8; Catavault 3-11; KDE 9-10.427 See generally ; Huwalt 3.428 225 XII. MISCELLANEOUS COMMENTS A. Microsoft’s “.Net” Initiative 449. Some comments argue that the RPFJ fails effectively to constrain Microsoft’s427 diverse set of announced and emerging web services initiatives, grouped generally under the “.Net” trademark. The comments claim that Microsoft, having vanquished the nascent cross-428 platform distributed computing threat posed by the Java architecture, is now implementing its own closed system that will require Microsoft operating system products on both the server side of the network and on the client side (i.e., Windows Operating System Products). Under such a scenario, argue the commentors, neither server nor client software competitors of Microsoft will be able to interoperate with the .Net technologies. The suggested remedies for this situation, according to the comments, range from mandatory transparency of all Microsoft APIs, Communications Interfaces, and other technical information, regardless of whether the disclosures touch on either Microsoft’s desktop operating system monopoly or middleware, to mandatory porting of the basic .Net architecture (the “.Net Framework”) to several alternate server and client platforms. These criticisms are not well taken. 450. First, whether .Net is, in fact, likely to have an anticompetitive effect, or what its competitive significance might be in general, is not yet clear. The very concept of “web services” is still evolving as new ways to use networking and the Internet are discovered. Many parts of .Net, and even some of the detailed plans for .Net, have not yet been released, and therefore cannot fully be evaluated. Similarly, announced (but not yet released) alternate web See generally .429 226 services frameworks, such as the multi-vendor “Liberty Alliance” founded by Sun429 Microsystems, are not fully developed and do not have actual products in the market. It would be difficult, if not impossible, to draw conclusions about the competitive impact of such pre-nascent initiatives that have sufficient reliability to warrant additional remedies or restrictions. 451. Second, the remedies proposed by the commentors, including mandatory transparency of Microsoft technical information, regardless to whether such disclosures relate to middleware or Microsoft’s operating system, reach beyond the scope of the case as sustained by the Court of Appeals. Any remedy must focus on addressing the specific conduct by Microsoft to impede the nascent middleware threat to its operating system. 452. Third, to the extent .Net might implicate middleware or Microsoft’s platform monopoly as developed in this case, it can, of course, fully be evaluated within the context of the RPFJ and this case. Thus, availability of Communications Protocols as provided for in Section III.E of the RPFJ provides a continuing obligation for Microsoft to make available, through licensing on reasonable and non-discriminatory terms, the Communications Protocols utilized by the .Net Framework to the extent these Communications Protocols are used by a Microsoft server operating system product to interoperate with the Windows Operating System Product. See discussion at Section III(B)(1)(d) - (2)(e), above. The practical effect of this provision is that, if Microsoft puts client/server interfaces for the .Net framework in its monopoly Windows Operating System Product, these interfaces will be available for use by third parties. Indeed, the United States understands that various Microsoft technologies, including the Active Directory services model, the Kerberos security model, and the Common Language Runtime CCIA 39-41.430 227 analog to Java virtual machines, are core components of the .Net Framework that the comments complain about and are already covered by the RPFJ. See CIS at 37-39. B. Course Of Conduct 453. A commentor criticizes the United States for taking the position that the Court of Appeals failed to uphold Microsoft’s course of conduct as an independent violation of Sherman Act § 2. Yet, it is difficult to see how the Court of Appeals could have made its position any430 clearer: the District Court did not point to any series of acts, each of which harms competition only slightly but the cumulative effect of which is significant enough to form an independent basis for liability. The “course of conduct” section of the District Court’s opinion contains, with one exception, only broad, summarizing conclusions. See, e.g., Conclusions of Law, at 44 (“Microsoft placed an oppressive thumb on the scale of competitive fortune. . . .”). The only specific acts to which the court refers are Microsoft’s expenditures in promoting its browser, see id. (“Microsoft has expended wealth and foresworn opportunities to realize more. . . .”), which we have explained are not in themselves unlawful. Because the District Court identifies no other specific acts as a basis for “course of conduct” liability, we reverse its conclusion that Microsoft’s course of conduct separately violates § 2 of the Sherman Act. Microsoft, 253 F.3d at 78. 454. The comment disagrees that the net effect of the Court of Appeals’s substantial narrowing of the findings of liability, including its rejection of the District Court’s “course of conduct” finding, was to curtail the available remedies. Again, the Court of Appeals made clear that “[w]hile we do not undertake to dictate to the District Court the precise form that relief should take on remand, we note again that it should be tailored to fit the wrong creating the occasion for the remedy.” Id. at 107; see also id. (“we have drastically altered the scope of Microsoft’s liability, and it is for the District Court in the first instance to determine the propriety ProComp 26-29; ProComp, Arrow ¶¶4, 32- 34; AOL 45; Elhauge 4, 10; SIIA 44-51;431 Litan 58-59; Henderson 4, 10; Litigating States, Ex. A 13-14; CCIA 10, 35-36, 42-44; Gifford 8; Pantin 37. 228 of a specific remedy for the limited ground of liability which we have upheld”). In light of the Court of Appeals’ decision, the wrong creating the occasion for remedy — the limited ground of liability upheld — is Microsoft’s specific practices, and not any alleged course of conduct undertaken to protect the operating system monopoly. C. Restoring Java/Netscape Threats 455. Several commentors suggest that the RPFJ does nothing to restore Netscape431 Navigator and Java as competitive threats to Microsoft. This criticism ignores what the RPFJ does do: it restores the ability of middleware, including browsers like Navigator and other middleware like Java, to threaten the applications barrier to entry protecting Microsoft’s operating system monopoly. The RPFJ not only enjoins Microsoft from continuing the anticompetitive conduct that it directed against Netscape and Java but also, as detailed elsewhere, imposes affirmative obligations on Microsoft that will give middleware providers the opportunity to develop as threats to Microsoft’s operating system monopoly. The United States believes that this restoration of the opportunity for middleware of all types, present and future — and not limited to Web browsers and Java — to erode Microsoft’s operating system monopoly is the appropriate goal for a remedy in this case. 456. As an initial matter, some comments presuppose that, had Microsoft not engaged in its unlawful conduct, both Netscape and Java would have succeeded in eroding Microsoft’s operating system monopoly. In fact, however, even the District Court concluded that “there is insufficient evidence to find that, absent Microsoft’s actions, Navigator and Java already would Sun 7; Litigating States, Ex. C at 1.432 229 have ignited genuine competition” in the PC operating system market. Findings of Fact, ¶ 411; see also id., ¶ 69 (threat posed by Netscape was only a “potential” threat); id., ¶ 77 (Netscape and Java had “a long way to go before they might imperil the applications barrier to entry”). And similarly, the Court of Appeals did not adopt the view that Microsoft “would have lost its position in the OS market but for its anticompetitive behavior.” Microsoft, 253 F.3d at 107. Thus, the emphasis that these comments place on the restoration of Java and Netscape as “threats” is misplaced. 457. The United States believes that the relief contained in the RPFJ, which applies to a broad range of middleware functionality and not just to Web browsers and Java, achieves the overriding goal that these comments also desire: the restoration of competitive conditions so that consumers have choices and collectively can determine competitors’ respective fates. The relief will allow for Navigator, Java, and other current middleware products to fulfill whatever capability they have as threats to Microsoft’s operating system monopoly and for other new and as-of-yet unanticipated forms of middleware to evolve as potential threats to Microsoft’s monopoly. D. Microsoft’s Responses To The Litigating States’ RFAs 1. Meeting Of The Minds 458. Two commentors say that Microsoft’s responses to Requests for Admission (RFAs) in New York show that the United States and Microsoft failed to reach a meeting of the minds on the essential terms of the RPFJ. Because these commentors mischaracterize Microsoft’s432 responses, however, they mistakenly see disagreement where agreement exists. See, e.g., Litigating States, Ex. C at RFAs 2, 5, 10, 12-13, 23, 28-35, 39-45.433 RFAs 2-4, 10, 32.434 230 459. The Litigating States in New York propounded 51 RFAs, pursuant to Fed. R. Civ. P. 36(a), some of which sought Microsoft’s interpretation of the terms of the RPFJ and cited or quoted (and on occasion mis-quoted) the CIS. In response, Microsoft objected to these and433 other RFAs on the basis that they call for a legal conclusion. The mere fact that Microsoft asserted legal objections to this discovery carries no significance in this case, because it does not constitute evidence of anything at all about the meeting of the minds of the parties to the settlement. 460. In response to a limited number of RFAs, however, Microsoft did deny that it shares the opinion of the United States as set forth in the CIS. But none of the selected portions of the434 CIS quoted addresses an interpretation of the terms of the RPFJ. Rather, the cited portions of the CIS contain expressions of the United States’ views regarding the competitive significance of the RPFJ: “the key to the proper remedy in this case” (RFA No. 2); that OEMs are a crucial distribution channel (RFA No. 3); that it is critical that OEMs are free to distribute and promote non-Microsoft middleware (RFA No. 4); that Windows license royalties and terms are complex and easy for Microsoft to use to affect OEMs’ behavior (RFA No. 10), and that the competitive significance of middleware is highly dependent on certain factors (RFA No. 32). Microsoft’s disagreement with the United States’ opinion in these matters has no bearing on the parties’ interpretation of essential terms of the RPFJ. Litigating States, Ex. C at RFAs 34, 39, 40, 41, 42, 43, 45.435 Red Hat 3-4.436 231 2. Objections To Language In The CIS As “Vague And Ambiguous” 461. In response to other RFAs, Microsoft identifies certain terms (all used by the United States in the CIS) as “vague and ambiguous” and objects to the RFAs on that basis. 435 Microsoft also identifies as “vague and ambiguous” a sentence in the RFA referring to Section III.J.1.a (RFA No. 45 (quoting terms from CIS at 39 (discussing RPFJ Section III.J.1.a))). 462. In response to concerns raised by commentors regarding the interpretation of Section III.E, the United States and Microsoft have agreed to the modification of the language of Section III.E described in Section VII(B) above. For a discussion of the terms of Section III.J, see Section VII(D) above. E. “Open Source” Community 463. Commentors raise a variety of concerns about how the RPFJ may affect the “open source” community. Generally, “open source” software is distinguished from traditional, proprietary software by who writes it, how (or whether) they are compensated, and the terms under which it is licensed to users and other developers. Open source software often is written by collections of individuals not affiliated within the framework of a firm, who may or may not be compensated for their work, and generally is distributed under licenses that grant greater rights to create and distribute derivative works than is typical of licenses for traditional, proprietary software. The Linux operating system, for example, is open source software.436 464. Several commentors express concern that Microsoft somehow may claim that an open source developer, or a network of open source developers, or a marketer of open source Red Hat 24; AAI 37-38; CCIA 77-82; Waldman 5.437 Red Hat 28-29; Henderson 7-8; Alexander 3-4; Carroll 2-3; Harris 9; Moglen 3, 5;438 Waldman 6; Litan 52; Pantin 24-25; AAI 23; Waldman 6. Red Hat 7-21.439 232 software, should not be considered to meet Section VI.I’s definition of an “ISV” and so should not receive the benefits and protections given to ISVs by the RPFJ. The United States believes437 this concern is groundless. See the discussion in Section III(A), above. 465. A number of commentors are concerned that Microsoft will deny disclosure of APIs and Documentation (as required by Section III.D), or licensing of Communications Protocols (as required by Section III.E), to open source developers on the grounds that the developers do not meet the “reasonable business need” or “authenticity and viability of [ ] business” criteria of Section III.J.2. The United States believes that the requirements in Section III.J.2 are no438 broader than is necessary to prevent misuse or misappropriation of intellectual property. See the discussion at Section VII(D), above. 466. One commentor in the open source community contends that the RPFJ fails to restore competitive conditions because the RPFJ does not prohibit Microsoft from bringing infringement suits to protect its extensive patent portfolio. The commentor recommends requiring Microsoft to license all of its intellectual property that would otherwise potentially be infringed by products that threaten Microsoft’s operating system monopoly, including competing operating systems, middleware, or other software and hardware. The United States believes that preventing439 Microsoft from protecting its intellectual property is unwarranted and inappropriate. Section III.I requires Microsoft to license to OEMs, ISVs, IAPs, and others “any intellectual property rights” Kegel 8-9..440 Kegel 11; Koppe 1; Tilwalli 1; Kasten 5; Carroll 3; Johnson 2.441 233 necessary for those entities to exercise any of their options or alternatives under the RPFJ. But allowing rivals otherwise to expropriate Microsoft’s intellectual property in order to compete with Microsoft would deter Microsoft from investing in innovation and simultaneously deter rival developers from inventing different, new, potentially better technologies to build into their own products. Nothing in this “solution” would benefit consumers. 467. In a similar but less extreme vein, another commentor suggests that the RPFJ should require Microsoft to list which software patents protect Windows APIs, so that vendors of other operating systems can avoid infringing Microsoft’s patents accidentally and reassure users that those operating systems are not infringing. While avoiding infringement is a laudable goal, it440 is not the purpose of the RPFJ to reduce the legal and technical efforts necessary for competitors to build products that they may lawfully market. 468. Several commentors complain that the RPFJ does not eliminate license terms that prohibit open source and other developers from finding ways to make Windows applications run on non-Windows operating systems. The issues these commentors raise appear to concern both terms in the licenses for Microsoft Office and terms in the licenses for Windows APIs and tools. The Litigating States’ Provision 6.b addresses the same point; it would prohibit441 agreements that “restrict Microsoft redistributable code from use with non-Microsoft Platform Software.” Such provisions are far outside the scope of this case, and in any event are unlikely to benefit consumers. If Microsoft could not prevent people from expropriating and modifying its applications or middleware products — that is, its “redistributable code” — to turn them into Kegel 9; CompTIA 5 (pro-settlement); Pantin 5-6.442 See CCIA 41-42; AOL 1, Klain 8-9; Litan 47-49; WLF 6; Waldman 4; ProComp 74-443 77; Sun 36-37. The RPFJ measures Microsoft’s conduct against this standard in, for example, Section III.B.2 (“reasonable volume discounts”), Section III.C.5 (“reasonable technical specifications”), Section III.E (“reasonable and non-discriminatory terms”), Section III.F.2 (“limitations reasonably necessary to and of reasonable scope and duration”), and Section III.G (“reasonable period of time”). 234 complements to non-Microsoft operating systems, Microsoft would have a significantly reduced incentive to invest in developing and marketing attractive applications and middleware for Windows users. 469. One comment contends that Microsoft should be prohibited from retaliating against an OEM that ships computers loaded with only a non-Microsoft operating system, rather than (as in Section III.A.2) prohibited only from retaliating against an OEM that ships a computer with Microsoft and non-Microsoft operating systems or one that ships a computer that will “dual- boot” with more than one operating system. Neither the District Court nor the Court of442 Appeals held Microsoft liable because it prevented OEMs from producing PCs with non- Microsoft operating systems; thus, there is no basis for redressing such conduct. The absence of such a provision, however, is not problematic. If the OEM ships no machines with Windows, then presumably it ships no machines with Windows applications, either; thus, Microsoft would have few ways to “retaliate” against that OEM for its decision not to ship Windows. F. “Reasonableness” Standard 470. A handful of comments express concerns about the use of a “reasonableness” standard in various provisions of the RPFJ. The commentors assert that use of a443 reasonableness standard for measuring certain of Microsoft’s conduct offers little practical CCIA 41-42; ProComp 74-77; Litan 49; AOL, Klain 8-9.444 AOL 1; Litan 47.445 235 guidance, and injects ambiguity into the decree, rendering it virtually unenforceable. 444 Commentors also assert that the adoption of a reasonableness standard turns the RPFJ into nothing more than an admonition to Microsoft to comply with the law.445 471. Contrary to these comments’ assertions, measuring a defendant’s conduct against a reasonableness standard does not render the RPFJ impermissibly vague. Inclusion of the term “reasonable” is common in antitrust decrees. See, e.g., United States v. Enova Corp., 107 F. Supp.2d 10, 21, 27 (D.D.C. 2000) (defendant required to use “reasonable best efforts” to obtain approvals and “all reasonable efforts” to maintain assets in a decree entered by the Court); United States v. 3D Sys. Corp., 66 Fed. Reg. 49,200-01 (D.D.C. 2001) (defendant to provide “reasonable access to personnel,” “reasonable efforts” by trustee to sell assets); United States v. Premdor, Inc., 66 Fed. Reg. 45,326-01 (D.D.C. 2001) (defendant to use “reasonable efforts” to maintain assets, provide “reasonable levels of transitional support,” provide “reasonable access” to personnel, trustee to receive “reasonable compensation”); United States v. Electronic Payment Servs., Inc., 1994-2 Trade Cas. (CCH) ¶ 70,796, 1994 WL 730003 at *4 (D. Del. 1994) (third- party processor is qualified if it meets “reasonable and nondiscriminatory technical, financial and operating criteria”; defendant may charge “reasonable set-up fees”); United States v. Pilkington PLC, 1994-2 Trade Cas. (CCH) ¶ 70,842 1994, WL 750645 at * 4 (D. Ariz. 1994) (permitting Thus, for example, the defendant in United States v. First Multiple Listing Service,446 Inc., 1984 WL 417, at *1-*2 (N.D. Ga. 1984), was enjoined from refusing to provide services to any person who agrees to pay “reasonable set-up costs,” a “reasonable security deposit,” and “reasonable and non-discriminatory fees . . . reflecting reasonable expenses . . . provid[ing] for a reasonable minimum annual fee . . . [and] reflecting a reasonable approximation of the cost[s].” The final judgment there further provided that “[n]othing in this final judgment shall prohibit Defendant from (i) imposing delivery or service charges . . . reflecting reasonable approximations of actual costs, including reasonable deposits for keys or books . . . .” Id. at *2. See, e.g., Litan 47-49; CCIA 41-42.447 See, e.g., Response to Comments on Sections III.B.2, III.F.2, III.G.2.448 An order need not list the components of a term which is understood by common449 parlance, particularly when considering the persons to whom the order is directed. United States v. PATCO, 678 F.2d 1, 3 (1st Cir. 1982), citing Village of Hoffman Estates v. Flipside, 455 U.S. 489, 495 n.7 (1982) (“[t]he rationale is evident: to sustain such a challenge, the complainant must prove that the enactment is vague ‘not in the sense that it requires a person to conform his conduct to an imprecise but comprehensible normative standard, but rather in the sense that no standard of conduct is specified at all’” (quoting Coates v. City of Cincinnati, 402 U.S. 611, 614 (1971)). 236 charges of “commercially reasonable and non-discriminatory Fees for the use or sublicensing of Float Technology . . . “).446 472. Certain commentors urge that the RPFJ reject the reasonableness standard and, instead, adopt bright-line prohibitions against Microsoft engaging in various activities. Such447 absolute prohibitions might benefit Microsoft’s rivals, but they also would reduce choice and thus not be in the interest of competition and consumers overall. Moreover, bright-line rules448 tend to require elaborate definitions that can render an agreement unduly complex. The inclusion of the reasonableness standard represents a recognition of the necessity for terms to be sufficiently flexible to allow for a multitude of future possibilities without requiring excess verbiage.449 Litan 47-49.450 237 473. Commentors are also incorrect in their insistence that including a reasonableness standard simply engrafts the rule of reason into the RPFJ, turning it into an instruction to450 Microsoft to comply with the law — effectively to “go forth and sin no more.” In fact, the RPFJ goes beyond eliminating illegal practices and preventing recurrence of the same or similar practices in the future. The RPFJ also takes affirmative steps to restore the competitive threat that middleware posed prior to Microsoft’s unlawful undertakings. So, for example, Microsoft is required to disclose and license its proprietary technology — although the Court of Appeals did not sustain any allegation that a failure to do so constituted monopoly maintenance. Similarly, the RPFJ ensures access to, and use of, Microsoft’s proprietary server-related protocols, even though the word “server” does not appear in the complaint and appears only in passing in the Findings of Fact. An instruction simply to obey the law would have taken the form of a decree saying only that Microsoft is enjoined “from future violations of the antitrust laws,” in stark contrast to the detailed and specific prohibitions in the RPFJ. 474. Finally, commentors suggest that the inclusion of a reasonableness standard will require a court to interpret the RPFJ, with an attendant delay in enforcement. That a decree may require interpretation is not and cannot be a basis for rejection; otherwise, no decree would remain. G. Computers For Schools 475. Many comments refer to or discuss the proposed settlement in the private, class actions against Microsoft, whereby Microsoft would donate $1 billion worth of computer 238 hardware and software to needy schools. See In re Microsoft Corp. Antitrust Litig., 2002 WL 99709 (D. Md. Jan. 11, 2002) (proposed settlement in MDL No. 1332). 476. There is no relationship between the settlement of the United States’ antitrust lawsuit against Microsoft and the settlement of the private, class action against the company. Because these comments relate to the settlement of an entirely different proceeding, in which the United States played no role, we do not believe these comments can be appropriately construed as comments on the RPFJ and therefore do not respond to them. 477. To the extent that comments mean that the RPFJ is deficient because it does not require Microsoft to make charitable donations, that cannot be a legal basis for rejecting a consent decree. Requiring charitable donations is not a proper remedy in a government civil antitrust case. 239 Respectfully submitted, CHARLES A. JAMES Assistant Attorney General DEBORAH P. MAJORAS Deputy Assistant Attorney General PHILLIP R. MALONE RENATA B. HESSE DAVID BLAKE-THOMAS PAULA L. BLIZZARD KENNETH W. GAUL ADAM D. HIRSH JACQUELINE S. KELLEY STEVEN J. MINTZ BARBARA NELSON DAVID SEIDMAN DAVID P. WALES Attorneys U.S. Department of Justice Antitrust Division 601 D Street N.W., Suite 1200 Washington, D.C. 20530-0001 (202) 514-8276 PHILIP S. BECK February 27, 2002 Special Trial Counsel