Skip to main content

Microsoft Tunney Act Comment : Project To Promote Competition & Innovation In The Digital Age (ProCOMP)

This document is available in two formats: this web page (for browsing content) and PDF (comparable to original document formatting). To view the PDF you will need Acrobat Reader, which may be downloaded from the Adobe site. For an official copy, please contact the Antitrust Documents Group.
PROJECT TO PROMOTE COMPETITION & INNOVATION
I N    T H E    D I G I T A L    A G E
2001 K STREET, NW . SUITE 800 . WASHINGTON, DC 20006

 

January 28, 2002

Ms. Renata Hesse
Trial Attorney
Suite 1200
Antitrust Division
Department of Justice
601 D. Street, NW
Washington, D.C. 20530

RE: Comments to the Proposed Final Judgment In
United States v. Microsoft Corporation, No. 98-1232
State of New York, et al v. Microsoft Corporation, No. 98-1233

Dear Ms. Hesse,

Enclosed please find ten (10) copies of the comments of the Project to Promote Competition and Innovation in the Digital Age ("ProComp"), submitted pursuant to the Tunney Act, 15 U.S.C. § 16, with respect to the Proposed Final Judgment in the above-captioned matters.

Please also note that this filing is accompanied by an affidavit prepared and submitted by Professor Kenneth J. Arrow, the original signed copy of which is attached hereto.

 

Sincerely yours,

         /s/         
Mitchell S. Pettit
President
ProComp

Comments to the Proposed Final Judgment In
United States v. Microsoft Corporation, No. 98-1232
State of New York, et al. v. Microsoft Corporation, No. 98-1233

 

Submitted By

Project to Promote Competition & Innovation
in the Digital Age ("ProComp")

Pursuant to the Tunney Act, 15 U.S.C. . 16

 

January 28, 2002

Kenneth W. Starr
Thomas D. Yannucci
Mark L. Kovner
Kirkland & Ellis
655 15th Street, N.W., Suite 1200
Washington, D.C., 20005
(202) 879-5000
      Counsel for ProComp
Robert H. Bork
1150 17th Street, N.W.
Washington, D.C. 20036
      Counsel for ProComp
 
Kevin J. Arquit
Michael C. Naughton
Arman Y. Oruc
Clifford Chance Rogers & Wells LLP
200 Park Avenue
New York, N.Y. 10166
(212) 878-8000
      Counsel for ProComp
Mitchell S. Pettit, President
ProComp
2001 K Street, N.W., Suite 800
Washington, D.C. 20006
(202) 912-7140
  Glenn B. Manishin
Stephanie A. Joyce
Kelley Drye & Warren LLP
1200 19th Street, N.W., Suite 500
Washington, D.C. 20036
(202) 955-9600
      Counsel for ProComp

TABLE OF CONTENTS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


This proposed decree is so ineffective that it would not have prevented Microsoft from destroying Netscape and Java, the very acts that gave rise to this lawsuit. It is so ineffective in controlling Microsoft that it might as well have been written by Microsoft itself.

The "public interest" standard of the Tunney Act, 15 U.S.C. § 16(e), is determined in this case by the unanimous legal ruling of the Court of Appeals for the District of Columbia Circuit sitting en bane. That Court held that Microsoft has maintained its monopoly in personal computer operating systems in clear violation of Section 2 of the Sherman Act. No decree that fails to cure that illegality and prevent its recurrence can conceivably serve the public interest. The Proposed Final Judgment ("PFJ" or "proposed decree") accomplishes neither of those mandatory purposes. For that reason, the proposed decree should be rejected by the District Court.

This case is entirely different from any settlement since the adoption of the Tunney Act in 1974. All other settlements were entered into prior to the conclusion of any trial, usually before any trial had even commenced. Cases holding that a Tunney Act court must accept a lesser remedy than might (or might not) be obtained after trial are utterly irrelevant. The Competitive Impact Statement's ("CIS") reliance upon such cases is misguided. United States v. Microsoft Corp., Revised Proposed Final Judgment and Competitive Impact Statement, 66 Fed. Reg. 59,452 (2001). Here, the District Court and the Court of Appeals, including a total of eight judges, have decided that in violating the Sherman Act, Microsoft's behavior is directly contrary to the public interest. The Tunney Act does not empower the District Court to enter a remedy that excuses past violations and permits future conduct of the same nature. The proposed decree does precisely that. It is no more binding on the District Court than would be a Department of Justice statement that henceforth a named company would be immune from antitrust prosecution.

In particular, the proposed settlement takes no steps to remedy Microsoft's foreclosure of middleware threats from competing Internet browsers and cross-platform Java technology, Microsoft's related efforts to illegally increase the applications barrier to entry protecting its Windows monopoly, or Microsoft's illegal commingling of browser and other middleware code with Windows. Further, the proposed settlement does not assure that future middleware competitors will have access to the necessary technical information to interoperate properly with Windows, and does not open up the critical Original Equipment Manufacturer ("OEM") distribution channel to these future competitors. Finally, the PFJ ignores the competitive threat to Microsoft's monopoly presented by server-based distributed applications, and thus fails to address Microsoft's practice of protecting its monopoly by controlling proprietary interfaces and communications protocols.

More significantly, the only suggestion in the CIS as to any basis for a very limited and deferential scope of judicial review is simply wrong. The Department insists that such a standard is "particularly" appropriate "where, as here, court's review of the decree is informed not merely by the allegations contained in the Complaint, but also by the extensive factual and legal record resulting from the district and appellate court proceedings." CIS, 66 Fed. Reg. at 59476. Exactly the opposite is the case. In routine Tunney Act cases, the law is clear that respect is to be accorded to the Department's antitrust enforcement judgments -- its "perceptions of the market structure and its view of the nature of the case" -- precisely because there is no factual or legal record before the court. United States v. Microsoft Corp., 56 F.3d 1448, 1448 (D.C. Cir. 1995) ("Microsoft l") (emphasis added). When a Sherman Act case has been litigated and affirmed on appeal, however, the district court is fully capable of assessing the proposed remedy in light of those rulings and its "familiarity with the market involved." Id. at 1461.

The closest parallel to this Court's review of the PFJ is the AT&T monopolization settlement presented by the Department and decided by this Court (Harold Greene, J.) under the Tunney Act. United States v. AT&T, 552 F. Supp. 131 (D.D.C. 1982), aff'd mere. sub nora., Maryland v. United States, 460 U.S. 1001 (1983). In the AT&Tease, Judge Greene had heard the vast majority of the evidence -- on all issues except remedy -- and more than a year earlier bad denied AT&T's motion to dismiss on the merits after the close of the government's case-in-chief. Following a wide-ranging Tunney Act process that included evidentiary hearings, third-party submissions and several days of oral argument, Judge Greene refused to approve the consent decree as proposed, even though it mandated divestiture of major components of the Bell System. He concluded that the decree was in certain respects substantively inadequate, precluded the Court from effective oversight and enforcement, and posed a risk of harming third-parties (despite the presence of complementary regulatory jurisdiction to accomplish similar goals). Judge Greene therefore insisted upon substantial modifications to the proposed decree before he would enter the settlement under the Tunney Act's public interest standard.

Recognizing the intense public concern over a possible "rubber stamp" of the settlement by the Court, Judge Greene concluded that it was his responsibility to ensure that the decree protected consumers, opened the relevant markets to effective competition in a timely manna-, and was readily enforceable. Significantly, Judge Green found that "unlike ordinary pre-trial antitrust settlements, the Court would 'be able to render sound judgments' because it 'ha[d] already heard what probably amounts to well over ninety percent of the parties' evidence both quantitatively and qualitatively, as well as all of their legal arguments." Id. at 152 (citations omitted). For this reason, Judge Greene held that "it does not follow that [the Court] must unquestionably accept a consent decree as long as it somehow, and, however inadequately, deals with the antitrust problems implicated in the lawsuit." Id.

The purpose of judicial review under the Tunney Act is to ensure that a consent decree follows "'the public interest as expressed in the antitrust laws.'" S. REP. NO. 93--298 (1973) ("SENATE REPORT") (emphasis added). Here, the Court of Appeals held specifically that "a remedies decree in an antitrust case must seek to 'unfetter a market from anticompetitive conduct,' 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. Microsoft Corp., 253 F.3d 34, 103 (D.C. Cir. 2001) ("Microsoft III"') (quoting Ford Motor Co. v. United States, 405 U.S. 562, 577 (1972), and United States 1,. United Shoe Mach. Corp., 391 U.S. 244, 250 (1968)). The Department itself earlier emphasized to this Court on remand that "both the applicable remedial legal standard and the liability determination of the Court of Appeals are clear." Joint Status Report, United States v. Microsoft Corp., at 24 (D.D.C. filed Sept. 20, 2001). The Court of Appeals has spoken and its holding is binding on this Court as well as the litigants. Consequently, in the unique procedural posture of this case, the "public interest as expressed in the antitrust laws" is the Court of Appeals' mandate itself. SENATE REPORT, supra, at 5.

The CIS does not even cite, let alone argue, that the PFJ meets the D.C. Circuit's remedial standard, quoted above, to terminate the monopoly, deny the defendant of its ill-gotten fruits, and ensure that monopoly practices cannot arise in the future.

As that standard recognizes, there is no difference between the remedies called for when a defendant has unlawfully gained a monopoly or unlawfully maintained a monopoly. The offense of monopolization under Section 2 of the Sherman Act occurs when a finn has either "'acquired or maintained" monopoly power by anticompetitive means. United States v Grinnell Corp., 384 U.S. 563, 570-71 (1966); Microsoft III, 253 F.3d at 50. There is no legal basis to distinguish between the methods of monopolization either for liability or relief purposes, and neither DOJ nor Microsoft has cited a case making such a distinction. All arc equally unlawful and all arc equally harmful to consumers. Here, for example, even assuming that Microsoft achieved its monopoly power through legitimate business means, it has been found to have maintained such monopoly power through a series of anticompetitive conduct designed to illegally preserve its monopoly position by foreclosing rivals. But for this illegal maintenance, Microsoft's monopoly power would probably have dissipated, and competitors and consumers would have enjoyed the benefits of free and fair competition. Microsoft's internal communications demonstrate that Microsoft thought that would be the likely outcome.

For these reasons, courts apply broad relief even where a firm has been found to possess monopoly power that was legally acquired but illegally maintained. See, e.g., United Shoe, 391 U.S. at 250 (in context of a legally attained monopoly position that was illegally maintained, the Court held it has a duty to "prescribe relief which will 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"). And courts have never distinguished between illegal attainment and illegal maintenance when determining remedies for a Sherman Act Section 2 monopolization claim. See, e.g., Schine Chain Theatres, Inc. v. United States, 334 U.S. 110, 128 (1948) (holding conduct injunctions against future violations not adequate to protect public interest in monopolization cases since defendant thus maintains the full benefit of the monopoly; instead broad remedies, including divestiture, are necessary to undo the harm to the market); see also 3 PHILLIP E. AREEDA AND HERBERT HOVENCAMP, ANTITRUST LAW ¶ 653i (2002) (quoting United Shoe, 391 U.S. at 250-52, for the proposition that a "monopoly that has been created or maintained by plainly exclusionary conduct is unlawful and that it is the duty of the court to assure its 'complete extirpation.'" (emphasis added)). In short, an appropriate set of remedies to restore competition needs to be sufficient to pry open the market to competition, stop the bad acts, undo the effects of the bad acts, and preclude future alternative anticompetitive tactics.

The D.C. Circuit was well aware that this case involves monopoly maintenance -- that the achievement by Microsoft of a Windows monopoly in the first instance was not alleged to be unlawful -- but nonetheless specifically adopted the Ford/United Shoe remedy standard, including its command to "terminate" the defendant's monopoly power. That is the law of this case and the law in all Sherman Act monopolization cases.

By agreeing to the proposed settlement, the Department and the Settling States have "won a lawsuit and lost a cause." International Salt Co. v. United States, 332 U.S. 392, 401 (1947). By excluding consideration of terminating the Windows monopoly from their remedy calculations, Plaintiffs have ignored the central meaning of Section 2. They would have the Court sanction Microsoft's unlawful conduct allowing its monopoly to remain intact. The Court of Appeals' use of the traditional Ford/United Shoe standard clearly holds that that is not a proper remedy.

The CIS explains that the applications barrier to entry protecting Microsoft's monopoly was directly threatened by "two incarnations of middleware that, working together, had the potential to weaken the applications barrier severely without the assistance of any other middleware" -- Netscape and Java. CIS, 66 Fed. Reg. at 59464-65. Nonetheless, the PFJ inexplicably contains no provision addressing Internet browsers or cross-platform Java runtime technology, let alone any other provisions that erode the applications barrier to entry. Moreover, the proposed decree simply ignores a number of other significant ways in which the Court of Appeals held that Microsoft's practices violated the Sherman Act. Consequently, the PFJ does not "unfetter [the] market from anticompetitive conduct" or "ensure that there remain no practices likely to result in monopolization in the future." Microsoft III, 253 F.3d at 103.

Nothing in the settlement prohibits Microsoft from commingling code or binding its middleware to the operating system. This was a major issue in this litigation, and the Court of Appeals specifically found Microsoft's commingling of browser and operating system code to be anticompetitive. The danger is reinforced by the definition of "Windows Operating System Product" in Section VI.U, which states that what code comprises Windows "shall be determined by Microsoft in its sole discretion." PFJ, 66 Fed. Reg. at 59459. Thus, Microsoft can render the protections for middleware, meaningless by binding and commingling code and redefining the operating system to include the bound/commingled applications.

ProComp strongly disagrees with the notion that it is impossible to move the market forward to approximate where it would have been absent Microsoft's violations. The applications barrier to entry is not an immutable condition. There are remedial alternatives available to restore Internet browsers and cross-platform runtime technology to the position they would have achieved -- ubiquitous distribution without any "lock-in" to the Windows operating system m in the absence of Microsoft's violations. The open source Internet Explorer ("IE") licensing requirement proposed by the Litigating States does just that. More specifically, a remedy that acts directly to undermine the applications barrier to entry, for instance by requiring "porting" of the Office suite to other operating systems platforms, could potentially do precisely what Netscape and Java were poised to accomplish in 1995-98 -- "commoditize" the operating systems and thus allow operating systems competition to occur on the basis of efficiency and consumer demand, rather than hardware lock-in. In any event, by ignoring the economic importance of the competition destroyed by Microsoft's wide range of exclusionary practices, the PFJ fails to address the central lesson of this litigation. It does not redress the core Sherman Act violations on which liability was unanimously affirmed by the en bane Court of Appeals.

The relief proposed by the Litigating States acts directly to deny Microsoft the fruits of the violation (Interact Explorer licensing), pry open the operating systems market to competition (Java must carry) and erode the barrier to entry protecting Microsoft's monopoly power (applications porting). It is precisely these omissions m consequences of the Department's current, erroneously truncated remedy analysis m that fatally undermine the legal sufficiency of the PFJ. The Department's proposed remedy flatly contradicts the Court of Appeals' directives and thus "the public interest as expressed in the antitrust laws." SENATE REPORT, supra, at 5.

The PFJ purports to provide applications developers with the tools to create competing platforms, but the proposed decree fails to achieve even the narrow goals it sets out to accomplish. The PFJ neither creates the conditions under which new middleware competition can flourish nor provides OEMs with the freedom to support such middleware in the event these technologies avoid the predatory acts of Microsoft.

Most predatory conduct fails to achieve or maintain monopolization because the aggressor must incur greater costs than its prey in order to keep or drive competitors from the market. What this litigation has shown is that Microsoft has numerous weapons in its arsenal to impose far greater damage on its competitors than the loss Microsoft suffers by using such weapons. Controlling the disclosure of the Application Program Interfaces ("API") and the related technical information, imposing conditions on OEM licenses, "commingling" or bolting of software code and products are all examples of weapons Microsoft employed in its predatory attack on Netscape's Navigator and Java technologies. The PFJ does nothing to protect Microsoft from using the same tactics against any future middleware threats.

The PFJ purports only to make public those APIs between the operating system and Microsoft middleware that run on top of the operating system. It does not accomplish even that narrow result. To name a few, the convoluted definitions and exemptions to the API disclosure obligation allow Microsoft itself to decide which APIs will be subject to the disclosure requirement and when those APIs will be released. The decree also permits Microsoft to design and bundle its products in different ways to evade the disclosure requirements, for instance by permitting Microsoft in "its sole discretion" to decide what software comprises a "Windows Operating System Product." PFJ, 66 Fed. Reg. at 59459. With some simple packaging decisions, Microsoft can unilaterally dictate whether middleware competitors will receive the interoperability information necessary to innovate. In short, as explained in detail below, the API disclosure provisions are riddled with numerous deficiencies that render them ineffective in promoting competition.

These are not loopholes, but triumphal arches that allow Microsoft to proceed uninhibited by the antitrust laws. The PFJ expressly allows Microsoft to play a game of form over substance by categorizing pieces of code into different defined terms. The operation of the disclosure requirements is devoid of any notion of technological or economic efficiency.

The PFJ relies almost exclusively on OEMs to restore competition, a naive hope at best. OEMs do not have the resources or the economic incentive to create competition for Microsoft. In any event, the provisions regarding OEM flexibility to distribute competing middleware products ignore the economic realities of the software industry. Most importantly, the decree fails to provide OEMs and consumers with the flexibility to support competing middleware or other new technologies that Microsoft may deem as a threat to its monopoly position. The add/remove provisions in the proposed decree only allow for removal of end user access, i.e., the icon for Microsoft middleware, not the middleware itself. As discussed in the accompanying Declaration of Kenneth Arrow (Attachment A), Nobel laureate and the Department's own expert in Microsoft I, this perpetuates the applications barrier to entry that is at the heart of this litigation. Thus, the OEM provisions enhance rather than erode Microsoft's operating system monopoly power.

Even if these serious deficiencies in the structure, scope and language of the proposed decree were corrected, the settlement would still not create the conditions for a competitive operating systems market. The proposed decree hardly deals at all with Microsoft's likely future anticompetitive conduct. Microsoft's prodigious market power is now directed at the next threat to the Windows platform -- applications and services provided via the Internet and other networks m not the Netscape/Java threat of 1995-99. Microsoft has destroyed those revolutionary technologies that are a source of operating systems competition and has moved on to other areas that the proposed decree all but ignores.

*****

The PFJ fails to serve the public interest and to achieve the settled goals of monopolization relief reaffirmed in the Court of Appeals' decision. It ignores the changing market realities, and the core violations upheld by the D.C. Circuit. The proposed settlement exhibits an unjustifiable deference to a convicted monopolist in designing its products and determining the scope of the remedy. In doing so, it renounces its purported goal of creating the conditions for new middleware threats to flourish. Additionally, it clearly fails to deny Microsoft the "fruits" of its violations and "terminate" its monopoly power. It is precisely these flaws that fatally undermine the legal sufficiency of the PFJ. In contrast, the relief proposal by the Litigating States includes provisions, such as Interact Explorer licensing, Java must carry, applications porting, sufficient and timely disclosure of information, and the freedom to license unbundled Microsoft products, just to name a few, which deny Microsoft the fruits of the violation, pry open the OS market to competition and erode the barrier to entry protecting Microsoft's monopoly power. As a matter of law, the Department's settlement proposal cannot be said to be consistent with "the public interest as expressed in the antitrust laws," SENATE REPORT, supra, at 5, where it has proposed a remedy without reference to those laws as reiterated by the Court of Appeals in this very case.

This is the only substantial Government Section 2 case in more than 30 years litigated through trial to judgment, appeal and dual opportunities for Supreme Court review.1 A "rush to judgment" is simply not the appropriate course of judicial review under the Tunney Act, or otherwise. A decision on the adequacy of the proposed decree should therefore be deferred until after the conclusion of the evidentiary heating on the remaining Plaintiffs' ("Litigating States") relief proposals. Moreover, the normal Tunney Act flexibility accorded to the Government in offering a proposed pretrial antitrust settlement cannot hold in the unique circumstances of this case, in which the Court is obligated to conduct a searching, independent inquiry into the proposed decree, with no deference accorded to the government.

No court has ever approved an antitrust settlement where, as here, there are remaining plaintiffs in the very same consolidated action that are about to begin a full remedies hearing based on adjudicated Sherman Act liability that has been affirmed on appeal. In this unprecedented case,2 it is essential that the Court evaluate all available evidence bearing on the "'public interest" of the Department's proposed settlement.

The Tunney Act sets no deadlines. Neither the Act nor its legislative history in any way encourages "fast-track" review. Instead, the Act expressly allows the Court to set its own schedule and to tailor its judicial review process to the facts and circumstances of each antitrust case. 15 U.S.C. §§ 16(1)3 As the Senate sponsor of the Tunney Act explained:

  1. INTRODUCTION.

     

     

     

     

     

     

     

     

     

     

    1. Standard of Tunney Act Review
    2. Failure to Satisfy Settled Monopolization Remedies Law
    3. Failure to Redress Core Violations
    4. The PFJ Does Not Achieve its Purported Goals

       

       

       

       

      1. The API Disclosure Requirements
      2. OEM Desktop Flexibility
    5. The PFJ Fails to Address Competitive Issues that Will Determine the Future of the Software Industry
  2. THE COURT SHOULD DEFER DECISION ON THE PROPOSED DECREE UNTIL AFTER THE LITIGATING STATES' REMEDIES HEARING AND SHOULD APPLY THE SETTLED ANTITRUST REMEDY STANDARD EXPRESSLY REAFFIRMED IN THIS CASE BY THE COURT OF APPEALS

     

     

     

     

     

     

     

     

    1. Approving the Proposed Decree Before Completion of the Remedy Hearings Would Be Wholly Unprecedented and Highly Prejudicial

       

       

       

       

      1. Waiting to Rule on the Proposed Decree Until After the Remedies Trial Avoids Pre-Judging the Remedies Case and the Prospect of Inconsistent Rulings
      2. Deferring Ruling on the Proposed Decree Promotes the Tunney Act's Express Goal of Conserving Judicial Resources
    2. The Applicable Legal Standard for Reviewing the Proposed Decree is the Ford/United Shoe Test Specifically Mandated by the Court of Appeals
    3. The Court Owes No Tunney Act Deference To the Department in this Unprecedented Post-Trial, Post-Appeal Settlement
    4. The AT&T Model is Instructive by Conducting a Searching Inquiry into the Scope, Adequacy and Effectiveness of the Proposed Decree
  3. THE PROPOSED FINAL JUDGMENT IS INSUFFICIENT UNDER ANTITRUST REMEDIES LAW AND DOES NOT MEET THE STANDARD ARTICULATED BY THE DEPARTMENT

     

     

     

     

     

     

    1. The Decree Does Not "Undo" the Competitive Harm Resulting from Microsoft's Anticompetitive Practices
    2. The Proposed Settlement Fails to Deny Microsoft the Ill-gotten Fruits as Required by Established Antitrust Law
    3. The Decree Does Not Terminate or Redress Numerous Practices that the Court of Appeals Found to Violate the Sherman Act

       

       

       

       

       

       

      1. Integration of Windows and Middleware
      2. Coercion and Market Allocation
      3. Deception and Product Sabotage
  4. THE API DISCLOSURE AND OEM FLEXIBILITY PROVISIONS OF THE PROPOSED DECREE WILL NOT CREATE THE OPPORTUNITY FOR MIDDLEWARE COMPETITION

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    1. The Proposed Decree's Provisions for Information Disclosure Do Not Assure that Future Middleware Competitors Will Have Access to Necessary Interoperability Information

       

       

       

       

       

       

       

       

       

       

       

       

       

       

      1. The API Provision's Scope is Far Too Narrow
      2. The API Provision of the PFJ Constructs an Illusive Framework for Disclosure of Interoperability Information

         

         

        1. Defined Terms Within the API Disclosure Provision Leave All Material Disclosure Determinations to Microsoft
      3. The API Disclosure Provision Also Leaves Critical Terms Undefined
      4. Under Provision III.D, APIs Will Never be disclosed in a Timely Manner
      5. The Exceptions from and Preconditions to API Disclosure Further Narrow the Scope of an Already Unworkable Disclosure Provision
      6. Cross-Licensing of Middleware APIs
      7. Timing of API Disclosure Obligation
    2. The Communications Protocol Provisions of the Decree Do Not Require Release of any Server APIs and are Based on Terms the Department Failed to Include in the Settlement
    3. The Proposed Decree's Provisions for OEM Flexibility Do Not Open the PC Manufacturing Channel to Future Middleware Competitors

       

       

       

       

       

       

       

       

       

       

       

       

       

       

      1. The OEM Provisions Place Sole Responsibility for Introducing Middleware Competition on PC Manufacturers
      2. The Provisions Allowing OEM Flexibility Do Not Address the Key Issue of Microsoft's Ubiquitous Middleware Development Platform
      3. The OEM Provisions Do Not Create a Level Playing Field for Middleware Desktop Competition
      4. Additional OEM Provisions Further Undermine the Crucial Ability of ISVs to Differentiate Competing Middleware Products
      5. The OEM Provisions Contain Other Superfluous Terms that Substantially Limit Any Potential Market Impact
      6. The OEM Provisions Have No Impact on Java
      7. The OEM Provisions Largely Codify Microsoft's Existing Business Practices
    4. The Proposed Decree Does Not Effectively Preclude Microsoft's Exclusive Dealings
    5. Current Market and Economic Realities Demonstrate that the PFJ is Incapable of Having Any Substantial Procompetitive Impact

       

       

       

       

      1. New Monopolies Enable Microsoft to Protect its Operating System Monopoly Despite the PFJ
      2. The Proposed Settlement Ignores the Likely Tactics Microsoft Will Use to Eliminate the Next Significant Threat to its Monopoly Position
    6. The Decree Increases Microsoft's Market Dominance and Actually Worsens Competitive Conditions in the Relevant Software Markets
    7. The Settlement Would Not Have Prevented Microsoft's Unlawful Campaign Against Netscape and Java
  5. THE PROPOSED DECREE IS HOPELESSLY VAGUE AND INHERENTLY UNENFORCEABLE
  6. DIVESTITURE REMAINS THE PREFERABLE AND MOST EFFECTIVE REMEDY FOR MICROSOFT'S SECTION 2 VIOLATIONS
  7. THE COURT SHOULD CONDUCT A RIGOROUS TUNNEY ACT EXAMINATION OF THE DECREE, THE COMPETITIVE IMPACT STATEMENT AND THE DEPARTMENT'S UNSUBSTANTIATED PROJECTIONS OF FUTURE COMPETITIVE EFFECT

     

     

     

     

    1. The Complexity and Substantial National Importance of this Case, the Government's Flat Reversal of Position and its Disregard of Clear Tunney Act Obligations All Dictate the Necessity of Critical Judicial Oversight in this Landmark Proceeding

       

       

       

       

       

       

      1. This Complex, Controversial, Nationally Important Antitrust Prosecution Demands Serious Judicial Oversight
      2. Heightened Scrutiny is Needed Because Neither the Department Nor Microsoft Complied With their Respective Tunney Act Obligations
      3. The Court Should Closely Examine the Government's Reversal of Position on Relief
    2. Live Evidence is Needed on the Technical and Economic Complexities of the Software Industry and the Profound Failings of, and Harms Caused by, the PFJ
  8. CONCLUSION
    1.  

      1. Standard of Tunney Act Review
    1.  

      1. Failure to Satisfy Settled Monopolization Remedies Law
    1.  

      1. Failure to Redress Core Violations
    1.  

      1. The PFJ Does Not Achieve its Purported Goals
      1.  

        1. The API Disclosure Requirements
      1.  

        1. OEM Desktop Flexibility
    1.  

      1. The PFJ Fails to Address Competitive Issues that Will Determine the Future of the Software Industry
    1.  

      1. Approving the Proposed Decree Before Completion of the Remedy Hearings Would Be Wholly Unprecedented and Highly Prejudicial
      1.  

        1. Waiting to Rule on the Proposed Decree Until After the Remedies Trial Avoids PreJudging the Remedies Case and the Prospect of Inconsistent Rulings

The decision to make [Tunney Act] procedures discretionary is dictated by a desire to avoid needlessly complicating the consent decree process. There are some cases in which none of these procedures may be needed. On the other hand, there have been and will continue to be cases where the use of many or even all of them may be necessary. In fact, in a very few complex cases, failures to use some of the procedures might give rise to a, indication that the district court had failed to exercise its discretion properly.

119 Cong. Rec. 3453 (statement of Sen. Tunney) (emphasis added).

This highly complex case demands that the Court utilize all available procedures for evaluating the adequacy of the proposed decree and the evidentiary basis of the economic projections that underly the Department's remedial scheme. Deferring decision on the proposed decree is the only sensible approach. The Court's consideration of testimonial and other evidence on the failings of the decree will avoid unfair pre-judgment of the remedies remand and the entry of potentially conflicting relief. It also offers the most efficient means of ensuring that the many issues raised by the proposed decree and the Court of Appeals' decision receive a thorough hearing on the merits. Deferring judgment will not harm any party or inconvenience the Court, given that the Litigating States' upcoming remedies trial is scheduled to begin just thirteen days after the completion of the Tunney Act comment process.4 Indeed, neither the Justice Department nor Microsoft can claim to be prejudiced by a short deferment in judgment on the PFJ, because Microsoft represents that it is already complying with the terms of the proposed decree.

Deferral would also avoid the highly undesirable result of inconsistent judgments. The Litigating States' remedy proposal differs markedly from the proposed settlement in breadth, scope and approach. A premature ruling on the PFJ would force the Litigating States either to (1) pursue their relief proposal in full, knowing there may be inconsistent remedy orders issued by this Court that would make compliance difficult, if not impossible, or (2) stunt their case by limiting their proposed remedies to those that can be implemented in a manner consistent with the PFJ, even though they have already rejected that settlement as inadequate.

The Court faces a similar, untenable choice if it seeks to issue an early ruling on the proposed decree. The Court would have to limit its ultimate remedy order to the terms already required by its ruling on the Department's settlement, or order new remedies but vacate those portions of the PFJ that are inconsistent with the subsequent decree. This dilemma is easily avoided, however, by waiting to resolve the issues raised by the Tunney Act comments until after the Litigating States and Microsoft have had a full and fair opportunity to present evidence supporting their respective remedy proposals.

Avoiding conflicting remedial orders alone is reason enough to defer judgment on the decree. Inconsistent judgments are to be avoided in antitrust as in all complex litigation. See In re Transit Co. Tire Antitrust Litigation, 67 F.R.D. 59, 65 (W.D. Mo. 1975) (separate relief hearings "would result in duplication of effort [and] possible inconsistent judgments"). It is well-established that "[t]he avoidance of logically inconsistent judgments in the same action" is a "just reason for delay[ing]" entry of final judgment in multi-party civil actions.5

The Court should give particular weight to considerations of uniformity in this case, because of the great need to ensure that all in the software industry -- suppliers, customers and competitors -- face a fair and even playing field. As the Supreme Court has held, antitrust violations should be remedied "with as little injury as possible to the interest of the general public." United States v. American Tobacco Co., 221 U.S. 106 (1911). Thus, "the Court would be justified in rejecting the proposed decree or requiring its modification if it concluded that the decree unnecessarily conflicts with important public policies other than the policy embodied in the Sherman Act." AT&T, 552 F. Supp. at 151. In this case, such an important public policy is the uniform application of antitrust law to the national software market.

    1.  

      1. Deferring Ruling on the Proposed Decree Promotes the Tunney Act's Express Goal of Conserving Judicial Resources

Deferring judgment on the proposed decree will also conserve judicial resources by allowing the Court to determine which questions raised by the PFJ can be resolved by the testimony and other evidence offered in the remedy trial. The Court may then limit or avoid duplicative evidence that must be adduced to assess whether the decree meets the applicable substantive standard for Tunney Act judicial review.

Consent decrees subject to Tunney Act review are generally used to obviate trial -- to avoid "extended proceedings" and provide a "'prompt and less costly'" means of resolving antitrust suits pre-litigation. CIS, 66 Fed. Reg. at 59476 (quoting 119 Cong. Rec. 24598 (1973)). Even the Department of Justice, in discussing the negotiation of antitrust settlements in its Practice Manual, identifies the consent decree as the best way to obtain relief "without taking the case to trial." Antitrust Division Manual, Ch. IV, § E, at 50 (3 rd ed. 1998) (emphasis added). Here, however, a liabilities trial has already occurred, and a remedies trial must occur regardless of when or whether the proposed Department settlement is approved. There is little or no court action to avoId. As a result, judicial resources are best conserved and most efficiently allocated by holding the remedies trial before ruling on the PFJ.

  1.  

    1. The Applicable Legal Standard for Reviewing the Proposed Decree is the Ford/United Shoe Test Specifically Mandated by the Court of Appeals

In no reported case since adoption of the Tunney Act in 1974 has the Department sought to settle a monopolization action after prevailing at trial and on appeal. The CIS nonetheless suggests that in assessing the adequacy of the proposed decree under the Act, this Court must approve a settlement that is less than the remedy the Court would otherwise impose of its own accord. CIS, 66 Fed. Reg. at 59476 (citations omitted). In the unprecedented procedural posture of this case, it cannot.

The Court of Appeals agreed that relief in this case must seek to "terminate" Microsoft's operating system monopoly, to "unfetter" barriers to competition to the operating systems market, to "deny" Microsoft the "fruits" of its statutory violations, and to "ensure" there are no practices "'likely to result in monopolization in the future"'6 That mandate is binding on this Court as well as the litigants. The Supreme Court has "consistently held that an inferior court has no power or authority to deviate from the mandate issued by an appellate court." Briggs v. Pennsylvania R. Co., 334 U.S. 304, 306 (1948). Indeed, even prior to the Tunney Act the Supreme Court emphasized that in antitrust cases, "[t]he Department of Justice ... by stipulation or otherwise has no authority to circumscribe the power of the courts to see that [their] mandate is carried out." Cascade Natural Gas Corp. v. El Paso Natural Gas Co., 386 U.S. 129, 136 (1967). 7 Consequently, in the unique procedural posture of this case, the "public interest as expressed in the antitrust laws," SENATE REPORT, supra, at 5, is the Court of Appeals' mandate itself.

The D.C. Circuit did not establish a new legal standard for monopolization relief, but rather adopted the traditional test developed by the Supreme Court decades ago. See Microsoft. III, 253 F.3d at 103 (quoting Ford Motor Co. v United States, 405 U.S. 562, 577 (1972), and United States v. United Shoe Mach. Corp., 391 U.S. 244, 250 (1968)). Notably, however, the CIS does not even cite, let alone argue, that the PFJ meets the D.C. Circuit's remedial standard. The Department instead offers its own view that "[a]ppropriate injunctive relief in an antitrust case should: (1) [e]nd the unlawful conduct; (2) avoid a recurrence of the violation and others like it; and (3) undo its anticompetitive consequences." CIS, 66 Fed. Reg. at 59465 (citations omitted). This lesser standard is invalid because it ignores the Supreme Court's directives to "'terminate" the monopoly and to eradicate the "fruits" enjoyed by the unlawful monopolist.

To the extent that DOJ may contend this case is different because the acquisition of Microsoft's monopoly was not challenged, rather the unlawful maintenance of that monopoly, it would be incorrect. There is no legal basis to distinguish between the methods of monopolizalion either for liability or relief purposes, and neither DOJ nor Microsoft has ever cited a case making such a distinction. The adverse consumer welfare and economic efficiency consequences of monopoly power are the same whether a monopoly was illegally acquired, illegally maintained or both. Indeed, the D.C. Circuit was well aware that the achievement by Microsoft of a Windows monopoly in the first instance was not alleged to he unlawful, 8 but nonetheless specifically adopted the traditional Ford/United Shoe remedy standard.

The Court of Appeals' carefully crafted and detailed opinion can hardly be deemed to have applied this standard by accident. Accordingly, notwithstanding Microsoft's claim, it is simply not true that "contrary to the critics' overheated rhetoric, there is no basis for relief designed to terminate an `illegal monopoly.'"9 The fact that a monopoly was acquired lawfully does not provide any defense, because the monopolist forfeits its right to continue to hold even a lawfully acquired monopoly when it violates the Sherman Act in its preservation.10

The Department and Microsoft may argue that the Court of Appeals' "drastic" modification of liability is of crucial significance in evaluating the scope of a remedy. See Microsoft III, 253 F.3d at 105. What this contention ignores is that the Court of Appeals reversed or remanded separate, distinguishable legal theories for Sherman Act liability that all arose from the same set of operative facts. As the government explained to the Supreme Court:

The court of appeals affirmed the district court's central ruling that Microsoft violated Section 2 of the Sherman Act by engaging in an unlawful course of conduct to maintain its monopoly of the market for Intel-compatible PC operating systems. With minor exceptions, the court agreed with the district court's findings and conclusions that Microsoft's restrictions on original equipment manufacturers; its bundling of Internet Explorer into Windows; its dealings with internet access providers, independent software vendors, and Apple Computers; and its efforts to contain and to subvert Java technologies that threatened Microsoft's operating system monopoly, all served unlawfully to maintain the Windows monopoly.

Brief for the United States in Opposition [To Certiorari], Microsoft Corp. v. United States, No. 01-236, at 5 (S. Ct. filed Aug. 2001) (emphasis added; citations omitted). And the Court of Appeals added the explicit, highly unusual caution that "[n]othing in the Court's opinion is intended to preclude the District Court's consideration of remedy issues."11 That the lesser included offenses of attempted monopolization and tying were not upheld does nothing to subtract from the seriousness of the widespread Section 2 violations affirmed by the Court of Appeals or the Court's explicit reaffirmation of the Ford/United Shoe standard for antitrust relief.

The CIS" lengthy recitation of cases indicating that a Tunney Act court must accept a lesser remedy than might be obtained after trial is irrelevant. CIS, 66 Fed. Reg. at 59475-76. None of these cases arose in the context of a post-trial settlement of a Section 2 monopolization claim and thus none resolved whether the remedial standard adopted by the federal courts in a fully litigated antitrust case must be jettisoned if the government subsequently agrees to a consensual decree.12 More importantly, the Department has not offered any statutory or policy basis 1o justify its wooden invocation of Tunney Act dicta to this case. By failing to articulate any legitimate justification for the deference it insists upon, the Department's position suggests that it is designed to shield the merits of the decree from critique by the Court and to mask the weakness of the proposed settlement, rather than to satisfy any compelling institutional or constitutional policy.

The only suggestion in the CIS as to any basis for a limited scope of judicial review is just wrong. The Department insists that a different relief standard is "particularly" appropriate "where, as here, court's review of the decree is informed not merely by the allegations contained in the Complaint, but also by the extensive factual and legal record resulting from the district and appellate court proceedings." CIS, 66 Fed. Reg. at 59476. That has things backwards. In normal Tunney Act cases, the law is clear that respect is to be accorded to the Department's antitrust enforcement judgments w its "perceptions of the market structure and its view of the nature of the case" -- precisely because there is no factual or legal record before the court. Microsoft I, 56 F.3d at 1448. When a Sherman Act case has been litigated and affirmed on appeal, however, the district court is fully capable of assessing the proposed remedy against that record and its "familiarity with the market involved." Id. at 1461.13 In short, the Court of Appeals" mandate, and its application of traditional monopolization remedy law, is the applicable standard against which to measure the scope and efficacy of the PFJ.

  1.  

    1. The Court Owes No Tunney Act Deference To the Department in this Unprecedented Post-Trial, Post-Appeal Settlement

The language, legislative history and purpose of the Tunney Act all indicate that the relatively deferential attitude ordinarily adopted by courts to antitrust settlements should not constrain this Court's inquiry into the legal sufficiency and acceptability of the remedy proposed by Microsoft, the Department and the Settling States.

The leading authority on Tunney Act deference is not at all to the contrary. In Microsoft I, the D.C. Circuit reversed the district judge for "construet[ing] his own hypothetical case and then evaluat[ing] the decree against that case." 56 F.3d at 1459. Here, no one is asking the Court to consider claims the government chose not to pursue. Quite to the contrary. ProComp asks the Court to grant effective relief for those claims that the Department actually brought and on which it has already prevailed.

The difference in judicial deference owed to the Executive Branch is easily understood against this backdrop. The Tunney Act was created as a "check on prosecutorial discretion," In re IBM, 687 F.2d 591,595 (2d Cir. 1982), that is, "a check.., on the government's expertise m or at the least, its exercise of it -- even on its good faith." United States v. Gillette Co., 406 F. Supp. 713, 715 (D. Mass. 1975). The concern of Congress was the predominance of pretrial antitrust settlements that otherwise would never reach a courtroom,14 For these reasons, the Microsoft I decision cautions that a district court's Tunney Act obligation to avoid delving too deeply into the substantive merits of antitrust settlements arises because "there are no findings that the defendant has actually engaged in illegal practices." Microsoft I, 56 F.3d at 1460 (emphasis in original).

That is obviously not the case here. Microsoft's liability for a wide variety of exclusionary practices violative of Section 2 of the Sherman Act has been adjudicated and affirmed on appeal. In contrast, it is clear that the Tunney Act was predicated on the assumption that proposed consent decrees would be presented in the context of pretrial settlements over which the courts had yet to engage in an exercise of judicial power. See 15 U.S.C. § 16(e)(1) (district court must "evaluate the competitive impact of... termination of alleged violations ...."); § 16(e)(2) (court must consider "the public benefit, if any, to be derived from a determination of the issues at trial"). Unlike the ordinary Tunney Act situation, in this case it is indisputably not correct to conclude that "[r]emedies which appear less than vigorous may well reflect an underlying weakness in the government's case." Microsoft I, 56 F.3d at 1461.

The Tunney Act's underlying principles of judicial restraint applicable to the exercise of prosecutorial discretion -- deeply rooted in separation of powers -- simply do not apply here.15 In the typical Tunney Act case, courts have made "no judicial finding of relevant markets, closed or otherwise, to be opened or of anticompetitive activity to be prevented," is by definition not present in a post-appeal antitrust settlement. Maryland v. United States, 460 U.S. 1001, 1004 (1983) (per curiam) (Rehnquist, J., dissenting). The separation of powers concerns in a post-trial settlement are actually reversed. 16 The source of Tunney Act deference is that "the court's authority to review a decree depends entirely on the government's exercising its prosecutorial discretion by bringing a case in the first instance." Microsoft I, 56 F.3d at 1459-60 (emphasis added). In contrast, deferential review of a post-trial settlement in a fully litigated, finally appealed antitrust prosecution would directly contradict the "mandate rule" of Cascade Natural Gas and would be inconsistent with this Court's Article III obligations.

The Court of Appeals has explained that because there are "constitutional difficulties that inhere in this statute," it is "inappropriate for the [district] judge to measure the remedies in the decree as if they were fashioned after trial." Microsoft I, 56 F.3d at 1461. The converse is true when a remedy is in fact fashioned after trial. In that situation, the court has already made the factual and legal findings that do not exist in the ordinary consent decree situation, and therefore is not required to "give due respect to the Justice Department's perception of the market structure and its view of the nature of the case." Id. at 1461.

In light of these serious constitutional concerns, this Court should not and cannot accept a proposed decree that falls short of the remedy that the Court would impose based on its own, independent assessment of the record and the Court of Appeals' remand mandate. The Court is undoubtedly aware of the long-standing maxim that constitutional questions are to be avoided if a statute can be interpreted so as not to raise them. E.g., Richmond Screw Anchor Co., 275 U.S. 331, 346 (1928). In the context of this unprecedented Tunney Act case, simple prudence dictates that the Court should construe the Act to dispense with deference to the government where liability has been adjudicated and affirmed on appeal, and thus avoid any possibility of a constitutional challenge to its remand decision on remedies.

Before turning to a substantive critique of the PFJ, it is appropriate to discuss the close parallels between Microsoft and the last major monopolization settlement presented by the Department and decided by this Court (Harold Greene, J.) under the Tunney Act. United States v. AT&T, 552 F. Supp. at 151.

Before the AT&T settlement was proposed, Judge Greene had heard the vast majority of the evidence--on all issues except remedy -- and had denied AT&T's motion to dismiss on the merits after the close of the government's case-in-chief. United States v. AT&T, 524 F. Supp. 1336, 1380 (D.D.C. 1981). Following a wide-ranging Tunney Act process that included evidentiary hearings, third-party submissions, and several days of oral augment, Judge Greene declined to approve the decree as proposed -- even though it required divestiture of the Bell system -- because he concluded that it was substantively inadequate, precluded the Court from effective oversight and enforcement, and posed a risk of harming third parties.

The Judge insisted upon substantial modifications to the proposed decree before he would enter the settlement under the Tunney Act's public interest standard. In doing so, Judge Greene explained that ,AT&T was "not an ordinary antitrust case." 552 F. Supp. at 151. Instead, in that case as in this one, the proposed decree was an "enormous undertaking" having "significant consequences for an unusually large number of ratepayers [i.e., consumers], shareholders... and competitors." 552 F. Supp. at 152. In addition, and also like in this case, the Court would "be able to render sound judgments" because it "ha[d] already heard what probably amounts to well over ninety percent of the parties' evidence both quantitatively and qualitatively, as well as all of their legal arguments." Id. For these reasons, Judge Greene concluded that "it does not follow that [the Court] must unquestionably accept a consent decree as long as it somehow, and, however inadequately, deals with the antitrust problems implicated in the lawsuit." Id. Instead, Judge Greene reasoned it was his responsibility to ensure the decree protected consumers, opened the relevant markets to effective competition in a timely manner, and would be readily enforceable. The Supreme Court affirmed. Maryland v. United States, 460 U.S. 1001 (1983) (per curiam); California v. United States, 464 U.S. 1013 (1983)(per curiam).

Like AT&T, this has been a long, exceedingly complex and very hard-fought case. Unlike AT&T, however, in this litigation the proposed settlement comes after the trial was completed and after the courts finally adjudicated the defendant's liability. Also' unlike AT&T, moreover, here the government has not succeeded in obtaining via settlement anything close to the relief it sought on the merits from this Court. We have submitted our view that deference to the Department of Justice is inappropriate in this unique case. The AT&T model provides a benchmark for the scope of Tunney Act judicial review which, if anything, should be exceeded given the far more advanced procedural posture here. This Court cannot err by following an expanded AT&T-like procedure. The converse may not be true.

*****

In sum, the Litigating States must be allowed to proceed free from the interference that early Court approval of the proposed decree would entail. When the Court does assess and rule on the decree, it must undertake a thorough, independent analysis of whether the settlement protects the public interest and satisfies the D.C. Circuit's mandate for effective relief. Delegating this core judicial responsibility to the Department would violate the Tunney Act, raise serious separation-of-powers concerns and leave the public without effective redress against a proven monopolist.

The proposed settlement does not meet the D.C. Circuit's remedial standard, quoted above, to terminate the monopoly, deny the defendant its ill-gotten fruits, and ensure that monopoly practices cannot arise in the future. The CIS does not even cite, let alone argue that the PFJ meets the D.C. Circuit's remedial standard. Indeed, the PFJ does not even meet the lesser standard, articulated in the CIS, to "(1) end the unlawful conduct; (2) 'avoid a recurrence of the violation' and others like it; and (3) undo its anticompetitive consequences." CIS, 66 Fed. Reg. at 59465 (citations omitted).

In fact, the proposed settlement fails to undo the competitive harm from the core antitrust violations affirmed by the Court of Appeals, and does not even address a series of additional violations of the Sherman Act upheld by the Court of Appeals.

Netscape's browser and Sun's Java were revolutionary middleware technologies which allowed Independent Software Vendors CISVs") to write programs that would run on any operating system, thus potentially making hardware platforms - and correspondingly, operating systems -- a matter of competitive and technological indifference. Microsoft both recognized and feared that this new model for software development would be an inflection point in the computer industry, 17 and accordingly launched a multi-faceted campaign to destroy the economic and technological viability of these forms of competing middleware.

United States v. Microsoft Corp., 87 F. Supp.2d 30, 38-39 (D.D.C. 2000) (Conclusions of Law), affirmed in part, 253 F.3d 34 (D.C. Cir.), cert. denied, 530 U.S. 1301 (2000).

The Court of Appeals affirmed the illegality of Microsoft's campaign to destroy the competitive threat of Internet browsers and cross-platform Java technology. Further, as the Court of Appeals explained, Sun's distribution arrangement with Netscape was key to .,"'achiev[ing] the necessary ubiquity on Windows" required for Java to serve "as the ubiquitous platform for software development." Microsoft III, 253 F.3d at 74, 75. By foreclosing Netscape from the market, Microsoft thus eliminated the ability of the Java runtime environment to develop into a ubiquitous, competitive alternative to Windows for applications development.18 Today, the anticonsumer effects are even more clear because Microsoft has integrated its own Internet browsing and Java-like runtime technologies into Windows.

No other middleware technologies introduced since Netscape and Java have evolved to the point where they could directly challenge, and substitute for, Windows. While a variety of middleware is available today, most if not all presently lack the capability to serve as major platforms for software development. As Professor Arrow explains, no middleware entrant currently exists that offers the user base, head start and technological capability to supplant Windows, characteristics enjoyed by both Netscape and Java before Microsoft eliminated them as serious competitive threats. Arrow Decl. ¶¶ 25-30. Middleware is more often a short-run complement to the operating system rather than a substitute. It is only when particularly "disruptive technologies" can achieve the distribution scale and scope of exposed APIs to permit substitution among operating systems -- the "commoditized" operating systems feared by Microsoft -- that middleware becomes a long-run competitive substitute for the operating systems. Id. ¶¶ 16-17, 33-34. Powerful middleware substitutes for Microsoft's operating systems monopoly just do not come along every week. Id. ¶ 18 ("Technological disruptions such as the middleware threat of the mid-1990s do not occur continually.")

Microsoft's anticompetitive practices destroyed the prospect that middleware could effect such a fundamental change (sometimes called a "paradigm shift') in the operating system market and, thus, have substantially entrenched its monopoly power. "Microsoft's significantly enhanced ability to stem potential middleware threats is the result, in very substantial part, of its past anticompetitive campaign against Netscape."19 As Professor Arrow explains, "[a]t times of technological disruption, the forces of dynamic competition play an especially important role." Id. ¶ 18. See Findings of Fact ¶ 377 ("Microsoft "successfully denied" Netscape status of "the standard software for browsing the Web").20 It will be "exceedingly difficult now, even with the best of remedies, to re-establish middleware fully as the kind of competitive threat to Microsoft's monopoly power that it posed in the mid-1990s." Arrow Decl. ¶¶ 5, 18, 71. Thus, as Professor Arrow concludes, it is "highly unlikely" that "market forces alone will lead to the development of innovative middleware that creates the same competitive risk to Microsoft that it faced from Navigator and Java in 1995." Id. ¶ 30.

Despite these compelling facts, the Department and the Settling States have proposed middleware provisions that ignore the core Internet browser and Java runtime technologies in favor of undefined, future middleware that may or may not present the same viable cross-platform capabilities. The Department's remedy ratifies the illegal acts that Microsoft committed, instead of moving the market forward to where it would be today had Netscape and Java been permitted to grow without illegal Section 2 constraint.21 The Supreme Court, however, has squarely rejected the proposition that "antitrust violators may not be required to do more than return the market to the status quo ante." Ford, 405 U.S. at 573 n.8.

Assistant Attorney General James explains that the settlement is designed "to recreate the potential for the emergence of competitive alternatives to Microsoft's operating system monopoly through middleware innovations."22 But without identifying any comparable middleware products today or predicting that truly competitive middleware will be introduced in the near-term future that could become substitutes for Windows, the Department does not have a verifiable basis to project that such a remedy will have any impact on competition. The Department's proposed settlement posits only hypothetical future entry to counteract the very real monopoly power of Windows today.

In addition, Microsoft's integration of Internet browsing and runtime environment technology into Windows allows Microsoft today to prevent any competing middleware technology from achieving ubiquity, thus preserving the applications barrier to entry.23 Unlike the Netscape and Java technologies that Microsoft's unlawful practices eliminated as serious competitive threats, however, Microsoft middleware is not cross-platform. Consequently, by sanctioning Microsoft's integration of middleware into Windows and by failing to redress its illegal campaign against Netscape and Java, the proposed decree enhances, rather than reduces, Microsoft's operating systems monopoly power. In short, the PFJ does not undo the competitive harm resulting from Microsoft's unlawful assault on Netscape and Java, and therefore, fails to meet the requirements of established antitrust law and the lesser standard the Department has set.

Equally importantly, in clear denial of the standards under established antitrust remedies law, the decree permits Microsoft to retain the fruits of its statutory violations. See United Shoe, 391 U.S. at 252. It "would be inimical to the purpose of the Sherman Act to allow monopolists free rein to squash nascent, albeit unproven, competitors at will -- particularly in industries marked by rapid technological advance and frequent paradigm shifts." Microsoft III, 253 F.3d at 79. Consequently, because the PFJ fails to "deny to [Microsoft] the fruits of its statutory violation," id. at 103, it cannot be approved by this Court.

There are remedial alternatives available to restore Internet browsers and cross-platform runtime technology to the position they would have achieved -- ubiquitous distribution without any "lock-in" to the Windows operating systems D in the absence of Microsoft's violations. The open source Internet Explorer licensing requirement proposed by the Litigating States does precisely that. A remedy that acts directly to undermine the applications barrier to entry, for instance by requiring "porting" of the Office suite to other operating system platforms, would act to commoditize the operating system and thus allow operating systems competition to occur on the basis of efficiency, technology and consumer demand. 24 See Arrow Decl. ¶ 46-49.25

In sharp contrast, the proposed decree is described in the CIS as encouraging the development of future technologies that "over time could help lower the applications barrier to entry." CIS, 66 Fed. Reg. at 59467 (emphasis added). As no significant platform innovations with the characteristics necessary to substitute for Windows have developed since Microsoft's multi-faceted predatory campaign was launched, there is simply no reason to believe that new Netscape and Java-like middleware competition could flourish today, especially under the decree, which not only does not lower the applications barrier to entry - it actually preserves and strengthens. Therefore, the remedy fails to meet the standard set by established antitrust remedies law by refusing to deny Microsoft the fruits of its unlawful acts, or providing any viable alternative mechanism.

The decree now proposed by the government improperly permits Microsoft to continue some of the very exclusionary practices that the Court of Appeals explicitly held were illegal. Both established antitrust remedies law and the lesser standard articulated by the Department require that the settlement terminate and redress the unlawful conduct affirmed by the Court of Appeals. The settlement does not.

The PFJ does not preclude Microsoft from integrating middleware software, or any other technology that could erode the applications barrier to entry, into its operating system products. Hence, the proposed decree not only does not end Microsoft's practice of binding competing technologies to Windows, but allows middleware integration to continue unabated in the future.

This failure is impossible to square with the Court of Appeals' decision. First, the Court specifically held that "Microsoft's decision to bind IE to Windows 98" by "commingling of code" was an unlawfully "exclusionary" practice. Microsoft III, 253 F.3d at 64-67. The Court of Appeals' discussion is worthy of close attention became it sheds light on the magnitude of the PFJ's failure with respect to product integration. The Court explained that "[t]echnologically binding IE to Windows ... both prevented OEMs from pre-installing other browsers and deterred consumers from using them," Microsoft III, 253 F.3d at 64 (citing Findings of Fact ¶ 159), and thus that "Microsoft's... commingling of browser and operating system code constitute[s] exclusionary conduct, in violation of ¶ 2." Id. at 67. Moreover, the Court of Appeals emphasized that its Section 2 holding rebuffed Microsoft's arguments "not only that its integration of IE into Windows is innovative and beneficial, but also that it requires non-removal of IE." Id. at 89.

Second, the Court summarily denied Microsoft's rehearing petition challenging both the factual basis and the legal sufficiency of the code commingling holding.26 The Court denied without opinion Microsoft's rehearing petition, in which the defendant Microsoft argued that "`commingling of code' is not 'per se pernicious or even suspicious'" and urged the D.C. Circuit to (1) reverse the applicable Findings of Fact, and (2) limit its liability holding with respect to bundling of Internet Explorer to Microsoft's refusal to permit "[r]emoval of end-user access by OEMs."27

In spite of these repeated holdings, the PFJ reverses course and adopts the position for which Microsoft argued on rehearing. The proposed settlement allows OF. Ms to remove "access to" middleware -- that is, icons w from the desktop and related areas of the Windows user interface. Conversely, it permits Microsoft to commingle any code and prohibits OEMs from deleting Microsoft middleware code from the operating system software. Thus, although the Court of Appeals expressly reiterated that technological integration of Interact Explorer violated Section 2, the PFJ fails to impose any limits whatsoever on current or future bundling of middleware and operating systems software.

Assistant Attorney General James has testified that "[t]he court of appeals ruled that, albeit with some limits, Microsoft could lawfully integrate new functions into the operating system."28 This is a mischaracterization. The D.C. Circuit remanded the tying claim for rule of reason analysis, Microsoft III, 253 F.3d at 84-95, but did not conclude that any product integration litigated at trial was "lawful." The only general statement the Court made was that the "integration of additional software functionality into an operating systems" is not a per se unlawful Section 1 offense.29

The D.C. Circuit affirmed that Microsoft's coercion of Apple, by threatening to withhold porting of Office to the Macintosh operating systems platform, was unlawful. The District Court likewise found that Microsoft attempted (this time without success) to coerce Apple into abandoning development of its QuickTime software, in order to limit "the development of multimedia content that would run cross-platform." Findings of Fact ¶ 110.

Microsoft also coerced Intel -- Microsoft's partner in the IBM-compatible PC market m into abandoning its work on creation of Java-compatible multimedia software.(30)Microsoft III, 253 F.3d at 77. In fact, the Court specifically ruled that "Microsoft's threats to Intel were exclusionary, in violation of § 2 of the Sherman Act." Id. at 78 (emphasis added). And the District Court, again without objection by the Court of Appeals, also found that Microsoft pressured Intel to cease development of "Native Signal Processing ('NSP') software, [which] would endow Intel microprocessors with substantially enhanced video and graphics performance,"31 as well as "using revenues from its microprocessor business to fund the development and distribution of free platform-level software," 32 in order to "halt the development of software that presented developers with a set of operating-system-independent interfaces." 33

The proposed decree does not constrain Microsoft's ability to engage in this sort of coercive conduct to impede competition from potential middleware or other software rivals.Section III.F of the PFJ precludes Microsoft only from "retaliating" against ISVs and IHVs that develop or use competing platform software and from entering into exclusive dealings with ISVs (but curiously not IHVs) for platform software. It does not, however, deal with the use of threats and coercion to compel adherence to Microsoft's objectives short of an actual agreement.34 As both a legal and practical matter, the PFJ fails to redress the Court of Appeals' holding that Microsoft's "threats" to its competitors and partners violated Section 2.

The Department recognizes that among the practices the D.C. Circuit ruled unlawful was Microsoft's "attempt[s] to mislead and threaten software developers in order to contain and subvert Java middleware technologies that threatened Microsoft's operating system monopoly."35 Yet the PFJ does not prohibit Microsoft from misleading developers or, as it did with Java, creating supposedly "open" software development tools that, in reality, are compatible only with Windows. See Microsoft III, 253 F.3d at 77. These sorts of practices are added in the Litigating States remedy proposal.36 By preventing Microsoft from intentionally sabotaging competing applications or middleware products, and by requiring that if Microsoft implements open industry standards it not "pollute" those standards with proprietary, Windows-specific protocols and features, such relief would constrain the exclusionary conduct held unlawful by the D.C. Circuit. The Department's proposed settlement does not.

*****

The Department's claim that the decree "ends" Microsoft's unlawful practices is incorrect. It is also wrong as a matter of remedies jurisprudence. Antitrust courts must "start from the premise that an injunction against future violations is not adequate to protect the public interest."37 In order to prevent "a recurrence of the violation" found, antitrust courts are not limited to imposing "a simple proscription against the precise conduct [the violator] previously pursued." 38

Yet Assistant Attorney General James recently testified that the government's remedy proposal is "focused on the specific practices that the court [of appeals] had ruled unlawful."39 This focus on specific practices does not eliminate those practices. In any event, it is settled that antitrust relief may prohibit even otherwise lawful conduct if it "represents a reasonable method of eliminating the consequences of the illegal conduct" or preventing its resumption. 40

The proposed decree neither provides future middleware competitors with the API information needed to develop interoperable products nor opens the OEM distribution channel to effective competition from any such new entrants. To a surprisingly large degree, the PFJ's provisions simply memorialize Microsoft's current business practices. Indeed, the PFJ would not have thwarted Microsoft's 1995-98 unlawful campaign against Net. scape and Java had the decree been in place at that time.

As a consequence, the PFJ will discourage, rather than encourage, investment and innovation in new middleware technology. Future middleware competitors, faced with the very real prospect that they may not be able to obtain necessary API information from Microsoft or access to the OEM distribution channel, will have virtually no incentive to invest in time development of new and innovative middleware technology. Moreover, even if the PFJ actually did "creat[e] the opportunity for software developers and other computer industry participants to develop new middleware products that compete directly with Microsoft," as the CIS states, the five-year term of the proposed decree is far too short to promote innovation and investment in middleware technology. In short, under the PFJ the status quo that prompted the Department of Justice and State Attorneys General to bring these actions against Microsoft will perpetuate.

As the Supreme Court emphasized in its landmark ruling in the DuPont antitrust case, "It]he proper disposition of antitrust cases is obviously of great public importance, and their remedial phase, more often than not, is crucial. For the suit has been a futile exercise if the Government proves a violation but fails to secure a remedy adequate to redress it." United States v. E.I. du Pont de Nemours & Co., 366 U.S. 316, 323 (1961). Under any appropriate standard for judging the effectiveness of antitrust remedies, the key portions of the PFJ are just such an exercise in futility.

The Department proclaims that the API disclosure provisions of the proposed decree will create middleware competition by requiring Microsoft to disclose all of the interfaces and related technical information that Microsoft's middleware uses to intemperate with the Windows operating system." CIS, 66 Fed. Reg. at 59460. 41 That is simply not accomplished by a literal reading of the proposed decree's API provisions. The proposed decree does not provide middleware competitors with the information needed to intemperate, but rather allows Microsoft itself to decide whether, when and which APIs to release to potential competitors.

There are four provisions of the proposed decree that seek to address the issues of information disclosure for the purposes of enabling interoperability. Section III.D addresses the disclosure of APIs and Section III.E addresses the disclosure of communications protocols with server operating systems products. These provisions need to be read in concert with Section HI J, which substantially narrows the scope of required disclosures, and Section HI.L5, which potentially undermines the information disclosure regime by granting to Microsoft rights to insist on cross licenses to intellectual property developed through the use of Microsoft's APIs. Lastly, these provisions are dependent on a multitude of definitions which include Sections VI.A "APIs"; VI.B "Communications Protocol"; VI.E "Documentation"; VI.J "Microsoft Middleware"; VI.R "Timely Manner"; VI.T "'Trademarked"; and VI.U "Windows Operating System Product." To understand the impact of the PFJ on information disclosure, all these provisions must be read together, along with their subordinate definitions and exceptions.

The PFJ falls short of requiting the disclosure of APIs that innovative middleware technologies might need. Section III.D requires only that Microsoft disclose: "the APIs and related Documentation that are used by Microsoft Middleware to intemperate with a Windows Operating System Product." PFJ, 66 Fed. Reg. at 59454 (emphasis added).

This obligation is plainly too narrow to support real middleware competition. If a potential competitor creates a new form of middleware that provides innovative functionalities, it will not be entitled to the necessary APIs, if those APIs are not "used by Microsoft Middleware to interoperate with a Windows Operating System Product" within the scope of Section III.D. This necessarily limits future innovation to the parameters set by the breadth of Microsoft's Middleware functionality, it creates a regime where competitors must always follow, as opposed to lead, middleware innovations. For example, when Netscape was attempting to achieve full 38 interoperability with the Windows operating system in 1995, Netscape required the APIs for Windows, not merely the APIs between Windows and Microsoft's browser, which was just in the process of development.42

Further, under Section III.D, Microsoft must disclose "for the sole purpose of interoperating with a Windows Operating Systems Product... APIs and related documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product." PFJ, 66 Fed. Reg. at 59454. Windows Operating Systems Products are defined in Section VI.U to include Windows 2000 Professional and Windows XP for the PC. Thus, Microsoft does not have to disclose APIs its middleware uses to interoperate with Microsoft operating systems on servers or handhelds. And for those APIs that Microsoft does disclose, Microsoft is permitted to limit their use by third parties "solely for the purpose of interoperating with a Windows Operating System Product." Id. at 59454. Thus, Microsoft can distribute middleware products that interoperate with all of its client and server operating systems along with its applications such as Office, while competitors' middleware products will be limited to using any disclosed APIs to intemperate only with PC versions of Windows. This limitation certainly does not provide a level playing field for competitive middleware.

Close review of the plain language of the API disclosure provision and its subordinate definitions reveals that the provision is quite illusory. A careful examination of these complex provisions of the proposed decree -- represented graphically in Figure 1 on the next page reveals that, despite their length, they are nonetheless circular and illusory.

Figure 1         
 Are APIs Disclosable?
[D]

Section III.D sets forth the basic obligation that Microsoft must disclose to competitors "the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product." The PFJ therefore establishes a regime where Microsoft must disclose the "APIs," a defined tern, that are used by "Microsoft Middleware," a defined term, to intemperate with a "Windows Operating System Product," a defined term.

The defined terms within Section III.D reveal that the PFJ's API disclosure obligations are without substance. As stated, the provision calls for the disclosure of "APIs" between "Microsoft Middleware" and the "Windows Operating System Product." Taking those definitions in reverse order demonstrates that the Department cannot possibly predict precisely what information is required to be disclosed under Section III.D because most of the definitions are left to Microsoft.

First, Section VI.U provides the definition of a "Windows Operating System Product." A Windows Operating System Product is defined as:

The CIS explains that, pursuant to the proviso in the final sentence, this definition means that "the software code that comprises a Windows Operating System Product is determined by Microsoft's packaging decisions (i.e., by what it chooses to ship as 'Windows')." CIS, 66 Fed. Reg. At 59459. Under this approach, therefore, Microsoft retains the unilateral discretion to determine what constitutes Windows for purposes of its API disclosure obligations. If middleware software is included with Windows, it is thus part of a Windows Operating System Product for the purposes of this definition. It follows that if Microsoft chooses "at its sole discretion" to include middleware as part of Windows it escapes the disclosure requirements of Section III.D.

The other "bookend" of Microsoft's information disclosure requirement rests on definition VI.J, "Microsoft Middleware." First, it is critical to understand that provision III.D does not invoke definition VI.K "Microsoft Middleware Product," which clearly sets forth that "Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express and their successors" are "'Microsoft Middleware Products." Id. Rather, the provision rests on the far more ambiguous definition of "Microsoft Middleware." Under definition VI.J, Microsoft Middleware means:

The weakness of this definition is immediately apparent. The first prong of the definition requires Microsoft middleware to be distributed "separately from a Windows Operating System Product." Therefore, if Microsoft decides to include middleware as part of Windows as it is entitled to do "in its sole discretion" it cannot possibly be Microsoft Middleware because it will not be "distributed separately." Alternatively, because middleware is "Microsoft Middleware" only if it is distributed "to update" Windows, Microsoft can as easily avoid any API disclosure obligations by distributing middleware as a separate application rather than as a Windows update.43

Second, in order to qualify as Microsoft Middleware, the middleware must also be "Trademarked." Section VI.T of the PFJ defines "'Trademarked" in two ways. The first clause of the definition states:

PFJ, 66 Fed. Reg. 59459.

We cannot fathom the rationale for resting the definition of Middleware on whether or not a particular technology is trademarked. The Department contends that the definition is "designed to ensure that the Microsoft Middleware ... that Microsoft distributes (either for free or for sale) to the market as commercial products are covered by the Proposed Final Judgment." CIS, 66 Fed. Reg. at 59465. Yet, again it appears that exactly the opposite is true based on the second part of the "Trademarked" definition, which states:

PFJ, 66 Fed. Reg. at 59459 (emphasis added).

Under this definition, if the product is distributed as "Windows® Media Player" as opposed to "Windows Media® Player" it would not be covered. That is because the formulation of the name "Windows® Media Player" would be "comprised of the ... [Windows®] trademarks together with a descriptive or generic term [Media Player]."

An analysis of each of Microsoft's Middleware Products demonstrates the problem. "Microsoft Internet Explorer" could easily be distributed as Microsoft® plus the generic or descriptive term "Internet Explorer" or "Windows Messenger" as Windows® plus the generic or descriptive term "Messenger." As a factual matter, "Microsoft Internet Explorer," "Microsoft Java Virtual Machine," "Windows Media Player" and. "Windows Messenger" are not currently distributed under either ® or TM nor are they registered with the United States Patent and Trademark Office. 44 Thus, in stark contrast to its purported effect, Section VI.T either currently excludes or provides a roadmap to exclude each of Microsoft's major Middleware Products from the disclosure requirements of III.D.

When the "Trademarked" provision is taken in conjunction with the additional requirement that the Middleware must be "distributed separately from a Windows Operating System Product to update that Windows Operating System Product," it is apparent that Microsoft can completely escape coverage under Definition VI.J by either altering its distribution or the nomenclature of its products. In sum, the set of "Microsoft Middleware" that interoperates with "Windows Operating System Products" appears to be a null set.

The final definition implicated by Provision III.D is that of "Application Programming Interfaces." "APIs" are defined in Definition VI.A as follows:

PFJ, 66 Fed. Reg. at 59458. (emphasis added). Thus, "interfaces" means "interfaces" because the basic API definition rests once on the Microsoft Middleware definition (described above) and three times on the definition of Windows Operating System Product, which is defined by Microsoft in its "sole discretion." The Department has proclaimed the API disclosure remedies to be the centerpiece of the PFJ. That the definition of "API" will be exclusively determined by Microsoft highlights the seriously flawed nature of the entire proposed device.

In sum, we do not believe it is possible for the Department of Justice, Microsoft or any party to know with any degree of certainty exactly what must be disclosed under Provision III.D. But there is no question that these definitional issues will be before the Court in numerous enforcement actions and dominate this Court's docket for the next five years.

Focusing on the terms of Provision III.D that are not defined yields some striking conclusions. First, the critical term "interoperate" is left undefined by the PFJ. Moreover, despite the Department's claim in the CIS that the decree's API provisions require the release of all "interfaces and related technical information," 45 these terms are neither defined nor employed in the language of Section III.D. In fact, the phrase "technical information" does not even appear in the proposed decree. In contrast, the Interim Order included a detailed definition of "Technical Information" (Section 7.dd) that the Department and Microsoft have without explanation eliminated from the proposed decree. 46 Inexplicably the PFJ has lowered the standard of interoperability supported by disclosed APIs in the Interim Order from information that software developers "require" to "interoperate effectively" with Windows to information "used by Microsoft" to "interoperate."

These terms are not peripheral. They go to the core meaning of the API disclosure provisions of the proposed decree. An injunction designed to require Microsoft to disclose interoperability information to rivals cannot possibly be effective where the scope of the information to be released is not defined with specificity. The elimination of the definition of Technical Information is thus particularly revealing, because it illustrates that the Department has crafted a remedy that is, at best, a subset of the Interim Order on which the Department claims it relied. It also demonstrates that the Department affirmatively made a determination not to define a term which was clearly central to the disclosures mandated by the Interim Order.

Finally, Section III.D does not ensure simultaneous API access for Microsoft and its competitors. While the Interim Order required disclosure of APIs at the same time they were made available to Microsoft applications developers, the PFJ does not. Instead, the proposed decree uses the very ambiguous standard that, for a "new major version" of Microsoft middleware, API disclosure "shall occur no later than the last major beta test release." PFJ, 66 Fed. Reg. at 59454. Yet "last major beta test release" is not defined, and the provision in any case begs the question of how to decide which beta release is the "last."

No less problematic are the requirements for timely disclosure of APIs exposed by new versions of Windows. Here, the proposed decree provides in Section III.D that for "a new version of a Windows Operating System Product," disclosure "shall occur in a Timely Manner." Here the definition of "Timely Manner" provides little, if any, protection for ISVs. Definition VI.R provides that Timely Manner is "the time Microsoft first releases a beta test version of a Windows Operating System Product that is distributed to 150,000 or more beta testers." We do not believe that Microsoft has ever had 150,000 "beta testers" as opposed to 150,000 "beta copies" of its new product. Regardless, all Microsoft has to do is limit distribution to 149,000 beta testers in order to frustrate the timeliness of the required disclosures.

The proposed decree also contains several broad exemptions from and preconditions to API disclosure by Microsoft. These provisions undermine whatever strength, if any, remains in Section III.D in light of the scope and definitional failings addressed above.

Section III.J of the PFJ exempts Microsoft from disclosing "portion of APIs or Documentation" related interface information "which would compromise the. security" of a "particular installation or group of installations" of any "anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems." 66 Fed. Reg. at 59455. These exceptions to API disclosure are extremely broad.

First, the scope of this provision implicates nearly all of Microsoft's Middleware products. For example, digital rights management is encompassed in all multimedia applications (e.g., Windows Media Player). Authentication is a function embedded in Windows software (e.g., Outlook Express and Microsoft Passport) and is required for access to Windows server operating systems. Encryption likewise is a technology that is used by Internet browsers (e.g., Internet Explorer) for e-commerce and by instant messaging middleware (e.g., Windows Messenger).

Second, because the Department acknowledges that this provision permits Microsoft to withhold from disclosure certain APIs, CIS, 66 Fed. Reg. at 59472, it must also acknowledge that this provision both narrows an already limited scope of disclosures and ensures that an alternative middleware product will never be fully interoperable in the same way as Microsoft's middleware.47

Third, the CIS either misstates the implications of the provision or the Department does not understand what was agreed to in the PFJ. For example, there is no such thing as an API that is relevant to a "particular installation [PC] or group of installations [network of PCs]." APIs are standard across all Windows installations. Moreover, the provision does not refer to "keys and tokens particular to a given installation" as stated in the CIS, 66 Fed. Reg. at 59472, but rather states that Microsoft may withhold "APIs ... the disclosure of which would compromise the security of a particular installation or group of installations ... including without limitation, keys, authorization tokens or enforcement criteria." PFJ, 66 Fed. Reg. at 59455. Therefore, the way the provision appears in the PFJ as opposed to the CIS, is that it is not limited to the user-specific security duties protecting specific computer networks that no one argument should be disclosed publicly.

Section III.J.2 also imposes onerous preconditions on ISVs for the receipt from Microsoft of APIs "related to" encryption, authentication and other security matters. In order to receive relevant APIs that relate to security technologies, competitors must meet a subjective standard of "reasonableness" which the decree appears to consign to Microsoft's discretion. Thus, an ISV is only entitled to the APIs if the competitor (1) "has a reasonable business need" for the information "for a planned or shipping product," (2) satisfies "reasonable, objective standards established by Microsoft" for "certifying the authenticity and viability of its business," and (3) submits its software for Microsoft testing to "ensure verification and compliance with Microsoft specifications for use of the API or interface."

None of these limitations seems appropriate, because they unduly rely on Microsoft to determine "reasonable business" need. As one example, Microsoft clearly views "open source" software, or a threat, but will no doubt continue to claim that it is not a "viable business".

The API section must also be read in conjunction with Section III.I of the proposed decree. This portion of the proposed decree contains a provision (Section III.5) that grants Microsoft the right to require ISVs and other API recipients to cross-license their own intellectual property back to Microsoft if it relates "to the exercise of their options or alternatives provided by this Final Judgment." PFJ, 66 Fed. Reg. at 59455. Under this approach, Microsoft can, at is own discretion, require that the products developed with APIs and related interface information -- for instance, a competing middleware program -- be licensed back to Microsoft, because they "relate[] to the exercise" of an ISV's "options or alternatives" under the proposed decree. That is not a new issue in the industry. For years Microsoft has attempted to extract cross-licensing requirements and most in the industry have successfully resisted. If this provision is exercised, Provision III.D will simply not be utilized if the result is a requirement that intellectual property resulting from competitors' own investments in software research and development. Again, the CIS purports to limit the plain meaning of Section III.I by opining that the intellectual property cross-licenses are only available if Microsoft "is required to disclose interfaces that might be used by others to support a similar feature in the same fashion." CIS, 66 Fed. Reg. at 59472. But that does not appear to be consistent with the language of the PFJ.

Finally, under Section III.D, the requirement for Microsoft to release APIs and Documentation to competitors does not commence for one year. This delay means that Microsoft's own middleware will continue to be preferred in terms of its interoperability with the Windows operating system. The one-year period in which competitors must wait for API releases is one-fifth of the decree's five-year term. Nothing in the CIS discusses or explains a rationale for this substantial delay.

The Competitive Impact Statement claims that the server provisions in Section III.E of the proposed decree will "prevent Microsoft from incorporating into its Windows Operating System Products features or functionality with which its own server software can intemperate, and then refusing to make available information about those features that non-Microsoft servers need in order to have the same opportunities to interoperate with the Windows Operating System Product."48 Like the decree's API disclosure provisions, this obligation is ephemeral.

First, Section III.E is designed only to support interoperability between Windows PCs and non-Windows servers. See CIS, 66 Fed. Reg. at 59469 (interoperability between "Windows Operating System Products and non-Microsoft servers on a network"). It expressly does not cover interoperability between Windows servers and non-Windows PCs. Thus, Apple, Linux and all other desktop operating systems competitors have no right under the proposed decree to obtain any of the technical information needed to allow PCs running such competing operating systems to intemperate with Windows servers.

Second, as with the API disclosure requirements, Microsoft can easily avoid Communications Protocol disclosure through product design. For example, Microsoft can implement protocols in other software on the desktop, such as Office, or from software it downloads over the Internet from its servers to its Windows Operating Systems Product rather than implementing those protocols directly in the Windows Operating Systems Product.49 Indeed, we understand that with Microsoft's new .Net offering, Microsoft plans to download code from the Internet to effect communications between clients and Microsoft's .Net servers. This will require no disclosure under Section III.E.

Third, the definition of "Communications Protocols" itself is extraordinarily ambiguous. The decree defines Communications Protocol in Section VI.B as:

PFJ, 66 Fed. Reg. 59458. This definition does not prescribe what "predefined tasks" are encompassed, and the phrase "format, semantics, sequencing, and error control of messages" can just as easily be read to apply only to the physical means of sending information to or from a server (the rules for transmitting information packets over a network) rather then the content of such information (the rules for structuring and interpreting information within such packets). Thus, Microsoft competitors wilt be able to learn how to construct messages that can be passed to or from Microsoft severs, but will not learn the substance of the information necessary to invoke the features and functionalities of the server.

Fourth, like the PFJ's API disclosure provisions, the key terms of Section III.E are undefined. We have addressed Windows Operating System Product, which allows Microsoft itself to define the term, above. The corresponding prong of Section III.E is that Communications Protocols are disclosable when used by a Windows Operating System Product to interoperate with "a Microsoft server operating system product." The CIS claims that

CIS, 66 Fed. Reg. at 59468-69. Amazingly, this term is nowhere defined in the PFJ, despite the fact that this language is what bounds the scope of Microsoft's obligation to disclose crucial information to rivals. Based on the plain language of the PFJ alone, there is no reason to believe that, for example, Internet Information Server is covered by the undefined PFJ term "server operating system product." Although the Department attempts to clarify this definition in the CIS, as noted above there is no reason to expect Microsoft to accept the Department's CIF definition.

Fifth, a large share of PC interactions with servers occur via the Interact browser. (For instance, all Web browsing, e-commerce and other Web functionalities are a result of the browser interoperating with a server.) Section III.E does not cover protocols that are implemented in Internet Explorer to support interoperability with Microsoft's server operating systems products. Therefore, Microsoft can easily evade the scope of this provision -- whatever that may be -- by incorporating proprietary interfaces and protocols into IE rather than Windows.

Sixth, the obligations of Section III.E appear to only apply to Communications Protocols that are "implemented ... on or after the date this Final Judgment is submitted to the Court." Read literally, all of the Communications Protocols built into Windows 2000 and Windows XP are exempt from disclosure because they were implemented before the proposed decree was submitted.

Finally, Section III.J constrains the Communications Protocol provisions of Section III.E in the same way it limits the API disclosure provisions of Section III.D. Thus, any Communications Protocols that "would compromise the security" of authentication, encryption or related technologies are exempt from disclosure. Because the heart of sever-based network interoperability is authentication and encryption, these exemptions once again swallow the rule.

For all these reasons, the decree's provisions for server interface information disclosure do not provide Microsoft competitors with the interface or protocol information necessary to enable interoperability between Windows PCs and non-Windows servers. Section III.E does not even cover interoperability between non-Windows PCs and Windows servers. The central terms establishing the scope of Microsoft's obligations are undefined and subject to Microsoft's unilateral control. In short, the PFJ has created another Venn Diagram with no intersecting circles, because the Communications Protocol provisions of the decree require nothing at all.

The Department explains that the personal computer manufacturer ("OEM") provisions of the proposed decree support "the ability for computer manufacturers and consumers to customize, without interference or reversal, their personal computers as to the middleware they install, use and feature." CIS, 66 Fed. Reg. at 59460, 59471. In reality, these measures hardly change anything in existing Microsoft-OEM relations, and do not appreciably alter the dynamics of the OEM distribution channel. Most important, Sections III.C and III.H cannot, by their very design, provide an opportunity for rival middleware products - as compared to Microsoft's middleware - to attract sufficient distribution to have any impact at all on the applications barrier to entry.

The OEM sections may actually make matters worse for middleware rivals. The PFJ limits what OEMs can remove from their PC products to just the middleware icons, euphemistically referred to as "access to" middleware in Sections III.C and III.H. In other words, OEMs are not permitted to remove the code for Microsoft Internet Explorer, Windows Media Player or any other Microsoft middleware, and the proposed decree allows Microsoft to commingle and integrate middleware with its Windows operating system software. The fact that the flexibility guaranteed to OEMs is limited to removing icons, and not the middleware itself, has major competitive significance and actually guarantees perpetuation of the applications barrier protecting Microsoft's operating systems monopoly.

To achieve its goal of "recreating the potential for the emergence" of middleware alternatives to Microsoft's monopoly operating system, the PFJ delegates the role of competitive gatekeepers to OEMs. Instead of requiting the monopolist itself to unfetter the market for entry by competitors, here the PFJ imposes that obligation on third-parties who are partners with, not competitors of, the defendant. If PC manufacturers do not act on the desktop flexibility powers provided by Sections III.C or III.H of the PFJ, there will, by definition, be no OEM-based remedy. Walter Mossberg, Personal Technology columnist for the Wall Street Journal, captured the problem elegantly. "Much" of the DOJ settlement, he explained, "pertains to the company's relations with the hapless makers of PCs, which aren't in any position to defy Microsoft."50

OEMs are captives of Microsoft for a number of reasons, beginning with the obvious fact that there are no commercially viable alternatives to the Windows operating system; there are no real alternatives to Microsoft's Office suite of personal productivity applications (Word Processing, Spreadsheets, E-Mail, etc.); and there is de minimis competition for Interact browsers. The fact that OEMs find themselves in a sole source relationship with the defendant provides Microsoft with innumerable avenues to exercise its leverage over the OEM channel. These complex relationships are built more on the subtleties of a sole source relationship than on written contracts, or overt retaliation, and thus are hardly resolved by the uniform Windows pricing obligation provided for in Section III.B.

It must also be understood that personal computer manufacturers are in the business of producing low margin commodity equipment, a business characterized by very minimal (and shrinking) R&D budgets. It is unrealistic to expect any Windows-centric OEM to develop, test, and pre-install packages of rival middleware, because that would require substantial expenditures in technical software expertise and customer support which would further narrow already shrinking profit margins in a business where competitors are currently engaged in a major price war to gain market share.

The financial burden of customer support, where a single end user service call can eliminate an OEM's profit margin on a PC, creates powerful disincentives to the inclusion of non-Microsoft middleware. See Microsoft III, 253 F.3d at 62. Judge Jackson found and the Court of Appeals affirmed that in light of their customer support obligations, which are "extremely expensive," Microsoft III, 253 F.3d at 61 (citing Findings of Fact ¶ 210), OEMs are disinclined to install multiple versions of middleware. Since OEMs "have a strong incentive to minimize costs," id., the customer confusion resulting from duplicative middleware is sufficient to preclude OEMs from installing competitive programs where comparable Microsoft middleware is included with Windows.

Under the proposed decree, however, these are precisely the circumstances faced by OEMs. There are no restrictions in the PFJ on Microsoft's ability to integrate middleware technologies into Windows; in fact Microsoft is allowed to do so at its "sole discretion." Even if an OEM wants to install a competitive non-Microsoft middleware program, it will be required to deal with the fact that the corresponding Microsoft middleware product is already present on its PCs, which it is not permitted to remove. Consequently, just as OEMs' cost minimization requirements forced them not to pre-install Netscape where IE was included with Windows, so too will these same profit pressures force OEMs to decline to install competing middleware programs under the PFJ.

This is in stark contrast to the provision of the Interim Order on which the Department claims to have based its settlement. Both the Interim Order and the remedy proposed by the Litigating States would require Microsoft to ship a version of the operating system without any middleware included, if requested by an OEM. That scheme makes it possible for an OEM to truly offer a differentiated product suite without the burden of having Microsoft's corresponding technology present on the system as well.

Even if they had an independent economic incentive to support middleware competition, however, Windows OEMs are still held captive under the proposed decree's retaliation provisions. Section III.A prohibits "retaliation" (another undefined term) by Microsoft against OEMs for developing, distributing or supporting competitive middleware or exercising their desktop icon flexibility rights.

Despite their relative length, the retaliation provisions do not at all effectively preclude retaliation. Retaliation is only prohibited under Section III.A where "it is known to Microsoft" that an OEM is undertaking a permitted, competitive action. This subjective, actual knowledge standard will be difficult if not impossible to enforce. In addition:

Section III.A also limits the prohibited forms of retaliation to "altering Microsoft's commercial relations with that OEM, or by withholding newly introduced forms of non-monetary Consideration (including but not limited to new versions of existing forms of non-monetary Consideration)." PFJ, 66 Fed. Reg. 59453. Microsoft is not precluded from denying new monetary consideration to OEMs as a means of retaliation, as that is neither an "alter[ed] commercial relation" nor a "newly introduced form of non-Monetary Consideration." Similarly, Microsoft can also reward compliant OEMs by providing concessions on license fees for non-Windows Microsoft software, including applications such as Office, server operating system software and server applications, as well as Microsoft Middleware Products. None of these types of software is covered by the pricing parity requirements of Section III.B, which apply only to "'Microsoft Operating System Products." Id.

Finally, as a general matter there is no practical way to identify and prohibit all the subtle ways Microsoft can preferentially favor some OEMs, and harm others, depending on their degree of support for Windows. For instance, the definition of Consideration in Section VI.C covets "product information" and "information about future plans." Id. at 59458. Yet Microsoft could retaliate against OEMs by denying them sufficient technical information regarding important, upcoming Windows features, for example by not inviting them to internal development conferences or presentations. Likewise, Microsoft could assign fewer or less knowledgeable technical support personnel to a specific OEM's account team, a form of retaliatory discrimination that would be difficult to detect and virtually impossible to prove.

In sum, the anti-retaliation provisions offer little shelter for OEMs desiring to respond to legitimate demands by their customers for choice among competing software products. If there is any doubt about this analysis of Sections III.C and III.H above, the Court should took no further than the OEMs' treatment of Microsoft Internet Explorer. On July 11, 2001 Microsoft announced that OEMs would be free to remove access to Internet Explorer, which they had previously been prohibited from doing.51 Since this announcement was made more than six months ago, not one OEM has actually taken advantage of this provision and removed the icon for Internet Explore from retail PCs This real-world market test is an accurate gauge of how many OEMs will likely take advantage of the exact same flexibility provided in Section III.H of the decree, albeit for a somewhat wider range of middleware products: none.

The core of the case against Microsoft rests on the theory that Netscape and Java provided an alternative development platform (middleware) for applications developers, which, if applications developers began writing applications to the middleware, would undermine the applications barrier to entry and thus Microsoft's Windows monopoly. For this to occur, developers need to view rival middleware as a more attractive development platform than Windows. Unfortunately, the PFJ provides a solution to the wrong problem and actually ensures that rival middleware applications will never be able to attract a critical mass of developers.

Sections III.C and III.H of the decree allow OEMs to install competing middleware and to "enable or remove access to" Microsoft Middleware Products from the desktop of Windows PCs that they sell to end users. However, as noted, these provisions do not authorize OEMs to delete the Microsoft middleware itself, and Microsoft is not prohibited from retaliating against OEMs that attempt to delete Microsoft middleware code from its configured PCs.

This distinction between icons and code is competitively decisive. The applications barrier exists because developers write to Windows-centric APIs. Under the terms of the decree, however, the APIs exposed by Microsoft middleware remain on every Windows PC even if OEMs and end-users exercise all of the flexibility provided by Section III.H. It is crucial to understand that an application developer can write to Microsoft middleware regardless of whether "access" to that software is removed. In other words, Microsoft's middleware APIs remain ubiquitously available on all Windows PCs under the proposed decree. The best a rival middleware provider can hope for is to be "carried" alongside Microsoft's middleware on some lesser portion of personal computers.

A critical lesson learned in this case is that, as with Netscape and Java, ubiquity trumps technology in network effects markets. Professor Arrow explains that no middleware competitor can expect any economically significant chance to compete on the merits if, as permitted under the decree, Microsoft middleware is ubiquitous. Arrow Decl. ¶ 26. The important distinction between icons and code was explained by the D.C. Court of Appeals in 1998. The court emphasized that removal of end user access "do[es] not remove the IE software code, which indeed continues to play a role in providing non-browser functionality for Windows. In fact, browser functionality itself persists, and can be summoned up by ... running any application (such as Quicken) that contains the code necessary to invoke the functionality." Microsoft II, 147 F.3d at 941.

Consequently, by limiting its effect to the removal of icons only, the proposed decree cannot achieve any appreciable effect in eroding the applications barrier. They cannot "recreate the potential for the emergence" of middleware alternatives in a way that provides an economically realistic opportunity for operating systems competition.

We explained above why it is unlikely that OEMs will expend resources to promote rival middleware products. The alternative model is that rival middleware providers would pay an OEM to feature its software and delete end-user access to Microsoft's middleware. This is consistent with the CIS, which explains that the function of the OEM provisions is to allow OEMs to "feature and promote" non-Microsoft middleware. CIS, 66 Fed. Reg. at 59460.

Section III.H does not achieve this goal, for two primary reasons. First, as detailed above, the "value" of the PC desktop is diminished by the fact that an OEM is not permitted to remove the Microsoft middleware code, and thus cannot offer a rival exclusivity.

Second, Section III.H.3 does not guarantee that a rival's middleware icon will even remain on the desktop. As the Department explains the theory of this remedy, it is to create a "marketplace" on the desktop where OEMs can "stand in the shoes" of consumers and exercise choices in which middleware technologies to feature based on price and performance. Yet, the PFJ permits Microsoft to "sweep" competing middleware icons placed on the Windows desktop by OEMs. That is, Windows may automatically remove the icons featured by an OEM just fourteen days "after the initial boot-up of a new Personal Computer." True, this section contains a proviso stating that Microsoft may not do so absent end user "confirmation," but neither the text of this provision nor the Competitive Impact Statement require that confirmation be based on any objective notice or alert by Microsoft. CIS, 66 Fed. Reg. at 59471.

The fourteen-day desktop sweep proviso directly contradicts the objective of fostering OEM flexibility to feature and promote non-Microsoft middleware, because it undermines the ability of OEMs to sell desktop placement an ISV can count on. Under Section III.H.5, the best an OEMs can offer is a guarantee of desktop placement for fourteen days.

This is critically important for the reasons stated above. As rival middleware vendors attempt to attract developers to write applications to their platforms, as opposed to Microsoft's platform, they will have to make representations as to how many PC desktops actually have the rival middleware installed and available to consumers. With the fourteen day "sweep" provision included in the PFJ, ISVs will simply not be able to make any accurate projections, which will further reduce the price they might be willing to pay for desktop placement.

In order to displace Microsoft middleware and encourage applications developers to write to their APIs, competing ISVs will need to differentiate their middleware products from Windows Media Player, Windows Messenger and the other Microsoft middleware products that are bundled with Windows. The OEM provisions affirmatively undermine the ability of ISVs to achieve any meaningful degree of product differentiation.

First, Section III.C.3 permits OEMs to launch automatically non-Microsoft middleware only at boot-up or upon making a connection to the Interact. This constrains the ability of manufacturers to configure competing middleware products and reduces the value of this flexibility for (and hence potential OEM revenues from) ISVs.

Second, auto-launch of competing middleware is permissible under Section III.C.3 only (a) "if a Microsoft Middleware Product that provides similar functionality would otherwise be launched automatically at that time," PFJ, 66 Fed. Reg. 59454, and (b) if the non-Microsoft Middleware "displays on the desktop no user interface or a user interface of similar size and shape to the user interface displayed by the corresponding Microsoft middleware product." d. These limitations allow Microsoft to gate middleware competition by reducing the role of non-Microsoft middleware to only those instances in which Microsoft's own products are launched. If Microsoft decides that its middleware products will not have a user interface, or will utilize a window of a specific size, those decisions are binding on competitors' product designs as well. Indeed, the PFJ surprisingly appears not even to contemplate a situation where Microsoft's competitors develop a middleware product for which there is no "corresponding" Microsoft middleware.

Third, the PFJ empowers Microsoft to limit the freedom of ISVs in their product design and functionality decisions on its competitors. Microsoft can also limit the placement of icons and shortcuts may appear on the desktop and elsewhere, id. at 59454, 59455, the "functionality" of middleware products whose icons and shortcuts may be included by the OEM, and the ability of end users to designate non-Microsoft middleware as default middleware on their computers. Id. at 59455.

Each of these provisions has a similar, substantial effect. By allowing middleware to be substituted by an OEM only when (a) it performs similarly to Microsoft middleware, (b) exhibits functionality defined by Microsoft, or (c) includes the same user interface as Microsoft middleware, the PFJ allows Microsoft to "gate" competition. There is no competitive justification for these provisos, all of which serve to eliminate opportunities for product differentiation and permit Microsoft to constrain middleware competition to the scope, location and even "look and feel" it determines for its own products.

Section III.H of the proposed decree allows Microsoft twelve months to modify Windows XP in order to permit OEMs to remove Microsoft middleware icons or change default settings for invoking middleware functionalities. Yet the modification necessary to allow removal of icons via the "Add/Remove Programs" utility is a trivial exercise. Demonstrable proof of this fact is that Microsoft was able to modify the beta version of Windows XP to permit removal of the Interact Explorer icon within weeks of its July 11, 2001 announcement. We can not fathom why Microsoft is now given twelve months to accomplish the same task.

Section VI.N of the decree also provides that a "Non-Microsoft Middleware Product" is software with certain functionalities "of which at least one million copies were distributed in the United States within the previous year." Because the Section III.H obligations requiring modification of Windows XP to permit addition and removal of competing middleware apply to "Non-Microsoft Middleware Products," OEMs are foreclosed from the ability to feature and promote small middleware start-up competitors in Windows XP, Section VLN is a very veal impediment to achievement of the innovative middleware market the PFJ is purportedly designed to promote.

Sections III.C and III.H also do not apply to Microsoft's Java Virtual Machine ("JVM"), or Microsoft's equivalent of the JVM, its Common Language Runtime. Despite the fact that the "Microsoft Middleware Product" definition includes the Microsoft Java Virtual Machine, it appears there is no competitive consequence to its inclusion in this definition in any of the provisions of the decree. First, Microsoft no longer ships its JVM with Windows, so there is nothing for OEMs to remove. Second, even if they did continue to ship a JVM, there is no "icon" or "end-user access" to Java. Rather, Java is invoked automatically by programs that rely on its presence.

Users today enjoy the flexibility - without the benefit of the PFJ - to add, delete or customize their own PC desktops. Users may delete icons by simply "dragging" the icon to the "recycle bin" or "right-clicking" on the icon and simply choosing "delete."

Thus, the decree's OEM provisions allowing OEM removal of icons only codify Microsoft's current business practices. In response to the Court of Appeals' opinion, Microsoft on July 11, 2001 announced that "it is offering computer manufacturers greater flexibility in configuring desktop versions of the Windows operating system in light of the recent ruling by the U.S. Court of Appeals for the District of Columbia."52 According to the Microsoft press release, under this policy OEMs can "remove the Start menu entries and icons that provide end users with access to the Interact Explorer components of the operating system," and "Microsoft will include Internet Explorer in the Add/Remove programs feature in Windows XP." Id. Thus, Microsoft stressed that "Microsoft has always made it easy for consumers to delete the icons for Interact Explorer, but will now offer consumers this additional option in Windows XP." Id.

This announcement is revealing because it confirms, from Microsoft itself, that the "flexibility" provided to end users by Section III.H of the decree has always existed. And by revising Windows XP to permit OEMs to remove the Interact Explorer icon, Microsoft has already done precisely what the decree requires. Thus, the OEM provisions of the decree succeed mostly in codifying Microsoft's current business practices and achieve minimal, if any, remedial purpose.

In sum, the relief provided by Sections III.C and III.H is fundamentally at odds with the theory of the case. These OEM "desktop" remedies will not provide any opportunity for alternative middleware platforms to attract developers and thus to challenge the applications barrier to entry. They are economically irrational since Microsoft's middleware will continue to be ubiquitously available on all PCs, regardless of the choices exercised by OEMs. These provisions allow Microsoft to dictate product design features to its rivals, to limit product differentiation and to restrict OEM deals with rivals to a brief, fourteen-day exclusivity period. And at bottom, they cannot change the economic structure of the PC distribution channel because OEMs are sole-source partners of Microsoft, not competitors.

Although the proposed decree purports to ban exclusive dealing by Microsoft with respect to Windows software, Section III.G expressly permits Microsoft to establish favored or exclusive relations with certain OEMs, ISVs, etc., if the parties enter into "any bona fide joint venture or ... any joint development or joint services arrangement." This exception all but vitiates the supposed prohibition, for it allows Microsoft to enter into the identical distribution agreements that were held unlawful at trial merely by denoting them as "joint" activities.

The Department recognizes explicitly that relief in this case must "`ensure that there remain no practices likely to result in monopolization in the future.'" Microsoft III, 253 F.3d at 103 (citations omitted); see CIS, 66 Fed. Reg. at 59465 (monopolization remedy should "avoid a recurrence of the violation" in the future). Yet by failing to address significant market and technological developments that have occurred in the period since the trial record closed, the narrow remedies of the proposed decree do not provide relief that comes even close to ensuring that Microsoft's unlawful practices will not be repeated in the future.

Since the trial, Microsoft has solidified three new chokeholds with which it can easily perpetuate its monopoly power:

 
Updated January 9, 2023