Comments Of Computer & Communications Industry Association On The Revised Proposed Final Judgment

TABLE OF CONTENTS

INTRODUCTION

CONCLUSION

1.  

    

    

    

   1. Liability Rests On Microsoft's Suppression Of Middleware Threats That Threatened To Erode The Applications Barrier To Entry
   2. The RPFJ Does Not Prevent Microsoft From Abusing Its Position And Does Not Meet Basic Standards For An Antitrust Remedy
   3. The Obligations That Supposedly Restore Competitive Conditions In Fact Make Microsoft Do Virtually Nothing Against Its Will
   4. The Public Interest Requires An Effective Remedy That The RPFJ Does Not Provide
2. The Tunney Act Requires Close Scrutiny Under The Present Circumstances

    

    

   1. The Government's Victory On Liability Removes Litigation Risk And Therefore Limits Deference

       

       

      1. The Imposition And Affirmance Of Liability Remove Any Constitutional Concerns About Searching Review And Require The Court To Perform Its Constitutional Duty
      2. The Extensive Record And Judicial Opinions Provide Clear, Manageable Standards For Substantive Review Of The RPFJ
   2. Broad Deference Is Particularly Inappropriate Because The Circumstances Are Suspicious

       

       

       

       

      1. Microsoft's Manifestly Inadequate Disclosure Under The Tunney Act's Sunshine Provisions Weighs Strongly Against Judicial Deference To The Terms Of The RPFJ
      2. The RPFJ Represents A Swift And Significant Retreat By DOJ
      3. The CIS Overstates The Terms Of The RPFJ, Reflecting The Indefensibility of the RPFJ Itself
3. The RPFJ must meet the legal standards normally applicable to antitrust remedies

    

    

    

    

    

    

   1. The Relief Should "Terminate The Illegal Monopoly"
   2. The Relief Should Prevent "Practices Likely To Result In Monopolization In The Future"
   3. The Relief Should "Deny To The Defendant The Fruits Of Its Statutory Violation"
   4. Broader Principles Applicable To Injunctive Relief Also Should Inform The Analysis Of The RPFJ
4. The RPFJ falls far short of providing a remedy for proven offenses upheld on appeal

    

    

    

    

   1. DOJ's Effort To Minimize The Scope Of The D.C. Circuit's Affirmance Cannot Obscure The Failure Of The RPFJ To Remediate Clear, Proven Violations
   2. The RPFJ Simply Restates The Antitrust Laws At Critical Points And Thus Forfeits The Clarity And Efficiency Of The Contempt Process
   3. The RPFJ Provides No Remedy For Microsoft's Suppression Of The Browser And Java
5. The Icon-focused OEM flexibility Provisions Are Ineffective

    

    

    

    

    

    

    

    

    

    

   1. The PFJ Permits Microsoft's To Continue Illegally Commingling Middleware Code With The Code For The Monopoly Operating System

       

       

       

       

       

       

      1. The DC Circuit Specifically Condemned Commingling Twice
      2. The Failure To Limit Commingling Is Critical Because Ubiquity Trumps Technology In Platform Software Markets
      3. The RPFJ Retreats From The 1995 Consent Decree
      4. The RPFJ Encourages Illegal Commingling By Placing The Critical Definition of Windows Under Microsoft's Exclusive Control
   2. Empirical Evidence Shows That The Icon Flexibility Provisions Will Not Be Used
   3. The Icon Flexibility Provisions Require -- And Accomplish -- Little
   4. The 14-Day Sweep Provision Effectively Nullifies RPFJ § III(H)
   5. By Placing The Burden To Restore Competition On OEMs, The PFJ Leads To No Remedy At All For Much Of The Misconduct At Issue
   6. The RPFJ Permits Microsoft To Control Consumers' Access To Innovation To Suit Its Monopolistic Aims
6. The API and Communications protocol Disclosure Provisions Are ineffective

    

    

    

    

    

    

    

    

    

    

    

    

   1. The API Provisions Require Little, If Anything, Beyond Current Disclosure Practices In Microsoft's Self-Interest
   2. The RPFJ Does Not Require Disclosure of Windows APIs, But Rather Lets Microsoft Determine The Scope of Disclosure Through The Design and Labeling of Its Operating System And Middleware
   3. The Definition of "Microsoft Middleware" Gives Microsoft Further Leeway to Limit Its Disclosure Obligation

       

       

       

       

      1. The RPFJ Requires Microsoft To Disclose Only The APIs Used By The "User Interface" Or Shell Of Microsoft Middleware
      2. The RPFJ Requires Microsoft To Disclose APIs Only For "Microsoft Middleware" That Is Distributed Separately From Windows, Yet Is Distributed To Update Windows
      3. The Limitation Of Microsoft Middleware To "Trademarked" Products Further Eviscerates The API Disclosure Provision
   4. The Disclosure Provisions -- Particularly Those Concerning "Communications Protocols" -- Depend On An Undefined And Thus Unenforceable Concept of "Interoperability"
   5. The Narrow Scope Of The Disclosure Provisions Contrasts Sharply With The Broader Definitions In DOJ's Earlier Remedy Proposals
   6. The "Security" Exceptions in Section III(J) Permit Microsoft To Avoid Its Disclosure Obligations

       

       

      1. The Exclusions for Security-Related APIs and Protocols in RPFJ(J)(1) Permit Microsoft To Hobble Disclosures That Are Critical in Internet Computing
      2. RPFJ III(J)(2) Permits Microsoft To Refuse Effective Disclosure To A Range Of Potentially Effective Competitors
   7. RPFJ § III(I) Would Place A Judicial Imprimatur On Microsoft's Use Of Technical Information As A Lever To Extract Competitors' Intellectual Property
7. built-in delays exacerbate the decree's unjustifiably brief duration
8. Additional weaknesses undercut the RPFJ

    

    

    

    

   1. The Anti-Retaliation Provisions Are Deeply Flawed
   2. Microsoft Can Evade The Price Discrimination Restrictions
   3. Microsoft Can Enforce De Facto Exclusivity
9. THE RPFJ'S ENFORCEMENT MECHANISMS ARE FUNDAMENTALLY INADEQUATE

The Computer & Communications Industry Association ("CCIA") is an association of computer, communications, Internet and technology companies that range from small entrepreneurial firms to some of the largest members of the industry. CCIA's members include equipment manufacturers, software developers, providers of electronic commerce, networking, telecommunications and on-line services, resellers, systems integrators, and third-party vendors. Its member companies employ nearly one million persons and generate annual revenues exceeding $300 billion. CCIA's mission is to further the interests of its members, their customers, and the industry at large by serving as the leading industry advocate in promoting open, barrier-free competition in the offering of computer and communications products and services worldwide. CCIA's motto is "Open Markets, Open Systems, Open Networks, and Full, Fair and Open Competition," and its website is at www.ccianet.org.

For nearly 30 years, CCIA has supported antitrust policy that ensures competition and a level playing field in the computer and communications industries. That involvement antedates the founding of Microsoft, much less its acquisition of its first monopoly and its refinement of anticompetitive techniques. CCIA supported the Tunney Act in the 1973 congressional hearings preceding the enactment of that legislation, and played active roles on the side of competition in other significant antitrust cases, including those against AT&T and IBM. Before participating as amicus curiae at the trial and appellate stages of the current Microsoft case, CCIA participated as a leading amicus curiae in the proceedings examining the last Microsoft consent decree in 1994- 1995, both in the district court and in the court of appeals. As a consequence, CCIA and its members are intimately familiar with the shortcomings of that decree, and its failure to prevent or deter Microsoft from continuing on an anticompetitive course. Microsoft's conduct in the intervening years, including the period while this case has been litigated, has only sharpened CCIA's awareness of Microsoft's dedication to driving out competition from as many aspects of the computer-software and related industries as possible. Microsoft may repeat its attempts to mischaracterize CCIA as a mere voice for competitors, but that innuendo cannot withstand scrutingy in light of the diversity of CCIA's membership now and over the years, combined with CCIA's 30 years of vigorous commitment to supporting openness and competition in the computer technology and communications industries. In hopes that a meaningful remedy in this case will prevent Microsoft from further expanding the scope of its monopoly, and with the certainty that the current Revised Proposed Final Judgment ("RPFJ") falls far short of that task, CCIA submits this analysis of the RPFJ in conjunction with the economic analysis of Nobel laureate Joseph Stiglitz and his colleague Jason Furman, and the Declaration of Edward Roeder.

The Tunney Act was designed to constrain the Department of Justice ("DOJ") from entering into settlements that provided DOJ with an exit from an antitrust case but did not provide the public with a remedy commensurate with the defendant's antitrust violations. The Revised Proposed Final Judgment (RPFJ) in this case does not provide adequate relief for the extensive and thoroughly proven antitrust violations it purports to remedy.

Review of the RPFJ in this case should be especially searching because there can be no doubt about Microsoft's liability. For the first time in the history of the Tunney Act, the Court will review a proposed settlement reached after liability has been not only imposed, but unanimously affirmed on the government's most sweeping and economically significant theory. That clear-cut liability, and the voluminous Findings of Fact and trial record, place the Court in this case in a different position from courts reviewing pre-trial settlements.

Because there is no litigation risk on liability, the Court is uniquely situated to evaluate any asserted litigation risk as to remedy. Established principles of antitrust relief provide the Court in this case with concrete, recognized standards to ensure that the settlement serves the public interest in a way that courts reviewing pre-trial settlements cannot. Magnifying the need for close measurement of the RPFJ by objective principles is Microsoft's silence, in its filing under 15 U.S.C. § 16(g), about its effort to truncate this case by a lobbying campaign of unprecedented scope directed at the Executive and Legislative Branches alike -- despite extensive public reports of that lobbying. Microsoft's effort to deny the obvious gives rise to an inference that it has something to hide.

The terms of the RPFJ provide the strongest reason for close scrutiny, because they cannot withstand analysis. The RPFJ would not provide a meaningful remedy for Microsoft's extensive campaign of exclusionary acts. That campaign suppressed the most serious threat to Microsoft's monopoly in the past decade, and not only prevented the erosion of the applications barrier to entry that insulates the monopoly, but increased the bar to new competition. The RPFJ ignores some of the most significant holdings of the court of appeals, however, including its separate imposition of liability for Microsoft's commingling of middleware code with the code for the Windows operating system.

More fundamentally, the RPFJ misses the point of Microsoft's illegal conduct, which was to prevent erosion of the applications barrier to entry by preventing middleware from attracting software developers to the middleware application programming interfaces ("APIs"). The RPFJ's basic premises, moreover, ignore the current economic and technical realities of the computer and software markets. In the seven years since Microsoft began the illegal conduct at issue in this case, Microsoft has strengthened its operating systems monopoly. The Internet browser, formerly a threat to that monopoly, has become an adjunct to it, with Microsoft's 91% share of that product adding further insulation to the operating systems monopoly. Microsoft's unadjudicated monopoly over personal productivity applications -- a key to the applications barrier to entry in the operating systems market -- likewise has grown in market share and market power.

But the RPFJ does not try to deprive Microsoft of any of the benefits of its illegal activity directed at the browser and other middleware. DOJ's remedial theory rests entirely on unidentified future middleware threats. In fact, there are no technologies today presenting a threat as intense as that presented by the Netscape browser and Java, and the duration of the RPFJ is so short that it almost certainly will expire before any significant new threats materialize.

Aside from some restrictions on commercial retaliation that at best might keep matters from getting worse, the RPFJ relies on two sets of putative obligations to achieve a more competitive market. But neither the provisions aimed at original equipment manufacturer ("OEM") flexibility nor those addressing information disclosure requirements in fact require anything competitively meaningful. In large part, these provisions replicate Microsoft's current business practices respecting the disclosure of technical information and the configuration of end-user access to middleware products.

The OEM flexibility sections in RPFJ §§ III(C) and III(H) are literally superficial, principally addressing desktop icons rather than the middleware code itself, which contains the APIs relied on by software applications developers. Even if successful, the flexibility provisions would not affect the applications barrier to entry. Moreover, these provisions largely restate current business practices or provide OEMs with flexibility that both Microsoft and DOJ understand from experience will never be exercised. OEMs have little or no incentive to exercise their options; if they decline to do so, then the flexibility provisions will have no competitive consequences for the industry.

The RPFJ's information disclosure sections (§§ III(D) and III(E)) are so transparently insubstantial as to cast doubt on the entire proposal. The purported disclosure requirements trace back to definitions that are committed to Microsoft's control, are circular, or simply do not exist. Neither DOJ nor any other objective observer could have any idea precisely which APIs or protocols must be disclosed. The RPFJ's provisions and definitions are so vague that only two practical results are possible. Either everyone will simply ignore the decree, which plainly would not be in the public interest for an antitrust remedy, or the Court will have to take primary responsibility for defining its terms during enforcement proceedings. DOJ's answer seems to be to let Microsoft set the terms of its obligations: the RPFJ gives the defendant "sole discretion" to define the decree's most important term, "Windows Operating System Product," which appears 46 times to delimit the RPFJ's 10 substantive provisions.

Indeed, much of DOJ's Competitive Impact Statement ("CIS") seems to reflect an understanding that the RPFJ is inadequate in several critical respects. The CIS defines terms not defined in the RPFJ, exaggerates the scope of certain RPFJ provisions, and redefines other terms in order to minimize the impact of some of the broad exemptions in the RPFJ. It is the RPFJ that the Court would have to enforce, however, as the CIS is not part of the contract between DOJ and Microsoft.

In sum, although the RPFJ's provisions superficially seem to restrict Microsoft's practices, there is no substance behind them. The provisions accomplish little beyond laying down criteria for Microsoft to follow in order to avoid any interference with its continuing campaign of illegal monopolization.

The terms of the RPFJ, as much as the circumstances of the settlement, strongly suggest that Microsoft and the Department of Justice shared a desire to end this case, rather than to provide an effective remedy for Microsoft's substantial antitrust violations. The 1995 consent decree with Microsoft produced uninterrupted illegal monopolization, prompting the filing of this case in 1998. The Court can expect the same with this decree. The RPFJ, if approved, might temporarily end DOJ's involvement, but would not provide the type of remedy that the public interest and the Tunney Act demand. To the contrary, because the harm to the competitive process caused by Microsoft's adjudicated illegal conduct is certain, a remedy that masks but does not cure that harm affirmatively injures the public interest, and therefore should be rejected.

1. • Liability Rests On Microsoft's Suppression Of Middleware Threats That Threatened To Erode The Applications Barrier To Entry

This case is about Microsoft's devastatingly thorough suppression of threats to its Windows operating system ("OS") monopoly by "middleware." That monopoly was insulated from competition by the applications barrier to entry described by the court of appeals and the CIS. See United States v. Microsoft Corp., 253 F.3d 34, 55-56 (D.C. Cir. 2001) ("Microsoft III"); CIS 10-11, 66 Fed. Reg. 59,452, 59,462 (2001). See also Declaration of Joseph E. Stiglitz & Jason Furman 7-9 ("Stiglitz/Furman Dec.") (attached). The middleware at issue in this case exposed APIs that could be used by software applications developers to write programs that did not rely on the underlying Windows operating system. As Microsoft recognized, if developers embraced non- Microsoft middleware APIs and designed their products to run on that middleware rather than directly on an operating system, "middleware" of this kind "would erode the applications barrier to entry," as "applications * * * could run on any operating system on which the middleware product was present with little, if any, porting." Microsoft III, 253 F.3d at 55. The threat that "middleware could usurp the operating system's platform function," id. at 53, prompted Microsoft's anticompetitive conduct.

But non-Microsoft middleware can become a competing platform only if developers write software that calls on the non-Microsoft middleware APIs. Most developers will create software only to run on platforms that are distributed widely enough for the developers to be reasonably certain that the APIs (on which their programs rely) will be present on most, if not all PCs. Likewise, if developers can be certain that Microsoft's middleware APIs are present on all PCs, this will strongly influence their initial decision as to whether it is worth the effort to write applications to alternative, non-Microsoft middleware APIs.

The successful theory of the case -- proved and accepted by two courts -- is that Microsoft engaged in an "extensive campaign of exclusionary acts" that were designed "to maintain its monopoly" by suppressing middleware threats posed by the Netscape Navigator Internet browser and the cross-platform Java technologies. CIS 9, 66 Fed. Reg. 59,462; Microsoft III, 253 F.3d at 53-56, 60-62, 74-78. Microsoft's response to this threat guaranteed that developers would not use the APIs of competing middleware, destroying the platform threat.

Because Microsoft has a monopoly over the OS, it can ensure that its own versions of a middleware product have universal distribution, so that Microsoft's middleware APIs will be present on all PCs. For example, because Windows is both an operating system and a distribution channel for Microsoft's technologies, Microsoft could and did ensure that the code for its Internet Explorer ("IE") browser was distributed to every PC.

Ensuring that the code for Microsoft middleware was on every PC accomplished two related goals. First, it guaranteed instant and unassailable ubiquity for the Microsoft version of the middleware and the middleware APIs on which developers rely. Second, the forced ubiquity of Microsoft middleware prevents competing middleware from achieving ubiquity, or anything like it, because few distribution channels will incur the support and other costs of distributing two versions of the same functionality. A key theory of the case is that the applications barrier to entry could have been eroded only if developers chose and used alternative middleware platforms on which to write software. End-user access to middleware was significant only to the extent it influenced developers' choices to write to the APIs of that middleware.

Thus, ensuring that the code for the Microsoft version of middleware is on every PC destroys the competitive threat presented by the competing middleware's APIs, since few developers will use them in preference to Microsoft middleware APIs that are certain to be ubiquitous. This fact provides the essential context for any meaningful analysis of the information disclosure and OEM flexibility provisions of the RPFJ.

2. • The RPFJ Does Not Prevent Microsoft From Abusing Its Position

And Does Not Meet Basic Standards For An Antitrust Remedy The D.C. Circuit set out a simple standard for measuring the legal sufficiency of any remedy selected in the Microsoft litigation: the remedy must "seek to 'unfetter [the] 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.'" 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 Machinery Corp., 391 U.S. 244, 250 (1968)). As the District Court recognized in beginning remedy proceedings on remand (9/28/01 Tr. 6-7), not one word in the D.C. Circuit's opinion suggests the slightest antipathy toward any conduct remedy related to the illegal monopolization that the Court of Appeals exhaustively condemned.⁽¹⁾ The District Court warned the plaintiffs to be "cautiously attentive to the efficacy of every element of the proposed relief." 9/28/01 Tr. 8. That is, the plaintiffs must make sure that the proposed remedy works.

That admonition appears to have fallen on deaf ears. Because liability has been established and affirmed in great detail, the scope of the District Court's appropriate deference to DOJ is extremely limited because the range of permissible action by DOJ is closely confined. There is no litigation risk other than the risk that the District Court would not approve a particular remedy, or that the District Court's exercise of discretion in approving a remedy might be reversed on appeal. A remedy, even one imposed by agreement, must provide adequate relief for the violations that have been proved, however. DOJ is entitled to deference only for choices that fall within the range of adequate relief.

The RPFJ misses the point of the central theory of liability. The RPFJ does not impose certain, enforceable, or competitively significant obligations on Microsoft to restore competition or to avoid suppressing future threats. The RPFJ allows Microsoft to keep every anticompetitive gain that resulted from its illegal conduct, simply requiring Microsoft to find new and slightly different ways to accomplish its anticompetitive goals. DOJ seems to recognize that the case focused on two specific products -- Netscape Navigator and Java -- that embodied the broader threat of middleware and the Internet to the stability and significance of Microsoft's monopoly. The RPFJ does nothing to restore the specific competitive threat posed by an independent Internet browser. It does nothing to restore the threat of cross-platform Java. And it does nothing to protect any other middleware threat -- in the unlikely event that another such threat might arise within the short duration of the RPFJ -- from much similar exclusionary conduct, or indeed from the identical commingling of code that sealed Netscape's fate.

Rather, the RPFJ appears to assume that it is still 1995, and that the threat of the Internet browser can begin anew without confronting a more thoroughly entrenched Microsoft. The RPFJ does not take account of the impact on participants at different levels of the computer and software industries of an additional seven years of Microsoft's anticompetitive abuses. That view does not accord with reality, and the provisions intended to permit open competition in that counterfactual world cannot achieve their goal.

3. • The Obligations That Supposedly Restore Competitive Conditions In Fact Make Microsoft Do Virtually Nothing Against Its Will

The RPFJ purports to give current and future middleware the ability to present the same threats to the Microsoft monopoly that Netscape and Java presented before the onset of Microsoft's illegal conduct. DOJ describes the obligations in the RPFJ as if they would have stopped Microsoft's suppression of Netscape, and as if they would allow rival middleware vendors to obtain the technical information that they need to "emulate Microsoft's integrated functions" (Testimony of Charles James before Senate Judiciary Committee 7 (Dec. 12, 2001)) and to step into the shoes of Microsoft middleware in relation to Windows and the Windows monopoly. The RPFJ does not achieve those goals.

Most of the RPFJ reduces to two sets of obligations, along with some prohibitions on exclusive deals and on retaliation against those who take advantage of Microsoft's obligations. One set of obligations appears to restrain Microsoft from taking particular actions to interfere with OEMs' placement of the icons of Non-Microsoft Middleware on their machines, or with end-users' use of those products. These OEM flexibility provisions principally rely on the OEMs to provide a remedy for Microsoft's misconduct. The other set of obligations requires a certain degree of disclosure of APIs and Communications Protocols to allow competing software products can "interoperate" -- an undefined term -- with the monopoly OS.

For the most part, the obligations placed on Microsoft by the RPFJ simply replicate current options voluntarily provided by Microsoft. For example, Microsoft must continue to disclose the APIs it currently discloses in the Microsoft Developers' Network (MSDN), a program Microsoft developed to further its self-interest in making the Windows platform popular with software developers. And Microsoft must continue to allow end-users to delete icons from the desktop and start menu. Such provisions at most simply prohibit Microsoft from making matters worse than they are after Microsoft's years-long anticompetitive campaign. Indeed, the RPFJ in some instances specifically approves potential misuse of Microsoft's current voluntary implementations of the flexibility and disclosure provisions.

To begin with the flexibility provisions, their chief flaw is their focus on icons rather than on middleware functionality. This is literally a superficial approach. Microsoft can include its own middleware and middleware APIs on every PC. Developers will know those APIs are there and consequently will write to them in preference to the APIs of a competing product that may or may not be on a particular machine. No provision of the RPFJ restricts Microsoft's insertion and commingling of middleware code into the "Windows Operating System Product" bundle that Microsoft receives the right to define for decree purposes "in its sole discretion." RPFJ § VI(U). From the point of view of developers -- and thus of the ability of middleware to erode the applications barrier to entry -- these "flexibility" provisions are meaningless.

Even to the extent that competing middleware vendors might obtain favorable placement for their products' icons in preference to the icons for Microsoft products, that achievement would be both superficial and temporary. The functionality of the Microsoft product would remain on the machine, and Microsoft could insist on its invocation for a variety of functions. And, 14 days after a PC first boots up, Microsoft would be free to nag users to click a "Clean Desktop Wizard" which would organize icons in the way that suited Microsoft. There is nothing in the RPFJ to stop that "Wizard" from resetting default applications to coincide with Microsoft's preferences as well, or even from enhancing the product so that it becomes a Clean File Wizard to remove code of competing middleware with a single click.

These provisions place responsibility for restoring competition on innocent OEMs and ISVs rather than on Microsoft. And many provisions give end-users what they have now: the ability to remove an icon from the desktop or a program menu by right-clicking it and selecting "Delete," or by dragging it to the Recycle Bin. The provisions do change the status quo in one way. The "Add/Remove" function, which now removes some underlying code for applications, will only remove a few icons when the removed application is Microsoft middleware.

The disclosure provisions are no better. The RPFJ requires Microsoft to disclose APIs between "Microsoft Middleware" and a "Windows Operating System Product," but the definitions of those terms are so completely within Microsoft's control that it is impossible to tell whether Microsoft ever would have to disclose an API that might have competitive significance. As noted above, a "Windows Operating System Product" is whatever Microsoft says it is. "Microsoft Middleware" must be distributed separately from the OS (unlike, e.g., the current version of Windows Media Player). "Microsoft Middleware" must be "Trademarked" in a way that would exclude Windows Messenger, may exclude Windows Media Player, and certainly would exclude any products that followed Microsoft's practice of simply combining the Microsoft® or Windows® marks with a generic or descriptive term.

Indeed, because "Microsoft Middleware" need not mean any more than the user interface of a middleware functionality that meets the other definitional requirements, see RPFJ § VI(J)(4), the only APIs that must be disclosed are those between the middleware user interface and "Windows," which Microsoft in its discretion can define to include all of any given middleware functionality. See id. § VI(U). Microsoft need not disclose how the middleware actually invokes Windows to work, except for the way that the OS displays the middleware's shell.

The disclosure provisions applying to Communications Protocols are similarly weakened by non-existent definitions. The disclosable Protocols are those required to "interoperate" -- whatever that may mean -- with equally undefined "Microsoft server operating products." RPFJ § III(E). In addition, the Communications Protocol disclosure provisions are limited by sweeping exceptions applying to security protocols that are intertwined with all significant computer-to-computer communication. See id. § III(J)(I). Microsoft can withhold parts of those Protocols (and, indeed, parts of APIs) on the basis that disclosure would compromise security of an installation.

If this exemption were limited to the customer-specific data like encryption keys or authorization tokens, it would be necessary, not objectionable. But the exemption explicitly permits Microsoft to withhold portions of the Protocols and APIs themselves, which necessarily makes "interoperation" (as that term normally is used) incomplete. Interoperation, however, is an all-or-nothing state. Software that can use only parts of APIs and Communications Protocols simply cannot "interoperate" with the software on the other side of the API or Protocol.

But that is not all. RPFJ § III(J)(2) permits Microsoft to refuse to disclose security-related Protocols or APIs to any company that does not meet Microsoft's standards of business viability or its standards for a business need. Again, little if anything is left of this disclosure requirement if Microsoft chooses to resist disclosure when that serves its anticompetitive goals. One thing is certain. Unless Microsoft and DOJ alike render the RPFJ irrelevant by simply ignoring it, the District Court will be faced again and again with the task of interpreting the RPFJ's indistinct provisions. Microsoft has demonstrated its incentive and ability to contest even the most seemingly obvious points of any court order.

4. • The Public Interest Requires An Effective Remedy That The RPFJ Does Not Provide

Despite the belated efforts of DOJ to minimize the scope of this case, it remains the largest, most successful prosecution for monopolization liability since at least the Second World War. The D.C. Circuit affirmed "the District Court's holding that Microsoft violated § 2 of the Sherman Act in a variety of ways." 253 F.3d at 59. The breadth of that holding is clear from the 20 Federal Reporter pages consumed by the court's detailed discussion of Microsoft's array of exclusionary behavior. The competitive significance of the conduct condemned by that holding is explained both in the opinion, in the Declaration of Joseph E. Stiglitz and Jason Furman ("Stiglitz/Furman Dec.") 16-20, and in the Comment of Robert E. Litan, Roger G. Noll, and William D. Nordhaus ("Litan/Noll/Nordhaus Comment") 12-31, among other submissions for this Tunney Act proceeding. The difficulties encountered by peripheral claims are irrelevant, particularly because all of the challenged conduct supported monopolization liability in addition to one or more of the since-abandoned theories. The supposed "narrowing" left a huge monopolization case with a stark judgment affirming the government's theory. The RPFJ does not provide a remedy commensurate with that liability.

The RPFJ is insufficient for another overarching reason. The passage of time has only exacerbated the problem of Microsoft's successful abuse of its operating systems monopoly to extend that monopoly to embrace other sectors of computing and to forestall threats to the monopoly from those sectors. Microsoft's monopoly over Internet browsing is complete, as its current 91% market share indicates. Julia Angwin, et al., AOL Sues Microsoft Over Netscape in Case That Could Seek Billions, WALL ST. J., Jan. 23, 2002, at B1. Even the RPFJ recognizes, albeit through toothless provisions, that Microsoft is using its desktop OS monopoly to force greater use of its server operating systems. And Microsoft's efforts to use the inclusion of its Passport authentication software on every Windows machine as a means of directing through a Microsoft server all authentication and identification transactions -- gaining a literal chokehold over the communications aspect of Internet computing -- is so significant that Microsoft sought and obtained an exemption in the RPFJ specifically designed to excuse that known monopolistic strategy. See RPFJ § III(H)(1)[second]⁽²⁾; see also id. § III(J).

Microsoft has made ample use of the seven years since the beginning of the conduct at issue in this case. The RPFJ is wholly inadequate even on its own terms, which assume that the world has returned to 1995. But the RPFJ does not begin to address what has happened since then.

The public interest in a remedy that achieves what antitrust law says it must cannot be obscured by focusing either on the preference of the technology industry for standards, or on the never-litigated assumption that Microsoft obtained its original operating systems monopoly legally in the 1980s. The last premise, after all, still suggests that the last ten years or so of Microsoft's hegemony have resulted from the illegal acts that prompted two government antitrust lawsuits. If DOJ's enforcement history is to be credited, Microsoft has at least doubled the life of its monopoly through illegal conduct.

In addition, even if the nature of software platforms generally, or computer operating systems in particular, results in transitory single-firm dominance, that does not mean that competition has no place, or that entrenched monopoly is somehow without social costs. See Stiglitz/Furman Dec. 13-16. Innovation results in the periodic replacement or "leapfrogging" of one standard by another. This is not some meaningless replacement of one monopoly with another, as some would have it. To the contrary, as economists -- including those of the Chicago school -- have recognized, "competition * * * 'for the field'" provides consumers with substantial benefits. See Microsoft III, 253 F.3d at 49 and sources cited therein. But if competition in a market is limited in scope to serial competition for transitory dominance, predatory conduct is especially harmful. See generally Stiglitz/Furman Dec. 13-16. The monopolist may need to eliminate only a few incipient but significant threats in the course of a decade in order to transform transitory dominance into a durable, even impregnable monopoly.

That is what happened here. Although Netscape Navigator had not developed into a competing applications platform when Microsoft cut off its revenue sources, Netscape contemplated just such a development -- and Microsoft both contemplated and deeply feared it. The outcome of the competition that Microsoft thwarted is unknowable. But there will be no further competition -- much less competitive outcomes -- if Microsoft is allowed to repeat the course of conduct it undertook here.

But the RPFJ permits Microsoft to continue to fortify and expand its monopoly. Indeed, the RPFJ provides an imprimatur for Microsoft to continue and expand a whole range of additional, related anticompetitive practices. As a consequence, the RPFJ is an instrument of monopolization, not a remedy for it. The Court should not add judicial endorsement to DOJ's agreement to give up the case. The "public interest," within the meaning of the Tunney Act, 15 U.S.C. § 16(e), requires far more effective relief.

1. • THE TUNNEY ACT REQUIRES CLOSE SCRUTINY UNDER THE PRESENT CIRCUMSTANCES

The Tunney Act exists "to prevent 'judicial rubber stamping'" of proposed antitrust consent decrees. United States v. Microsoft Corp., 56 F.3d 1448, 1458 (D.C. Cir. 1995) (quoting H.R. Rep. No. 1463, 93d Cong. 2d sess. 8, reprinted in 1974 U.S.C.C.A.N. 6535, 6538) ("Microsoft I"); United States v. BNS, Inc., 858 F.2d 456, 459 (9th Cir. 1988); In re IBM, 687 F.2d 591, 600 (2d Cir. 1982). Upon enactment it was immediately clear that "Congress did not intend the court's" review of a proposed settlement "to be merely pro forma, or to be limited to what appears on the surface." United States v. Gillette Co., 406 F. Supp. 713, 715 (D. Mass. 1975) (Aldrich, J.).

The Tunney Act requires particularly close scrutiny of the RPFJ in this case. The government seeks to remedy a proven, well-defined, serious violation of the antitrust laws. Microsoft's heavy lobbying of the executive and legislative branches in order to bring political pressure for a lenient settlement heightens the need for scrutiny, and in addition makes necessary the Court's active investigation into Microsoft's failure to disclose the bulk of that lobbying despite the command of 15 U.S.C. § 16(g). The lenient terms of the RPFJ itself further underscore the need for close judicial scrutiny. Never in the history of the Tunney Act has a Court been confronted with this combination of an impregnable judgment of liability, pervasive lobbying, and apparent surrender by the federal government. The circumstances here indicate exactly the sort of "failure of the government to discharge its duty" -- whether or not actually "corrupt" -- that even DOJ concedes warrants close judicial scrutiny of a settlement. CIS 66, 66 Fed. Reg. 59,476 (quoting United States v. Mid-America Dairymen, Inc., 1997­1 Trade Cas. ¶ 61,508, at 71,980, 1977 WL 4352 at *8 (W.D. Mo. 1977)).

1. 1. • The Government's Victory On Liability Removes Litigation Risk And Therefore Limits Deference

The CIS suggests (at 65-68, 66 Fed. Reg. at 59,475-476) that the Court owes nearly absolute deference to DOJ's decision to retreat from its appellate victory. That is not true. The affirmance of liability on appeal removes any speculation that "remedies which appear less than vigorous" simply "reflect an underlying weakness in the government's case." Microsoft I, 56 F.3d at 1461. There is no "underlying weakness"; liability is a given, and provides a clear benchmark for measuring whether the proposed relief is sufficiently effective to come "within the reaches of the public interest." Id. at 1460. Those "reaches" are narrower when liability is proved and affirmed than when it is merely alleged, as it was in Microsoft I.

1. 1. 1. • The Imposition And Affirmance Of Liability Remove Any Constitutional Concerns About Searching Review And Require The Court To Perform Its Constitutional Duty

Most important, the current posture of this case places it beyond the scope of the prudential and constitutional concerns expressed by some courts (and dissenting Justices) about judicial scrutiny of DOJ's charging decisions, or of its settlement of unproven claims. It may be that when "the government is challenged for not bringing as extensive an action as it might, a district judge must be careful not to exceed his or her constitutional role." Microsoft I, 56 F.3d at 1462. Such concerns did not persuade the majority of the Supreme Court, however, which over a dissent rejected similar arguments in summarily affirming the modifications imposed by the district court in the AT&T consent decree. See Maryland v. United States, 460 U.S. 1001 (1983).

In any event, when the action has been brought, tried, and won, and the only question is whether the proposed relief is adequate, the constitutional concerns dissipate. Because DOJ already made the discretionary decision to bring the case, and successfully proved liability to the satisfaction of two courts, the Court in reviewing this settlement runs no risk that by exercising its normal remedial discretion under established legal principles it somehow might be said "to assume the role of Attorney General." Microsoft I, 56 F.3d at 1462. It was precisely the absence of a "judicial finding of illegality" that might impede the Tunney Act from "supply[ing] a judicially manageable standard for review." Id. at 1459. Here, two courts have provided the "findings that the defendant has actually engaged in illegal practices" that were missing in both Microsoft I and AT&T (like other cases settled before trial). Id. at 1460-1461 (emphasis added). In addition, the appellate affirmance imposed monopolization liability for all of the significant conduct that had been alleged to support the additional, largely supererogatory legal theories that were rejected as ground for additional liability.

It is accordingly entirely appropriate, and indeed necessary, for the Court in this case "to measure the remedies in the decree as if they were fashioned after trial," Microsoft I, 56 F.3d at 1461, because they were "fashioned after trial" and appellate affirmance. The Court need not "assume that the allegations in the complaint have been formally made out" (id.), but rather knows beyond doubt exactly which allegations were proved. There is a "judicial finding of relevant markets, closed or otherwise, to be opened" and "of anticompetitive activity to be prevented." Maryland v. United States, 460 U.S. at 1004 (Rehnquist, J., dissenting). "[T]hat there was an antitrust violation," and "the scope and effects of the violation," were not assumed, as they must be in a pretrial settlement, but proved to the satisfaction of two courts. Id.

Very limited prosecutorial discretion remains in this situation. The amorphous, policy-laden choices whether to bring a case and how much to allege, are behind us. The predictive judgment as to the chances of success on liability likewise is beyond serious dispute in light of the unanimous affirmance of monopolization liability by the en banc court of appeals. DOJ has some leeway in choosing a remedy, but its chosen remedy must be "adequate to remedy the antitrust violations alleged in the complaint," United States v. Bechtel Corp., 648 F.2d 660, 665 (9th Cir. 1981), under the well-established legal standards for antitrust relief. See Microsoft III, 253 F.3d at 103. Those standards inform the "public interest" determination under the Tunney Act, and, by contrast with the "public interest" standing alone, are judicially manageable without a doubt.

The D.C. Circuit has made crystal clear that a consent decree "even entered as a pretrial settlement, is a judicial act," so that "the district judge is not obliged to accept one that, on its face and even after government explanation, appears to make a mockery of judicial power." Microsoft I, 56 F.3d at 1462. Judicial approval of the settlement in this case is far more of a classic "judicial act" than the typical settlement without proof of liability. As in the context of post-conviction criminal sentencing, the Court must act as more than a passive recipient of arrangements made between the parties

There is no serious question that a federal court may reject a plea bargain in its sound discretion, Fed. R. Crim. P. 11, Santobello v. New York, 454 U.S. 257, 262 (1971), for reasons that may include the "court's belief that the defendant would receive too light a sentence under the circumstances." United States v. Adams, 634 F.2d 830, 835 (5th Cir. 1981).⁽³⁾ Granted, plea bargains in the criminal context generally involve admissions of liability. But the case here, if anything, is stronger here, where liability has been, not admitted, but established after extensive litigation and affirmed by an en banc court of appeals over the vigorous objection of the defendant.

At this stage, "the discrepancy between the remedy and undisputed facts of antitrust violations" can "be such as to render the decree 'a mockery of judicial power.'" Massachusetts School of Law, Inc. v. United States, 118 F.3d 776, 782 (D.C. Cir. 1997) (quoting Microsoft I, 56 F.3d at 1462). By contrast with the concerns expressed in the pretrial settlement context about the intrusion of Tunney Act courts on functions that are constitutionally allocated to the executive branch, the situation after liability is established presents opposite concerns under our system of separated powers, and of checks and balances between the branches of government. Constitutional concerns in this case would arise only if the Court failed to apply the legal standards governing antitrust relief to the adjudicated liability here. DOJ asks the Court not only to abandon its traditional power over the relief to be imposed in an adjudicated case, but also to ignore the clear command of Congress to provide a check on the irresponsible exercise of power by a suddenly and inexplicably compliant prosecutor. The Court should refuse that suggestion.

1. 1. 2. • The Extensive Record And Judicial Opinions Provide Clear, Manageable Standards For Substantive Review Of The RPFJ

None of the authorities on which DOJ relies involved a full trial in which liability was proved, much less one in which liability was affirmed on appeal. Indeed, the statements quoted in the CIS draw heavily on that fact -- that in each case there had been no finding of liability, and that review of the settlement at issue necessarily involved second-guessing DOJ's prosecutorial discretion in making two rather standardless assessments: (1) whether to bring a case at all, and thus place the matter in a judicial forum, see Microsoft I, 56 F.3d at 1459-1460, and (2) the chances for success. See, e.g., Mid-America Dairymen, 1977 WL 4352, at *8 (Tunney Act "did not give this Court authority to substitute its judgment about the advisability of settlement by consent judgment in lieu of trial") (emphasis added).

Here, neither of these fundamentally discretionary prosecutorial judgments is at issue. The decision to bring the case was made years ago, and the case was litigated and won, establishing liability to a known extent.

It is telling that in asking for broad deference DOJ places heavy reliance on language from the Ninth Circuit's decision in United States v. Bechtel Corp., 648 F.2d 660 (9th Cir. 1981). See CIS 66-67 & n.4; 66 Fed. Reg. 59,476. One could hardly find a setting more distant from this one. Not only did Bechtel not involve a finding of liability after full litigation and affirmance on appeal; and not only did the setting there -- alleged complicity in the "Arab boycott" of Israel in the mid-1970s -- implicate the foreign policy powers of the executive branch; but the issue before the court in Bechtel was the defendant's effort to avoid its own settlement by arguing that the settlement to which it had agreed was "not in the public interest." Bechtel, 648 F.2d at 665.⁽⁴⁾

As it happens, however, the court of appeals in Bechtel enunciated the legal standard that should be applied here: "whether the relief provided for in the proposed judgment was adequate to remedy the antitrust violations alleged in the complaint." Bechtel, 648 F.2d at 665 (emphasis added). That is precisely the standard that DOJ wishes to avoid. Where liability is a given, as it is here, the Court must ensure that the "remedies negotiated between the parties and proposed by the Justice Department clearly and effectively address the anticompetitive harms" that have been proved. United States v. Thomson Corp., 949 F. Supp. 907, 913 (D.D.C. 1996). When the "anticompetitive harms" and their illegality have been proved, the fit between those harms and the proposed remedies must be closer than when those harms merely have been "initially identified," id., as is usually the case in Tunney Act proceedings.

Even if there were no finding a liability, the Court would not be compelled "unquestionably [to] accept a consent decree as long as it somehow, and, however inadequately, deals with the antitrust problems implicated in the lawsuit." United States v. Alcan Aluminum, Ltd., 605 F. Supp. 619, 622 (W.D. Ky. 1985) (citing United States v. AT&T, 552 F. Supp. 131, 151 (D.D.C. 1982), aff'd sub nom. Maryland v. United States, 460 U.S. 1001 (1983). With liability in place, however, the Court need not proceed "on the assumption that the government would have won." Gillette, 406 F. Supp. at 716 n.2. The government did win. The Court in this case need not "speculate in regard to the probability of what facts may or may not have been established at trial." United States v. Mid-America Dairymen, Inc., 1977 WL 4352, at *1. Those facts are a matter of record.

Whatever narrow deference may be afforded here amounts only to the tested rule that "[i]t is not the court's duty to determine whether this is the best possible settlement that could have been obtained." Gillette, 406 F. Supp. at 716 (emphasis added). Although the Court may not be able to insist on the "best possible" decree, the proof and affirmance of liability require the Court to ensure that the RPFJ is at least adequate on that record under well-established remedial principles. Bechtel, 648 F.2d at 665.

The differences are real, but not dramatic, between the Court's role in deciding whether to accept this settlement in Track I, and in deciding in Track II what relief to impose at the request of those plaintiffs who have not abandoned the pursuit of a full and effective remedy in this case. In each track, the Court must measure proposed remedies against the legal standards set out by the D.C. Circuit and by the Supreme Court. In each track, the Court should not approve a remedy that is inadequate to meet those standards. In evaluating the RPFJ, the Court is not at liberty to substitute its view of equally effective, or marginally more effective relief, if the terms of the RPFJ are fully adequate to the task as the law defines it. That is, the DOJ's choices among adequate alternatives warrant deference, but its determination of what is adequate warrants none. In the other track, the Court does have the liberty, not merely to go beyond any decree that might be entered in this track, but also to insist that the final decree address the competitive issues in a way that satisfies the Court's view as to the best and most effective means of opening the operating systems market to competition, depriving Microsoft of the fruits of its illegal conduct, and preventing similar monopolistic abuses in the future. That is, while in this track of the proceeding the Court cannot insist on the "best possible settlement," Gillette, 406 F. Supp. at 716, so long as the proposed relief meets the remedial standards anchored in antitrust law, in Track II the Court has not only the power but the duty to impose the "best possible" decree.

1. 2. • Broad Deference Is Particularly Inappropriate Because The Circumstances Are Suspicious

1. 1. 1. • Microsoft's Manifestly Inadequate Disclosure Under The Tunney Act's Sunshine Provisions Weighs Strongly Against Judicial Deference To The Terms Of The RPFJ

Section 2(g) of the Tunney Act requires Microsoft to file a "true and complete description" of "any and all written or oral communications" by it or on its behalf "with any officer or employee of the United States concerning or relevant to" the proposed settlement. 15 U.S.C. § 16(g) (emphasis added). The only exception from this requirement is for settlement negotiations between "counsel of record alone" and "employees of the Department of Justice alone." Id. (emphasis added).

When Senator Tunney first introduced his bill, he focused on the significance of the disclosure provision. "Sunlight is the best of disinfectants," he explained (quoting Justice Brandeis), and thus "sunlight * * * is required in the case of lobbying activities attempting to influence the enforcement of the antitrust laws." 119 Cong. Rec. 3449, 3453 (1973). Minor amendments to Section 2(g) were designed "to insure that no loopholes exist in the obligation to disclose all lobbying contacts made by defendants in antitrust cases culminating in a proposal for a consent decree." H.R. Rep. No. 1463, at 12 (emphasis added).

The breadth of Microsoft's effort to use political pressure to curtail this case has no parallel in the history of the antitrust laws. The ITT episode that prompted the Tunney Act pales in comparison. It has been widely known that since 1998 Microsoft has comprehensively lobbied both the legislative and executive branches of the federal government in an effort to create political pressure to end this case.⁽⁵⁾ But Microsoft did not disclose any of these contacts, much less all of them, as the Tunney Act requires.

Rather, Microsoft disclosed only meetings that occurred during the last round of settlement negotiations ordered by the Court. Microsoft's insupportable interpretation of its statutory disclosure duty effectively nullifies the sunshine provisions of the Act, which are crucial to the Act's protection of the public interest.

1. 1. 1. 1. Contacts With All Branches Must Be Disclosed.

All contacts with "any officer or employee of the United States" must be disclosed. As Senator Tunney explained,

119 Cong. Rec. at 3453 (emphasis added). In other words, the disclosure applies

Id. Indeed, it is firmly established in other areas of the law that "officer" of the United States includes Members of Congress and their employees.⁽⁶⁾

But Microsoft did not disclose its extensive and heavily reported lobbying of Congress. Indeed, upon the remand to the District Court, Microsoft's lobbying of Congress produced a letter signed by more than 100 Members urging a swift settlement.

But Microsoft did not disclose even that lobbying, aimed at pressuring a swift capitulation by the government despite its victory on appeal, directly before the last round of settlement negotiations.

1. 1. 1. 2. • The "Counsel of Record" Exception Is Very Narrow.

Section 16(g) provides a narrow exception from disclosure for contacts between "counsel of record alone" (emphasis added) -- that is, without any other corporate officers or employees also involved -- and "the Attorney General or the employees of the Department of Justice alone." As Senator Tunney explained, this "limited exception" for attorneys of record "is designed to avoid interference with legitimate settlement negotiations between attorneys representing a defendant and Justice Department attorneys handling the litigation. * * * [T]he provision is not intended as loophole for extensive lobbying activities by a horde of 'counsel of record."' 119 Cong. Rec. at 3453. The House Report further clarifies that this "limited exception" distinguishes "'lawyering' contacts of defendants from their 'lobbying contacts'." H.R. REP. No. 1463, supra, at 9.

Microsoft did not disclose the well-publicized participation in the last round of settlement negotiations of its lobbyist-lawyer, Charles F. "Rick" Rule. It appears that the critical "negotiations" leading to the RPFJ took place, not in the offices of Microsoft's counsel of record, but "in Justice's offices and those of Microsoft legal consultant Rick Rule." Paul Davidson, Some States Fear Microsoft Deal Has Big Loopholes, USA TODAY, Nov. 5, 2001. Rule has been a registered lobbyist for Microsoft for some years, but was not named as counsel of record until November 15, 2001, after the settlement negotiations were complete. See Notice of Appearance (D.D.C. filed Nov. 15, 2001). That designation -- long after the settlement deal had been struck --cannot retroactively shield his extensive prior contacts with Mr. James or other executive or legislative officials from disclosure. Contacts by "[a]ttorneys not counsel of record" must be disclosed. Id. Of course, Microsoft's many other lobbyists do not conceivably come within this exception. But Microsoft concealed all of those lobbying contacts.

1. 1. 1. 3. All Communications Urging The Government To Abandon Or Settle The Case Were "Relevant To" The Proposed Settlement

Section 16(g) requires the disclosure of all contacts "concerning or relevant to" a proposed settlement. This statutory definition is intentionally broad. Microsoft's disclosure interprets the word "concerning" very narrowly, so that the provision covers only actual settlement discussions -- and only the last round of them. In Microsoft's view, the Tunney Act would require disclosure only of the very meetings that must precede any settlement. Microsoft reads the words "relevant to" right out of the statute. That this statutory provision is broad is obvious by its very terms; in order for the phrase "relevant to" not to be mere surplusage, it must encompass contacts less directly focused on the settlement than those that "concern[]" that agreement.

Senator Tunney gave an example: "the provision would require disclosure * * * of a meeting between a corporate official and a Cabinet officer discussing 'antitrust policy' during the pendency of antitrust litigation against that corporation." 119 Cong. Rec. at 3453. The Act borrows from evidentiary concepts, including the privilege for settlement discussions, which prompted the narrow exception for counsel of record. The evidentiary concept of relevance is very broad. See Fed. R. Evid. 401. "Relevance of evidence is established by any showing, however slight, that the evidence" makes a legally important factor "more or less likely." United States v. Mora, 81 F.3d 781, 783 (8th Cir. 1996) (emphasis added) (citation omitted). Plainly "relevant" to the question whether a defendant's lobbying activities influenced the existence and terms of a consent decree are contacts with the administration, and with members of Congress, that touch on the desirability of the government's agreeing to end the case. It is startling, for example, that Microsoft would omit reference to its efforts to enlist support for congressional proposals that would have cut DOJ's funding for the pursuit of this case, and for antitrust enforcement in high technology industries in general.⁽⁷⁾

Disclosure under Section 2(g) is not usually burdensome; most defendants do not try to win their case politically rather than in the courtroom. Microsoft's massive and unprecedented effort to distort the judicial process through political pressure makes its compliance burdensome, but all the more necessary. It is exactly this sort of manipulation that the Tunney Act was designed to discourage by bringing it to light.

1. 1. 1. 4. Microsoft's Flouting Of Its Statutory Duty Counsels Painstaking Judicial Scrutiny Of The RPFJ

Microsoft's cunning "interpretation" of the statutory disclosure requirements -- so that disclosures reach only the very settlement discussions that the Tunney Act was not concerned about -- sheds considerable light on Microsoft's likely "interpretations" of any remedy imposed on it, especially one like the RPFJ of which it can claim to be an equal drafter, if not the principal author. Microsoft's disclosure is so inadequate as to raise questions about Microsoft's good faith. The filing includes no disclosure of any lobbying contacts between Microsoft and the administration; it includes no disclosure of any contacts between Microsoft and members of Congress; it includes no disclosure of any contacts whatsoever before September 27, 2001, although it is well known that Microsoft and the government have tried to settle the government's antitrust action since before it was filed, and that Microsoft lobbied Congress to bring pressure on DOJ to settle or simply abandon the case.

Microsoft should face contempt sanctions for its certification "that the requirements of [Section 16(g)] have been complied with and that such filing is a true and complete description of such communications known to the defendant or which the defendant reasonably should have known." DOJ should refuse to acquiesce in Microsoft's deception. Although DOJ cannot be expected to be aware of all of Microsoft's lobbying of Congress in an effort to create pressure for a favorable settlement, DOJ should reveal the end-product of that pressure in the form of communications from Members and their staffs. And there is no excuse for DOJ to be complicit with Microsoft when it comes to contacts with DOJ itself. In particular, DOJ certainly is aware of Mr. Rule's lobbying contacts with before he belatedly appeared as counsel after the settlement had been concluded. The proper resolution of this issue is the appointment of a special master with the ability to examine the relevant participants under oath. In view of its responsibility to enforce 15 U.S.C. § 16(g) along with the rest of the antitrust laws, DOJ should request (and support) the implementation of such a procedure by the Court.

1. 2. • The RPFJ Represents A Swift And Significant Retreat By DOJ

Another factor counseling against deference here is the DOJ's striking capitulation to Microsoft's view of an appropriate remedy, despite the unanimous affirmance of the core of DOJ's case. The insubstantial provisions of the RPFJ provide ample "reason to infer a sell-out by the Department," Massachusetts School of Law, 118 F.3d at 784.

After prevailing on liability in the district court, DOJ sought and obtained not only structural relief -- as is "common" in broad monopolization cases, see Microsoft III, 253 F.3d at 105 -- but also "interim" conduct restrictions that clearly could not stand alone as a monopolization remedy. DOJ earlier recognized that the interim conduct remedies were stopgaps to keep the competitive situation from continuing to decline in the year or so before divestiture jumpstarted competition. See Plaintiffs' Memorandum in Support of Proposed Final Judgment 30-31 (corrected version) (filed May 2, 2000). On remand, DOJ abandoned the structural relief that it formerly found necessary, even though liability on the monopolization claim -- which alone could support structural relief in the first place -- was affirmed with minor modifications. DOJ stated that it would pursue relief "modeled upon" the interim "conduct-related provisions," along "with such additional provisions as Plaintiffs may conclude are necessary to ensure that the relief is effective, given their decision not to seek a structural reorganization of the company." Joint Status Report 2 (filed Sept. 20, 2001).

Instead of fortifying the proposed decree to compensate for the abandonment of structural relief, however, DOJ moved considerably backward from the interim remedies, narrowing Microsoft's duties and providing broad exceptions. Indeed, the RPFJ is weaker than the final proposal in the settlement negotiations that took place during Spring 2000, before any judgment of antitrust liability, much less appellate affirmance.⁽⁸⁾ Then, there was litigation risk as to liability. Now there is none. Nonetheless, the definitions and obligations in the current RPFJ fall short of those in the pre-judgment offer.

"[T]he government's virtual abandonment of the relief originally requested" is "a sufficient showing that the public interest was not * * * adequately represented" in the RPFJ. United States v. Associated Milk Producers, Inc., 534 F.2d 113, 117 (8th Cir. 1976). It is precisely when DOJ appears to have "abruptly 'knuckled under,'" id. at 118, as here, that judicial scrutiny under the Tunney Act should be most substantive and searching.

1. 3. • The CIS Overstates The Terms Of The RPFJ, Reflecting The Indefensibility of the RPFJ Itself

The CIS underscores the need for close scrutiny of the actual terms of the RPFJ and their effectiveness. The CIS seeks to convey an image of stringency by adding terms to provisions of the RPFJ that are absent from the RPFJ itself. But it is the RPFJ, not the CIS, that defines the enforceable bargain between the parties. As the Supreme Court has recognized, "any command of a consent decree * * * must be found within its four corners, and not by reference to any purposes of the parties." United States v. ITT Continental Baking Co., 420 U.S. 223, 233 (1975) (citations and internal quotation marks omitted). While the CIS may be useful in interpreting ambiguous terms in the RPFJ, the wording of the CIS is not independently enforceable. Only the RPFJ would be entered as a judgment, and "[t]he government cannot unilaterally change the meaning of a judgment." Bechtel, 648 F.2d at 665. It would be different, of course, if the CIS or its relevant refinements were "expressly incorporated in the decree." ITT Continental, 420 U.S. at 238.

In particular, the CIS goes beyond the text of the RPFJ to paint a far stricter picture of Microsoft's disclosure obligations than the RPFJ supports. It is no wonder that DOJ seeks to defend a document -- the CIS -- to which Microsoft would not be bound, rather than the far weaker RPFJ that alone would be judicially enforceable. The CIS cannot transform the RPFJ into a better deal for competition and consumers than it is.

2. • THE RPFJ MUST MEET THE LEGAL STANDARDS NORMALLY APPLICABLE TO ANTITRUST REMEDIES

The "public interest" standard in the Tunney Act is not without content. Rather, those "words take meaning from the purposes of the regulatory legislation," NAACP v. Federal Power Comm'n, 425 U.S. 662, 669 (1976). The well-developed jurisprudence of antitrust remedies provides sound guidance for the public interest determination.

Although a district court should not "engage in an unrestricted evaluation of what relief would best serve the public," Microsoft I, 56 F.3d at 1458 (quoting Bechtel, 648 F.2d at 666) (emphasis added), principled restrictions for that evaluation in this case arise from the extensive, unvacated Findings of Fact, the comprehensive opinion affirming monopolization liability on appeal, and the long-standing remedial principles of antitrust law, principles that the D.C. Circuit instructed the District Court to apply to any proposed relief on remand. See Microsoft III, 253 F.3d at 103. The "appropriate" inquiry (Bechtel, 648 F.2d at 666) is "whether the relief provided for in the proposed judgment [i]s adequate to remedy the antitrust violations" that were proved at trial and affirmed on appeal. Id. at 665.

The D.C. Circuit provided benchmarks rooted in Supreme Court jurisprudence to guide the evaluation whether a remedy is "adequate." A remedy in this case must serve "the objectives that the Supreme Court deems relevant," Microsoft III, 253 F.3d at 103. That is, a remedy must "seek to * * * [1] 'terminate the illegal monopoly, [2] deny to the defendant the fruits of its statutory violation, and [3] ensure that there remain no practices likely to result in monopolization in the future.'" Id. at 103 (quoting Ford, 405 U.S. at 577, and United Shoe, 391 U.S. at 250).⁽⁹⁾

1. 1. • The Relief Should "Terminate The Illegal Monopoly"

In a monopolization case, the problem to be remedied is the monopoly itself. Because the RPFJ would leave the illegally maintained monopoly in place without making the market structure more competitive, to satisfy this criterion relief must exclude the possibility that Microsoft again will prolong its monopoly power by abusing it. At a minimum, however, a monopolist should emerge from a remedy facing competitive threats of similar scope and significance to those it illegally stamped out. The D.C. Circuit recognized that the illegal conduct in this case was aimed at increasing and hardening the applications barrier to entry that insulates Microsoft's OS monopoly. See id. at 55-56, 79. The CIS similarly recognized that "[c]ompetition was injured in this case principally because Microsoft's illegal conduct maintained the applications barrier to entry * * * by thwarting the success of middleware." CIS 24, 66 Fed. Reg. 59,465. A remedy that does not literally terminate the monopoly accordingly must undermine the applications barrier to entry that was strengthened by the illegal conduct.

1. 2. • The Relief Should Prevent "Practices Likely To Result In Monopolization In The Future"

To satisfy this criterion, any remedy must both (1) prevent the monopolist from engaging in the same sorts of conduct that underlie the current finding of liability, and (2) prevent other types of conduct that could preserve the monopoly. The "monopolization in the future" that must be prevented includes both the simple maintenance of the current monopoly and the expansion of that monopoly's scope. Relief should make it impossible for the monopolist to continue its pattern of using current market power to foreclose imminent or contemplated competitive threats. Because Microsoft has been "caught violating the [Sherman] Act," it "must expect some fencing in." Otter Tail Power Co. v. United States, 410 U.S. 366, 381 (1973).

A monopolist that has been litigating for years no doubt has developed anticompetitive techniques that achieve the same goals through slightly different means. Microsoft embarrassed DOJ by obtaining language in the 1995 consent decree that was tailored to exclude, at least arguably, the company's next planned anticompetitive initiative. Exemptions, provisos, and narrow definitions should be scrutinized on the assumption that Microsoft again has tried to ensure that the RPFJ will not impede currently planned anticompetitive acts.

1. 3. • The Relief Should "Deny To The Defendant The Fruits Of Its Statutory Violation"

Relief in an antitrust case not only must prevent "recurrence of the violation," but also must "eliminate its consequences." National Society of Professional Engineers v. United States, 435 U.S. 679, 697 (1978). Thus, a remedy should prevent a monopolist from retaining the accrued competitive benefits of its illegal conduct. These advantages may permit a monopolist to maintain its monopoly without additional antitrust violations. Relief that allows a wrongdoer the full benefit of its illegal activity fails the most basic test of any remedy under any branch of the law.

In this case, the "fruits" of Microsoft's illegal conduct may be the most important target of a responsible remedy. One of the chief advantages that Microsoft gained by incorporating the Internet browser into the Windows monopoly was the ability to control not only the browser for its own sake, suppressing the possibility that the Internet browser would provide a source of alternate, OS-neutral APIs, but also the browser as the gateway to all Internet computing. As the Litan/Noll/Nordhaus Comment explains (at 58- 60), one of the most important fruits of monopolistic conduct is the suppressed development of competitive threats. That is why a forward-looking remedy must be rooted in current market conditions, and must seek to restore competition to where it likely would have been in the absence of the anticompetitive conduct. Litan/Noll/Nordhaus Comment 35-36, 40-42, 58-59.

1. 4. • Broader Principles Applicable To Injunctive Relief Also Should Inform The Analysis Of The RPFJ

The remedial analysis here resembles other remedial undertakings. Although civil antitrust relief is not punitive, effective antitrust relief shares with criminal sentencing the broad goals of incapacitation and deterrence. As much as possible, an illegal monopolist should be flatly prevented from engaging in the same or similar suppression of competition in the future. In addition, the remedy should be enforceable with sufficient speed and certainty to make stiff contempt sanctions likely if the monopolist nonetheless manages to engage in anticompetitive conduct again.

The point of antitrust relief after a finding of liability is to learn from history, not to permit the offender to repeat it. This consideration is particularly acute here, where the purposes of the expiring 1995 consent decree clearly have not been realized, but rather have been evaded or neutralized.

Because antitrust relief necessarily is forward-looking, a remedy's effectiveness should be judged with respect to where the market is going, not where it has been. Microsoft has directed its efforts to destroy the competitive threat of Internet computing. The more functionality that is performed on the Web, the less significant the operating system on a particular client device connected to the Web. Thus, Internet computing represents the maturation of the competitive threat posed by the Internet browser and squelched by Microsoft's illegal conduct. The current industry-wide focus on Web-based services reflects the realization that a competitive market still survives in this sector. The Court will have to consider whether the RPFJ in fact is "all about the past, not the future battle in Internet services[, and] doesn't touch the company's ability to use Windows XP to extend its monopoly to these new areas." Walter Mossberg, For Microsoft, 2001 Was A Good Year, WALL ST. J., Dec. 27, 2001, at B1. See Stiglitz/Furman Dec. 38-39.

3. • THE RPFJ FALLS FAR SHORT OF PROVIDING A REMEDY FOR PROVEN OFFENSES UPHELD ON APPEAL

The RPFJ lights upon narrowly defined practices and prohibits narrowly defined versions of them, in ways that might have mitigated, but would not have ended, the very conduct at issue in this case. The RPFJ does not measure up to the sweeping monopolization violations found by two courts. The RPFJ's provisions do not address Microsoft's ability and incentives to strengthen the applications barrier to entry, which was the underlying issue at the core of the case, instead focusing on techniques of monopolization that have been defined so narrowly that Microsoft's actual behavior need not change. And when addressing a precise technique that directly implicated the reinforcement of the applications barrier to entry -- Microsoft's ability to stop porting its Office productivity suite to the Apple Macintosh platform -- the RPFJ permits Microsoft to retain the ability to repeat that threat in slightly altered contexts.

1. 1. • DOJ's Effort To Minimize The Scope Of The D.C. Circuit's Affirmance Cannot Obscure The Failure Of The RPFJ To Remediate Clear, Proven Violations

DOJ has tried to lower the bar for approval of its proposal by minimizing the most significant appellate imposition of monopolization liability in the past half-century, and adopting Microsoft's crabbed view of its own liability. In Senate testimony, Assistant Attorney General James made the remarkable assertion that the D.C. Circuit, despite affirming "the District Court's holding that Microsoft violated § 2 of the Sherman Act in a variety of ways," 253 F.3d at 59, somehow precluded any consideration, for remedial purposes of Microsoft's astonishing anticompetitive campaign as a whole. See James Testimony 5. To the contrary, the court of appeals never rejected the common-sense notion that "Microsoft's specific practices could be viewed as parts of a broader, more general monopolistic scheme"; much less did the court of appeals insist (or even hint) that "Microsoft's practices must be viewed individually" for all purposes. Id. Rather, the court of appeals clearly considered some illegal acts in the context of others. Thus, the court held that Microsoft's exclusive contracts with ISVs, though affecting only "a relatively small channel for browser distribution," had "greater significance because * * * Microsoft had largely foreclosed the two primary channels to its rivals." 253 F.3d at 72.

The D.C. Circuit's examination of the divestiture remedy is telling. If the many separately illegal monopolistic acts could not be viewed as cumulatively contributing to the illegal maintenance of Microsoft's monopoly, divestiture would have been an unthinkable remedy, since no specific act held illegal on appeal changed the structure of the company or of the market. But the court of appeals recognized that divestiture could be justified if the many separate illegal acts, taken together, were shown to have had a sufficiently certain causal connection to justify using structural relief to undermine, if not end, the monopoly. See 253 F.3d at 80, 106-107.

The court of appeals did "reverse [the] conclusion that Microsoft's course of conduct separately violates § 2 of the Sherman Act." 253 F.3d at 78 (emphasis added). But the reversal occurred because the district court purported to find that a series of acts that did not constitute separate, free-standing antitrust violations had a "cumulative effect * * * significant enough to form an independent basis for liability" -- but never specified acts other than those that separately violated Section 2 that might be aggregated into such a violation. Id.

It is a remarkable leap from this unremarkable holding to the absurd notion that Microsoft's extraordinary series of separate adjudicated antitrust violations cannot be considered together for any purpose. Even the CIS recognizes that those violations are part of one coordinated and "extensive pattern of conduct designed to eliminate the threat posed by middleware." CIS 11, 66 Fed. Reg. 59,462. They should be remedied as such.

1. 2. • The RPFJ Simply Restates The Antitrust Laws At Critical Points And Thus Forfeits The Clarity And Efficiency Of The Contempt Process

Another striking feature of the RPFJ is its repeated reliance on a reasonableness standard of conduct that simply imports full rule-of-reason analysis under the antitrust laws. Antitrust remedies, like other injunctive decrees, are supposed to be amenable to swift and sure enforcement, according to standards that give warning of what is forbidden and what is permitted both to the wrongdoer and to its potential victims. But the RPFJ would regularly require the decree Court to determine whether Microsoft's conduct was "reasonable." For example, the Court would have to determine

• whether volume discounts were "reasonable" or exclusionary (RPFJ § III(B)(2));
• whether technical requirements for the bootup sequence that Microsoft Imposed on OEMs were "reasonable" (id. § III(C)(5));
• whether the terms on which Microsoft makes Communications Protocols available are "reasonable" (id. § III(E));
• whether exclusivity requirements imposed on ISVs were "reasonable" in "scope and duration" (id. § III(F)(2)); see also id. § (III(G)(2));
• whether technical requirements designed to force the invocation of Microsoft Middleware despite contrary consumer or OEM preferences are "reasonable" (id. § III(H)(2)[second]);
• whether the licensing terms accompanying required disclosures, and terms of mandatory cross-licenses required for access to the disclosures, are "reasonable" (id. §§ III(I)(1), III(I)(5));
• and whether Microsoft's bases for excluding ISVs from access to securityrelated protocols are "reasonable" (id. § III(J)(2)(b)-(c)).

It is telling that the RPFJ states so many of its provisions in terms that simply duplicate the antitrust rule of reason. Rule of reason disputes are notoriously difficult to litigate, see Arizona v. Maricopa County Medical Soc., 457 U.S. 332, 343 (1982) (noting "extensive and complex litigation" involving "elaborate inquiry" at "significant costs"), -- and difficult for plaintiffs to win. These provisions add nothing to the antitrust laws themselves, either in clarity of obligation or in efficiency of enforcement. That is no remedy at all.

1. 3. • The RPFJ Provides No Remedy For Microsoft's Suppression Of The Browser And Java.

As noted above, perhaps the most glaring deficiency of the RPFJ is that it does nothing to restore the competitive threats to Windows posed by the Internet browser and cross-platform Java. That cannot be an oversight. The bulk of the evidence, and much of the opinion of the court of appeals affirming liability, focused on Microsoft's successful efforts to suppress these threats to the applications barrier to entry. See Microsoft III, 253 F.3d at 58-78. Even the CIS recognizes the primacy of these products in the case. See CIS 10-17, 66 Fed. Reg. 59,462-463.

Yet the RPFJ does not change the competitive picture for either product in the least. The RPFJ does not deprive Microsoft of these "fruits" of its illegal conduct, but instead takes that illegal conduct, and the advantages derived from it, as a tacit baseline for future competition. The RPFJ leaves Microsoft with the full benefit not only of the years of insulation from the competitive threats posed by those products, but also of the expanded power it has accumulated by incorporating Internet Explorer into the Windows monopoly. Microsoft thus has more, and stronger, weapons to suppress any middleware threats that it identifies in the future, since its monopoly control over the browser -- now labeled part of the Windows monopoly product -- provides Microsoft with complete control over the universal client for Internet computing. The RPFJ's approach is like sentencing a bank robber to probation, but letting him keep his weapons and the loot.

But the RPFJ's failure to provide relief that restores the specific competitive threats that Microsoft Illegally suppressed is worse than that. In a platform technology market like that for PC operating systems, single standards tend to prevail, so that only sweeping changes can dislodge the incumbent. Platform threats are very rare. It could easily be another five or ten years or more before a comparable threat arises again; certainly no threat of similar strength to the Internet browser or Java has surfaced in the nearly seven years since Microsoft began the course of illegal conduct condemned by the court of appeals. See Stiglitz/Furman Dec. 35-36. That is what makes anticompetitive conduct directed at them so potentially profitable. The RPFJ makes that conduct profitable beyond any rational actor's wildest dreams, and greatly increases the incentives for its repetition. Having been caught illegally suppressing two related platform threats, Microsoft retains all the benefits that it sought through its illegal acts.

By eliminating Navigator, Microsoft has not only eliminated consumer choice in browsers, but it also seized the power to control the interfaces and protocols through which an enormously valuable set of Internet applications -- ranging from instant messaging and e-mail to streaming video and e-commerce -- are delivered to desktop computers and other digital devices. Microsoft's Internet Explorer is now the bottleneck through which all Internet-related middleware must pass. Instant messaging and media player technology are equally dependent on browser software. Microsoft has also seized the power to decide whether that browser functionality will be ported to any competing operating system, and, if so, to which ones. Finally, in destroying Navigator, Microsoft has also destroyed an important alternative distribution channel, one free of Microsoft's control or influence, through which Microsoft's competitors could formerly distribute middleware runtimes and products to desktop consumers and application developers.

Although Navigator has practically disappeared from the competitive scene, Java has not. But Java's importance has been limited to servers, where Microsoft has a leading share but not yet an operating systems monopoly. Microsoft's conduct appears to have assured that Java will not function as cross-platform middleware for client computers. Java thus poses no threat to the desktop OS monopoly. But the RPFJ lets Microsoft keep that anticompetitive benefit of its conduct.

4. • THE ICON-FOCUSED OEM FLEXIBILITY PROVISIONS ARE INEFFECTIVE

RPFJ §§ III(H)(1)-(2)[first] superficially allow OEMs and end users to rearrange icons and menu entries relating to middleware.⁽¹⁰⁾ These provisions are hollow, however. Section III(H)(1) duplicates only what Microsoft unilaterally agreed to permit OEMs to do back on July 11, 2001. And the end-user provisions simply restate and preserve endusers' longstanding options to delete icons and menu entries if they right-click and delete or drag the icon or menu entry to the Recycle bin. The default provisions in Section III(H)(2) are so limited, and so fully subject to Microsoft's architectural control, as to be competitively meaningless as well.

The icon provisions do not adequately address the competitive harms of Microsoft's adjudicated misconduct because Microsoft remains able to ensure that the Microsoft versions of middleware will appear, ready to be invoked by applications, on every PC. Even if the icon provisions had greater competitive significance in theory, they are unlikely to have any significance in fact, because few if any OEMs are likely to take advantage of the options provided. DOJ cannot claim to be unaware of this market reality. These provisions are mere window-dressing. See Stiglitz/Furman Dec. 35.

1. 1. • The PFJ Permits Microsoft's To Continue Illegally Commingling Middleware Code With The Code For The Monopoly Operating System

The RPFJ capitulates on DOJ's most hard-fought and significant substantive victory: the finding that Microsoft Illegally preserved its monopoly by commingling the middleware code with the operating system, foreclosing the competitive threat to Windows while effectively expanding the scope of the monopoly to encompass middleware. DOJ's inability to enforce the 1995 consent decree against the binding of IE to Windows, see United States v. Microsoft, 147 F.3d 935 (D.C. Cir. 1998) ("Microsoft II"), was widely viewed as prompting this action. The conduct itself was viewed as the most successful in furthering Microsoft's anticompetitive goals.

Rather than repeat and strengthen the prohibition in the 1995 decree that failed to achieve its goals, the RPFJ does not even impose the type of superficial prohibition applied to other conduct condemned at trial and on appeal. To the contrary, under the RPFJ, the operating system is whatever Microsoft says it is, and Microsoft can commingle any new product to the monopoly product -- foreclosing competition for the OS and the new product alike. See Stiglitz/Furman Dec. 34-37. Not only does Microsoft preserve its anticompetitive gains, but it obtains a green light to repeat the same conduct to destroy any new middleware threats. In a market characterized by serial dominance, an incumbent monopolist may need only to suppress one threat every few years in order to make its monopoly virtually permanent. Cf. id. at 35-36. A continued ability to commingle middleware gives Microsoft limitless tenure over the OS market. If Microsoft emerges from this case free to bind middleware to the OS, this action will be an exercise in futility.

1. 1. 1. • The DC Circuit Specifically Condemned Commingling Twice

DOJ's victory on the commingling point was crystal clear, and repeatedly underscored by the court of appeals. The court of appeals recognized that "Microsoft's executives believed" that "contractual restrictions placed on OEMs would not be sufficient in themselves" and therefore "set out to bind" IE "more tightly to Windows 95 as a technical matter." Microsoft III, 253 F.3d at 64 (quoting Findings, 84 F. Supp.2d at 50 (¶ 160)). In the CIS (and in Assistant Attorney General James' Senate testimony), DOJ appears to assume that icon-based relief that subjects some Microsoft Middleware Products to the Add/Remove utility equates with relief for commingling code. Thus, the CIS blends the two offenses in stating that Microsoft violated Section 2 when it "integrated Internet Explorer into Windows in a non-removable way while excluding rivals." CIS 7, 66 Fed. Reg. 59,461. In affirming liability for both courses of conduct, however, the court of appeals clearly distinguished between Microsoft's "excluding IE from the 'Add/Remove Programs' utility" and its "commingling code related to browsing and other code in the same files." 253 F.3d at 64-65, 67. The court of appeals found no justification for commingling code or, indeed, more broadly, for "integrating the browser and the operating system." Id. at 66. One could hardly ask for a clearer statement.

Microsoft argued bitterly against liability for commingling, and for a declaration that its product design decisions were beyond the reach of the antitrust laws. Instead, the D.C. Circuit pointedly rejected Microsoft's argument that it "should vacate Finding of Fact 159 as it relates to the commingling of code." Microsoft III, 253 F.3d at 66; see Findings, 84 F. Supp.2d at 49-50 (¶ 159). And the court of appeals "conclude[d] that such commingling has an anticompetitive effect," because it "deters OEMs from pre-installing rival browsers, thereby reducing the rivals' usage share and, hence, developers' interest in rivals' APIs as an alternative to the API set exposed by Microsoft's operating system." 253 F.3d at 66 (emphasis added). See generally id. at 64-67. That is, commingling helps reinforce the applications barrier to entry that shields the Windows monopoly.

The D.C. Circuit's holding reflected a principle of critical importance to the enforcement of the antitrust laws in the software industry, where the complementarity of different programs makes product design a potentially devastating weapon to foreclose competition: a "monopolist's product design decisions" can violate the antitrust laws just as any other economic conduct can. 253 F.3d at 65. Product design decisions may be grossly anticompetitive, particularly in the software industry where lines of code can be packaged (and marketed) in many different ways without affecting the operation of programs once they are installed. As Microsoft's James Allchin recently acknowledged, software "code is malleable," so that "[y]ou can make it do anything you want." Microsoft Net Profit Fell 13% in Recent Quarter, Wall St. J. Europe, Jan. 18, 2002, 2002 WL-WSJE 3352885 (quoting Allchin).

Lest there be any doubt on the matter, the court of appeals flatly rejected Microsoft's rehearing petition aimed squarely at the remedial issue. Microsoft specifically sought to preclude relief that addressed the commingling violation, and instead to treat the commingling and the lack of add/remove functionality as the same. Microsoft's rehearing petition made clear that the "ruling with regard to 'commingling' of software code is important because it might be read to suggest that OEMs should be given the option of removing the software code in Windows 98 (if any) that is specific to Web browsing [as opposed to] removing end-user access to Internet Explorer." Appellant's Petition for Rehearing, at 1-2 (July 18, 2001). Microsoft argued that affirmance only on the ground of the add/remove issue would ensure that the remedy was tightly confined, because the "problem will be fully addressed by including Internet Explorer in the Add/Remove Programs utility, which Microsoft has already announced it will do in response to the Court's decision." id. at 2.

The court of appeals rejected this argument out of hand, adding this remarkable sentence in a terse per curiam order denying rehearing: "Nothing in the Court's opinion is intended to preclude the District Court's consideration of remedy issues." Order at 1 (D.C. Cir. Aug. 2, 2001) (per curiam). Nonetheless, the RPFJ would settle this case as if rehearing had been granted, requiring Microsoft only to allow OEMs and end users to "add/remove" the icons for middleware. This is insufficient to remedy technological binding -- commingling since it does nothing to remove the underlying middleware code on which developers will continue to rely. If only the Internet Explorer icon is removed from the desktop, the IE middleware remains, and with it the same applications barrier issues that Microsoft preserved by stifling competition by Netscape and Java.

It is true that the interim conduct relief in the vacated Final Judgment required only that Microsoft offer an operating system where OEMs and end-users were permitted to remove end-user access to the middleware components, United States v. Microsoft Corp., 97 F. Supp.2d 59, 68 (D.D.C. 2000), vacated, 253 F.3d 34 (D.C. Cir. 2001), a provision similar to that in RPFJ § III(H)(1)[first]. That transitional provision of course assumed the existence of structural relief that would remove Microsoft's economic incentive to bind middleware to the OS unless the binding was independently justifiable. Without a structurally more competitive market, those modest provisions would be meaningless, and would permit Microsoft to follow much the same course that triggered the lawsuit.

There is no excuse for DOJ's failure to do anything about one of the principal, and most easily replicable, violations in the case. Even one of Microsoft's vocal, libertarian defenders, University of Chicago law professor Richard Epstein, recognized that the minimum plausible remedy after the D.C. Circuit decision would involve "undoing a few product-design decisions." Richard Epstein, Phew!, Wall. St. J., June 29, 2001, at A10. But DOJ did not even insist on that. Instead, the RPFJ's omission of any relief for this violation gives Microsoft something the D.C. Circuit twice refused: a victory on the hardest-fought legal issue in the case. Given the central importance of middleware to the theory of the case, failing to address the principal means by which Microsoft bundled browser middleware to Windows would be plainly inadequate.

1. 1. 2. • The Failure To Limit Commingling Is Critical Because Ubiquity Trumps Technology In Platform Software Markets

The failure to prohibit commingling of middleware deprives the RPFJ of any significant procompetitive effect on the emergence and adoption of competing platform software. The critical competitive phenomenon in this case was not middleware in itself, but rather the potential, and deeply feared, development of particular middleware into a competing platform for software applications. Middleware can develop into a competing applications platform by attracting software developers to use its Application Programming Interfaces (APIs) in preference to, or at least in addition, to the APIs offered by Microsoft In Windows. Developers will write their applications to invoke particular APIs -- i.e., to run on a particular platform -- based on how widely available the APIs will be.

Although potential platform software not distributed by Microsoft must attract users in order to achieve the widespread availability of their APIs that will attract developers, it is the expected presence of the APIs that matters, not how much consumers directly use the application exposing the APIs. Non-Microsoft middleware depends on the availability of the application in order to gain the critical mass of users that, in turn, may attract developers.

The availability and prominence of the application's icon may be significant for the purpose of attracting end-users. In platform competition, however, the availability of the application is only a means to the desired end. Developers don't write to icons; they write to APIs. The inclusion of Microsoft Middleware functionality in every copy of Windows is determinative, regardless of how or whether the icons are featured, and regardless even of the presence of the user interface or shell.⁽¹¹⁾ If developers know that the plumbing for a Microsoft version of middleware will be on every PC because it is commingled with Windows, then developers will write to the Microsoft version's APIs. Because the RPFJ permits Microsoft to include the APIs accompanying the software functionality that mimics middleware that is a potential platform threat, Microsoft will be able to defeat any middleware threat in exactly the same way it destroyed the threat of Netscape and Java on the PC desktop. See Stiglitz/Furman Dec. 36.

Under the RPFJ, developers will continue to assume that Windows Media Player, for example, is present on every computer. This will be true regardless of whether "end user access" is removed, because the remedy does not require Microsoft to remove the middleware. The result is that software developers will write applications to, for example, the Windows Media Player APIs, rather than to the APIs supplied by rival platforms. That is an advantage that no competitor can overcome.

It is no answer to say that OEMs can offer rival middleware even if the code for a Microsoft version of the same product is commingled with Windows, so that the Microsoft version of middleware appears on every desktop PC. If Microsoft's version of a product is everywhere, few OEMs will go to the effort of providing another product that does largely the same thing. The district court and court of appeals alike recognized that OEMs faced strong disincentives to install two competing products with similar middleware functionality, disincentives arising largely from support costs and disk space. See 84 F.Supp.2d at 49-50, 60-61 (¶¶ 159, 210); 253 F.3d at 61. If the Microsoft Middleware is there, the OEM will have to support it, even if -- perhaps especially if -- the end-user does not know that it is there.

Thus, rival middleware cannot undermine Microsoft's monopoly unless (1) the rival middleware is ubiquitous, or (2) the Microsoft version is not ubiquitous. If developers do not feel compelled to write to the rival middleware as well as the Microsoft middleware, the rival middleware will not undermine the monopoly. And if Microsoft's version of particular middleware can be ubiquitous by virtue of its inclusion in the monopoly operating system, as the RPFJ plainly allows, there is virtually no likelihood that rival middleware will ever achieve the ubiquity needed to present a platform challenge. See Stiglitz/Furman Dec. 36-37; see generally Litan/Noll/Nordhaus Comment 44-47.

1. 1. 3. • The RPFJ Retreats From The 1995 Consent Decree

Microsoft uses Windows as an instant, universal distribution channel for Microsoft software that represents a response to a threat to the dominance of Windows as a program development platform. As a consequence, "Windows" has become whatever bundle Microsoft needs it to be to forestall competition. The 1995 Consent Decree contained a prohibition on contractual tying of applications to the operating system in order to prevent anticipated conduct that would maintain the operating systems monopoly by anticompetitive means. That the earlier provision failed in its purpose suggests that the provision should be broader, not that it should be abandoned, particularly since this case began as a way to stop conduct that had escaped summary condemnation under the earlier decree. It would be senseless as a matter of enforcement policy to bring and win an action prompted by an evasion (if not a violation) of a monopolization consent decree, win the case on the monopolization theory most closely related to the object of the earlier consent decree, and then reward the violator by removing the relevant restriction upon the expiration of the earlier decree rather than broadening it as proposed here.

Microsoft's monopoly gives it the power to make all systems integration and software bundle decisions, a power that Microsoft Is exercising more broadly, as the breadth of the Windows XP bundles clearly illustrates. The RPFJ should not step back from the 1995 Consent Decree.

1. 1. 4. • The RPFJ Encourages Illegal Commingling By Placing The Critical Definition of Windows Under Microsoft's Exclusive Control.

But the RPFJ does step back from the 1995 Decree, and makes matters still worse. Not only does the RPFJ completely fail to prevent future illegal commingling, but it effectively approves that conduct by permitting Microsoft "in its sole discretion" to "determine[]" exactly which "software code comprises [sic] a Windows Operating System Product." RPFJ § VI(U). That provision permits Microsoft an unearned advantage in repelling any future challenges to illegal commingling of applications code with Windows. Were the Court to enter this provision as part of its judgment, Microsoft could point to DOJ's capitulation on this issue -- and the Court's approval -- as extraordinarily persuasive evidence that its monopoly product was as broad as it says it is, and that, despite the contrary holding of the D.C. Circuit, any commingling of an application with the operating system is per se legal.

The Court can and should disapprove provisions that appear to endorse practices of apparent anticompetitive effect and dubious legality. Thomson Corp., 949 F. Supp. at 927-930 (refusing to approve fee schedule for mandatory license for legally dubious copyright). The Court should not approve this provision, which defangs many of the other obligations in the RPFJ.

Rather than learning from the difficulties with the "integration proviso" in that Decree, DOJ has ceded the issue to Microsoft, permitting Microsoft to decide for purposes of the decree obligations where the OS stops and where middleware begins. Much of the RPFJ rests on the relationship between the Windows OS and middleware. But the RPFJ places Microsoft firmly in control of every technical aspect of the proposed decree by permitting Microsoft absolute control over the definition of "Windows Operating System Product." That subjects many of Microsoft's purported obligations to Microsoft's own discretion.

No term is more important in the RPFJ than "Windows Operating System Product," which appears fully 46 times in the RPFJ: 26 times in the descriptions of substantive obligations, and 20 times in the definitions that circumscribe those obligations. The definition of Application Programming Interfaces (APIs) is the starkest example. "Windows Operating System Product" appears three times among the 41 words of the API definition. See RPFJ § VI(A.). Thus, Microsoft can determine "in its sole discretion" what an API is, and thus what must be disclosed.

One would think that DOJ would do everything possible to ensure that a new decree did not contain an analogue to the "integration proviso" that nullified much of the anti-tying provision of the 1995 decree. See generally Microsoft II, 147 F.3d 935. Instead, Section VI(U) ensures that few, if any, of the technical provisions of the RPFJ will mean anything except what Microsoft wants them to mean, and that none can be enforced without lengthy litigation that will further shrink the tightly limited duration of the proposed relief.

1. 2. • Empirical Evidence Shows That The Icon Flexibility Provisions Will Not Be Used

Not only do the icon flexibility provisions address the wrong problem, but the market already has tested their consequences. On July 11, 2001, Microsoft announced that OEMs and end users would be permitted to remove access to Microsoft's Internet Explorer browser, just as RPFJ § III(H)(1) permits. As of this writing, not one OEM has availed itself of this new liberalized policy. Windows XP is shipping with Internet Explorer on every single personal computer shipped by every single OEM. This real- world experience speaks volumes about the practical significance of this relief.

1. 3. • The Icon Flexibility Provisions Require -- And Accomplish -- Little

1. The icon flexibility provisions do not permit OEMs to swap out Microsoft Middleware Products and replace them with other products. Rather, the OEMs at most can hide the Microsoft icon, but need to be prepared to support the underlying Microsoft software when another software application invokes it. That means that these provisions do not address the added "product testing and support costs" that discourage OEMs from including more than one version of particular functionality. Microsoft III, 253 F.3d at 66.

This is a step backward from DOJ's settlement posture before liability was established. At that time, DOJ insisted that OEMs be allowed to alter or modify Windows, and that Microsoft provide OS development tools for that purpose. See Draft 18, §§ 4(1)(d), 4(g). The RPFJ provisions, by contrast, only permit OEMs to display icons, shortcuts, and menu entries for Non-Microsoft Middleware. The RPFJ does not require Microsoft to permit OEMs to remove any Microsoft Middleware Products, although even current Microsoft practice permits this. The RPFJ requires Microsoft only to allow the removal of "icons, shortcuts, or menu entries." RPFJ § III(H)(1)[first].

2. Section III(H)(2)[first] seems to permit OEMs and end-users to choose default middleware for particular functions. Microsoft's obligations are far less than they appear.

The provision applies only where a Microsoft Middleware Product would launch into a top-level display window (rather than operating within another interface) and would either display "all of the user interface elements" or the "Trademark of the Microsoft Middleware Product." RPFJ § III(H)(2)(i)-(ii) (emphasis added). Thus, the provision does not apply if Microsoft designs the slightest variation on the interface elements that launch from within another application, so long as the trademark also is not displayed in the top-level window. These do not present serious programming challenges. Microsoft's ability to preclude OEM installation of desktop shortcuts that "impair the functionality of the [Windows] user interface" (RPFJ § III(C)(2)) provides another, largely unreviewable set of opportunities to impede the use of innovative shortcuts to innovative software. Microsoft asserted similar reasons to defend some of the conduct condemned by the D.C. Circuit. See Microsoft III, 253 F.3d at 63-64. The D.C. Circuit rejected Microsoft's approach, but the RPFJ adopts it.

3. As explained above, the code beneath the surface is critically important to the success of middleware in undermining the applications barrier to entry in the OS market. The RPFJ contains exceptions that ensure that, however icons may be displayed on the surface, Microsoft Middleware will be firmly (and unchallengeably) established in the plumbing of each PC.

Sections III(H)(1)-(2)[second], undo what might be left of the obligations earlier in Section III(H). Section III(H)(1)[second] permits Microsoft to ensure that Microsoft Middleware Products are invoked whenever an end-user is prompted to use Microsoft Passport or the group of Microsoft web services now known as Hailstorm. Section III(H)(2)[second] ensures that Microsoft need only program in functions that invoke Active X or other similar Microsoft-proprietary implementations of common functions, in order to ensure that Microsoft Middleware Products constantly appear regardless of an end-user's stated preferences. And none of the provisions in Section III(H) would apply unless the corresponding Microsoft Middleware Products existed seven months before the last beta version of a new Windows release. As with other provisions, Microsoft would be constrained by these requirements only if it paid no attention to them when it decided when and how to release its products.

1. 4. • The 14-Day Sweep Provision Effectively Nullifies RPFJ § III(H)

Even if these provisions otherwise might mean something, the RPFJ ensures that they will be competitively meaningless by permitting Microsoft to nag users to give permission for Microsoft to override any array of non-Microsoft Icons and menu entries 14 days after the initial boot-up of a PC. See RPFJ § III(H)(3). Thus, Microsoft only needs to prompt users with a dialog box inviting them to "optimize the Windows user interface" every time they boot up, or when they download the inevitable bug fixes and security patches among Windows updates, in order to undo any OEM's or end-user's customization of icons. Microsoft apparently provided DOJ with the name for this feature, which DOJ uses in the CIS: "Clean Desktop Wizard." CIS 48, 66 Fed. Reg. 59,471. What user would not agree to have a cleaner desktop? No ISV is likely to pay an OEM a fee sufficient to cover the trouble of rearranging icons, and supporting additional software, for the privilege of having non-Microsoft software icons displayed advantageously for as little as two weeks.

The CIS suggests that the ability of Microsoft to sweep away icons of competing middleware and other products 14 days after a computer first boots up (RPFJ § III(H)(3)) applies only to "unused icons" (CIS 48, 66 Fed. Reg. 59,471), but the decree terms contain no such limitation. Once its "Clean Desktop Wizard" (id.) secures a click of user consent, Microsoft can hide any icons that offend it. Indeed, there is nothing in the RPFJ that would stop Microsoft from including similar "wizards" that would prompt users to reset middleware defaults, or even to remove Non-Microsoft Middleware," in order to "optimize performance" or to "take full advantage of powerful new Windows features."

1. 5. • By Placing The Burden To Restore Competition On OEMs, The PFJ Leads To No Remedy At All For Much Of The Misconduct At Issue

One of the most misguided elements of the RPFJ is its allocation to OEMs, ISVs and end-users of the primary responsibility for injecting competition into the OS market. The icon and default flexibility provisions of the RPFJ allocate to the OEMs almost all of the financial risk and responsibility for remediating Microsoft's antitrust violation, while the monopolist has no obligations except to allow others to make changes to hide (or add to) Microsoft's middleware. That approach ignores the fact that OEMs are motivated by their own fiduciary and economic considerations, not by the drive to remedy a monopolization offense. OEMs are risk-averse, as they operate in a low-margin, highly competitive environment in what has become a commodity-product market. In that environment OEMs are highly dependent on the good graces of Microsoft, not only for favorable pricing on Microsoft's monopoly software products Office as well as Windows but also for timely technical assistance, and access to technical information.

The Stiglitz/Furman Declaration confirms (at 32-34) that the economics of the OEM industry -- a commodity industry captive to a bottleneck monopolist -- discourage expenditures of this kind. It is bizarre and counterproductive to place the burden to restore competition on the innocent, low-margin OEMs rather than the monopolist. The "hapless makers of PCs" still "aren't in any position to defy Microsoft," Walter Mossberg, For Microsoft, 2001 Was A Good Year, But At Consumers' Expense, Wall. St. J., Dec. 27, 2001, at B1, any more than they were when the illegal conduct in this case first occurred. See, e.g., Findings, 84 F. Supp.2d at 62 (¶ 214) (Hewlett-Packard observation to Microsoft that "[I]f we had a choice of another supplier, * * * I assure you [that you] would not be our supplier of choice"). But if OEMs choose not to exercise their new "flexibility" under the middleware provision a choice that seems likely in view of the demonstrated lack of a response to Microsoft's offer of July 11, 2001 the government is left with no antitrust remedy for much of its case.⁽¹²⁾

Nor can ISVs be expected to pay OEMs to take advantage of the limited flexibility provided by RPFJ §§ III(C) and III(H). The RPFJ gives ISVs very slight incentives to subsidize OEM alterations of Microsoft's preferred desktop display, since the ISVs who sell middleware that competes against a Microsoft offering cannot buy exclusivity on the desktop of any computer. Rather, at best an ISV can obtain parity in the availability to developers of its middleware's code. No matter what ISVs and OEMs do, Microsoft Middleware will be ubiquitous. And ISVs could buy only 14 days of advantageous icon display before a Microsoft "Clean Desktop Wizard" (CIS 48, 66 Fed. Reg. 59,471) would begin prompting users to undo the OEM's arrangement of icons and reinstate the arrangement favored by Microsoft. No ISV would pay more than a pittance for such a shallow and short-lived advantage on the desktop.

1. 6. • The RPFJ Permits Microsoft To Control Consumers' Access To Innovation To Suit Its Monopolistic Aims

The RPFJ allows Microsoft to exercise full control over the pace of innovation in middleware because Microsoft can ensure that consumers are denied access -- or have only severely impeded access -- to competitively threatening middleware products to which Microsoft has no analogue. Section III(C)(3) allows Microsoft to prohibit OEMs from configuring PCs to launch non-Microsoft middleware from any point unless Microsoft already has a competing product that launches from that point. Microsoft can prohibit OEMs from configuring non-Microsoft middleware from launching automatically at the end of the boot sequence or upon the opening or closing of an Internet connection unless a Microsoft Middleware Product with similar functionality would launch automatically. RPFJ § III(C)(3).

Even after this catch-up provision serves its delaying purpose, Microsoft can control how competing middleware products reach and serve consumers, so that products launch only in the way that best suits Microsoft. This provision appears designed to protect Microsoft from competition, and to give the monopolist a clear imprimatur to control the pace of innovation. See Stiglitz/Furman Dec. 28.

5. • THE API AND COMMUNICATIONS PROTOCOL DISCLOSURE PROVISIONS ARE INEFFECTIVE

1. 1. • The API Provisions Require Little, If Anything, Beyond Current Disclosure Practices In Microsoft's Self-Interest

The API and Communications Protocol disclosure provisions (§§ III(D)-(E)) contain little in the way of hard, fast, enforceable obligations, and do not appear to add anything significant to Microsoft's current disclosure practices. As the CIS recognizes:

CIS 34, 66 Fed. Reg. 59,468.

Microsoft already discloses literally thousands of APIs to software developers through MSDN for the good reason that it is in Microsoft's self-interest to promote the Microsoft Windows platform to software developers. The extent of information disclosure required by the RPFJ must be understood in the context of Microsoft's current information disclosure practices. A "requirement" that Microsoft disclose APIs for the most part simply "requires" that Microsoft do what it does voluntarily.

Microsoft has a business incentive not only to disseminate Windows APIs but to assist ISVs in understanding and implementing Windows APIs in their products. Microsoft and other platform software vendors compete to attract developers by disclosing technical information, creating easy-to-use development tools, and "evangelizing" their development platforms. Attracting developers helps Microsoft perpetuate the substantial network effects that produce the applications barrier to entry protecting the Windows monopoly. Because the strength of the Windows monopoly and the power of the applications barrier to entry are directly related to the number of developers writing applications for Windows, it is in Microsoft's interest to provide a robust information disclosure program.

By widely disclosing APIs, Microsoft ensures that applications will continue to be written for its platform software rather than for rival platforms. Properly understood, Section III(D) does not actually require Microsoft to provide any new disclosure of APIs and technical information to promote interoperability; Microsoft already engages in these disclosures. Rather, the incremental effect of the API disclosure provisions of the RPFJ is at most to prevent Microsoft from selectively withholding certain APIs from certain vendors. As explained below, however, the disclosure "requirements" in the RPFJ are too insubstantial and too easily manipulated to accomplish even that limited goal.

1. 2. • The RPFJ Does Not Require Disclosure of Windows APIs, But Rather Lets Microsoft Determine The Scope of Disclosure Through The Design and Labeling of Its Operating System And Middleware

To begin with, the API disclosure requirements aim at the wrong thing. The RPFJ defines APIs as the interfaces used by Microsoft Middleware to invoke resources from a Windows Operating System Product. RPFJ § VI(A). But innovative rival software vendors do not need APIs between Microsoft Middleware and Windows. The really threatening innovators are threatening precisely because their products perform functions that Microsoft's do not. In those cases, by definition, there will not be any fully analogous Microsoft middleware -- just as Microsoft did not have an Internet browser when Netscape Navigator first appeared. Those developers need full access to Windows APIs -- APIs for all functionalities enabled by the Windows platform, whether Microsoft calls them "internal" calls within Windows or external APIs that may be distributed to ISVs -- not to the limited subset used by a Microsoft version of similar middleware.

That is what Netscape needed in 1995; there was no Internet Explorer to speak of at that time, and certainly Microsoft's rudimentary browser did not perform anywhere near the range of functions performed by Netscape Navigator. See Findings, 84 F. Supp.2d at 31-32 (¶¶ 82-84), 33-34 (¶¶ 91-92). The RPFJ provisions would not have helped Netscape then. See Letter from James L. Barksdale, former CEO of Netscape, to Chmn. Leahy & Sen. Hatch, Senate Comm. on the Judiciary, Attachment, Question 1 (Dec. 11, 2001).⁽¹³⁾ And they will not help any software developer whose products exceed the functionality of existing Microsoft middleware. The API disclosure provisions in the RPFJ thus ensure that Microsoft can control the pace of middleware innovation, providing another level of assurance that non-Microsoft products will not gain the type of head start that might result in ubiquity before a similar Microsoft product can be included in the bundle of products sold with every Windows operating system.

That limitation on API disclosure is severe enough. But it is just a beginning. The disclosure obligation is further limited by the definition of APIs at RPFJ § VI(A):

• "Application Programming Interfaces (APIs)" means the interfaces, including any associated callback interfaces, that Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product.

Setting aside the circularity, the malleability of the two principal defined terms renders this definition (and the corresponding obligations) a practical nullity. The API definition depends on the relationship between two "products," each of which is defined solely by Microsoft. As noted above, Microsoft has "sole discretion" to identify software code as part of a "Windows Operating System Product." RPFJ § VI(U). Many APIs can disappear from view simply as a result of Microsoft's unreviewable decision to relabel certain interfaces as internal to Windows. If Microsoft says that an operation takes place entirely within Windows, rather than requiring the interaction of a middleware and Windows, then there is no API to disclose.⁽¹⁴⁾

1. 3. • The Definition of "Microsoft Middleware" Gives Microsoft Further Leeway to Limit Its Disclosure Obligation

The only APIs that need be disclosed are those used by "Microsoft Middleware." But "Microsoft Middleware," too, is defined in a way that gives Microsoft tight control over the scope of its own obligations. Remarkably, Assistant Attorney General James testified that this definition would have been difficult for DOJ to achieve in a litigated proceeding. Statement of Charles James to Senate Judiciary Committee 8 (Dec. 12, 2001). But it is difficult to imagine what Microsoft would have contested. Just as in the dispute whether Internet Explorer is part of Windows, Microsoft can simply relabel software as part of one product rather than another. The label does not affect the commands and operations in the software.

1. 1. 1. • The RPFJ Requires Microsoft To Disclose Only The APIs Used By The "User Interface" Or Shell Of Microsoft Middleware

The APIs that must be disclosed are those that "Microsoft Middleware * * * uses to call upon [a] Windows Operating System Product." RPFJ § VI(A); see id. § III(D). But Microsoft determines how much code performing a Microsoft Middleware function is part of the Middleware, and how much is part of the Windows Operating System Product, since the latter definition is within Microsoft's "sole discretion." Id. § VI(U). The only code in Microsoft Middleware that Microsoft must consider separate for the purposes of API disclosure is the user interface, or shell, of the Middleware -- or, rather, "most" of the shell. Id. § VI(J)(4). The only limit is that "Microsoft Middleware" must "[i]nclude at least the software code that controls most or all of the user interface elements of that Microsoft Middleware." Id. Thus, the terms of the RPFJ permit Microsoft to provide only the APIs that go between 51% of the user interface elements of Microsoft Middleware and the rest of the Windows bundle of products. None of the APIs used by the Middleware's functionality -- the APIs that permit the Middleware perform its functions while running on Windows -- need be disclosed, so long as the shell APIs are disclosed. This definition appears to be designed to have nothing to do with developer preferences, or with the applications barrier to entry.

1. 1. 2. • The RPFJ Requires Microsoft To Disclose APIs Only For "Microsoft Middleware" That Is Distributed Separately From Windows, Yet Is Distributed To Update Windows

To come within the disclosure obligation, Microsoft Middleware must be "distributed separately from a Windows Operating System Product." That restriction alone is enough to take Windows Media Player 8 outside the definition, as that product is available only as part of the Windows XP bundle. But not all separate distributions prompt the API obligations; Microsoft must characterize the distribution as one that "update[s] th[e] Windows Operating System Product." See RPFJ § VI(J)(1). Thus, the scope of the obligation depends entirely on the labeling of the product, which Microsoft can easily manipulate.

1. 1. 3. • The Limitation Of Microsoft Middleware To "Trademarked" Products Further Eviscerates The API Disclosure Provision

But that is not all. At least equally significant is the restriction of the Microsoft Middleware definition, and thus the API disclosure obligation, to Middleware that is "Trademarked." RPFJ § VI(J)(2). The definition of "Trademarked" allows Microsoft to exclude current middleware from the API disclosure obligation, and to prevent future middleware from becoming subject to the API disclosure obligation, simply by manipulating its use of trademarks.

1. 1. 1. 1. Microsoft Easily Can Ensure That Middleware Is Not "Trademarked" By Using A Generic Or Descriptive Name Combined With Microsoft® or Windows®

The definition of "Trademarked" does not include "[a]ny product distributed under * * * a name compris[ing] the Microsoft® or Windows® trademarks together with descriptive or generic terms." Id. § VI(T). That is how Microsoft has chosen to name some of its newest and most important products: the combination of a monopoly brand with a simple descriptive mark that helps identify an entire software function with the Microsoft Implementation of it. Windows® Messenger instant messaging software is one example.

Moreover, by the terms of the RPFJ Microsoft disclaims any rights in the use of such combinations of the Microsoft® or Windows® marks with generic or descriptive terms, and abandons any rights that may be acquired in the future. RPFJ § VI(T). These provisions suggest that Microsoft can change the scope of the definition of Middleware, and thus of the API disclosure obligation, by abandoning some marks it has registered as combinations of Microsoft® or Windows® with generic or descriptive terms -- if the RPFJ does not accomplish that in itself. Windows Media Player is an example. Although Microsoft has registered the combination of Windows® and the generic term "Media" as Windows Media®, at bottom the name Windows Media Player is a combination of the Windows® mark with the generic term "media player."

Indeed, Microsoft could plausibly argue that the Windows Media® mark does not come within the "Trademarked" definition as it is, since even that mark consists of no more than the Windows® mark in combination with the generic term "media."⁽¹⁵⁾ RPFJ § VI(T) may therefore embody Microsoft's "disclaim[er of] any trademark rights in such descriptive or generic terms apart from the Microsoft® or Windows® trademarks." But even if Section VI(T) does not go so far, Microsoft could easily get Windows Media® Player outside of the "Trademarked" definition -- and thus outside the scope of the disclosure obligations that apply only to "Microsoft Middleware" -- simply by abandoning the registration mark and moving the registration symbol to the left. Thus, Microsoft can transform "Windows Media® Player," which might be subject to API disclosure requirements, into "Windows® Media Player," which clearly is exempt.

1. 1. 1. 2. The "Microsoft Middleware" Definition Governing Disclosure Obligations Is Far Narrower Than The "Microsoft Middleware Product" Definition Governing OEM Flexibility

That this highly restrictive definition is no accident is clear from comparison with the "Microsoft Middleware Product" definition which governs the icon-display obligations. To provisions paralleling the "Microsoft Middleware" definition, the "Microsoft Middleware Product" definition adds several named current products, including "Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express and their successors," RPFJ § VI(K)(1), although only to the extent that Microsoft "in its sole discretion" (id. § VI(U)) decides that those products are "in a Windows Operating System Product." Id. § VI(K)(1). Thus, Microsoft's icon display/removal obligations for those named products would not change merely because of a strategic product renaming or abandonment of a trademark that combines the Microsoft® or Windows® name with generic or descriptive terms. But none of those current products is named in the "Microsoft Middleware" definition that governs the disclosure obligations. That enables Microsoft to manipulate whether those products, although surely middleware, also satisfy the four subparts of RPFJ § VI(J).

1. 1. 1. 3. The CIS Broadens The "Trademarked" Definition Beyond Its Terms

The CIS overstates the breadth of the "Trademarked" definition, contending that it "covers products distributed * * * under distinctive names or logos other than by the Microsoft® or Windows® names by themselves." CIS 22, 66 Fed. Reg. 59,465. The CIS further claims that the exception for products known by combinations of generic terms with Microsoft® or Windows® does not cover marks that "are presented as a part of a distinctive logo or another stylized presentation because the mark itself would not be either generic or descriptive." CIS 23, 66 Fed. Reg. 59,465 (emphasis added). To the contrary, the terms of the RPFJ definition of "Trademarked" focus entirely on "names," not "logos" or "marks" as a whole. RPFJ § VI(T). The distinction is striking: the word "name" appears five times in the definition, and "descriptive or generic terms" appears three times. Neither "logo" nor "mark" appears at all.

Microsoft clearly appreciates the distinction. Although Microsoft apparently has not yet formally abandoned the mark "Internet Explorer" (U.S. Trademark Reg. No. 2277122), it does not assert that mark when it lists its trademarks as a warning to the public. See http://www.microsoft.com/misc/info/cpyright.htm. Microsoft does list its trademark for the Microsoft Internet Explorer logo, however. Id.; see U.S. Trademark Reg. No. 2470273.

1. 1. 1. 4. Microsoft Can Easily Manipulate Which Middleware Releases Are "New Major Versions"

Indeed, even a "Microsoft Middleware Product" satisfying that four-part test may not be "Microsoft Middleware" subject to the disclosure obligation unless it is a "new major version" of the product, that is, if the release is "identified by a whole number or by a number with just a single digit to the right of the decimal point." RPFJ § VI(J). That has two implications. First, Microsoft can simply adopt a different method of naming new releases. Second, even under current practice a version with two digits to the right of the decimal point may fix significant errors, so that disclosure only of the prior version of the APIs might leave developers without the ability to invoke some needed functionality with the disclosed APIs.

1. 4. • The Disclosure Provisions -- Particularly Those Concerning "Communications Protocols" -- Depend On An Undefined And Thus Unenforceable Concept of "Interoperability"

Both the API and Communications Protocol disclosure provisions define the scope of the data to be disclosed as that necessary to permit non-Microsoft products to "interoperate" with the Windows client OS and to "interoperate natively" with Microsoft server operating system products. See RPFJ §§ III(D), (E). The disclosure obligations are limited to "the sole purpose of interoperating with a Windows Operating System Product." Id.

The obligations depend on the meaning of "interoperate," but the RPFJ never defines that term, and there is no non-discrimination provision attached to this obligation. That is critical because interoperability is not something that can be achieved half way. Either two software products interoperate for all functions that they must perform together, or they do not. Any impediment in any aspect of the interoperation nullifies the interoperability. The CIS seems to equate "interoperate" with "fully take advantage of," see CIS 36, 66 Fed. Reg. 59,468, but there is no such language in the RPFJ itself.

The Communications Protocol disclosure provision (RPFJ § III(E)) outlines a seeming "obligation" that is entirely undefined. Section III(E) seems to require disclosure of Communications Protocols on Windows clients that are "used to interoperate natively * * * with a Microsoft server operating system product." But just as "interoperate" is not defined, neither does the RPFJ define "Microsoft server operating system product."

One of the most important aspects of the Windows 2000 Server product bundle is Microsoft's web server, IIS. In the absence of a definition of "Microsoft server operating system product," however, it is unclear whether the disclosure obligation encompasses protocols used to interoperate with this and other aspects of the current server product. Cf. RPFJ § VI(U) (defining "Windows Operating System Product" as all software code "distributed commercially * * * as Windows 2000 Professional" and other named products, and "Personal Computer versions" of their successors).

Again, the CIS attempts to provide assurances that go beyond the terms of the proposed judgment. The CIS states (at 37, 66 Fed. Reg. 59469):

That definition would be appropriate. But no corresponding language -- no enforceable definition -- appears in the RPFJ.

1. 5. • The Narrow Scope Of The Disclosure Provisions Contrasts Sharply With The Broader Definitions In DOJ's Earlier Remedy Proposals

Before liability had been confirmed on appeal, DOJ took a far broader view of what should be disclosed. The interim remedies in the vacated judgment required disclosure of APIs, Communications Interfaces, and "technical information" needed to enable competing products "to interoperate effectively with Microsoft Platform Software." 97 F. Supp.2d at 67 (§ 3(b)). That disclosure requirement was backed up by a requirement, absent from the RPFJ, that Microsoft create a secure facility so that developers could work with Windows source code to ensure that their applications worked properly on the Microsoft platform. See id.

The definition of "technical information," moreover, helped ensure that disclosure would be complete and not subject to many different methods of manipulative narrowing. The "technical information" definition encompassed the following items:

97 F. Supp.2d at 73 (§ 7(dd)).

Indeed, DOJ's position was stronger even before liability had been imposed at all. Draft 18 from the Posner mediation imposed a disclosure obligation using this definition of "technical information":

The RPFJ, by contrast, contains no analogue to these precise and inclusive definitions. Instead, the RPFJ relies solely on the circular (and completely manipulable) definition of API (RPFJ § VI(A)), a similarly narrow definition of "Communications Protocol" (id. § VI(B)), and a definition of "Documentation" that is wholly dependent on the API definition (id. § VI(E)).

1. 6. • The "Security" Exceptions in Section III(J) Permit Microsoft To Avoid Its Disclosure Obligations

RPFJ § III(J) provides Microsoft with two additional lines of defense in the event that any competitively sensitive APIs nonetheless fall within the malleable definition of API. Section III(J)(1) severely undercuts the disclosure requirements to the extent they apply in the modern world where security protocols are critical to any communication between networked computers, particularly over the Internet. And Section III(J)(2) provides Microsoft with seemingly unfettered discretion to decide who is worthy to receive technical information necessary to make middleware function on the Internet.

Microsoft can plausibly rely on Section III(J) to decline to comply with disclosure requests based on concerns with authentication and security that it will be able to assert with respect to any program that involves communication between a PC and a server on the Internet (or even within many private networks). Authentication, security, and similar protection mechanisms are and will continue to be integral parts of the functioning of those products. See, e.g., Comment, William A. Hodkowski, The Future of Internet Security: How New Technologies Will Shape the Internet and Affect the Law, 13 SANTA CLARA COMPUTER & HIGH TECH. L.J. 217 (1997). Indeed, security and rights-protection are particularly critical to Internet-based economic activity, which encompasses much of the computing on the Internet. As a consequence, the security mechanisms are critically important to any Internet-based middleware threat to the Windows OS monopoly.

For example, digital rights management ("DRM") has become a principal part of Windows Media Player. Allowing Microsoft to withhold data needed to permit rivals to interoperate with the DRM specifications in Windows Media Player -- specifications that Microsoft Is making universal by including Windows Media Player on every PC -- may well end effective competition for media players within the next upgrade cycle for Windows. Similarly, any distant remaining possibility of Internet browser (or even e-mail client) competition should be squelched by the RPFJ's approval for Microsoft to withhold parts of encryption-related protocols (again, as distinct from the customer-specific keys that make use of those protocols). For another example, Secure Socket Layer (SSL) is an open standard that has been critical to the open development of a relatively secure Internet. As Microsoft Implements a proprietary version of SSL -- one that others will have to follow given the ubiquity of the Microsoft browser as a result of the misconduct at issue in this case -- it will be able to conceal critical layers of that altered protocol from rivals, essentially ending the possibility of competition for client software for Internet computing. And by giving Microsoft a basis to conceal authentication protocols (not merely data), the RPFJ frees Microsoft Passport from scrutiny and permits Microsoft to bind a proprietary universal password and identity utility to its monopoly operating system without hope of interoperation.

By permitting Microsoft to withhold key parts of encryption, digital rights management, authentication, and other security protocols, the RPFJ effectively allocates Web-based computing to the monopolist of the desktop. A decree could hardly try to place a clearer stamp of approval on an expansion of the scope of an illegally maintained monopoly.

1. 1. 1. • The Exclusions for Security-Related APIs and Protocols in RPFJ(J)(1) Permit Microsoft To Hobble Disclosures That Are Critical in Internet Computing

It is no coincidence that Bill Gates has now emphasized the centrality of security concerns in Microsoft's future software offerings. See, e.g., John Markoff, Stung by Security Flaws, Microsoft Makes Software Safety a Top Goal, N.Y. TIMES, Jan. 17, 2002, at C1. That is no more than an acknowledgment of market and technical realities that have been widely known throughout the industry for years as Internet computing has taken hold. That market reality should have been sufficient to make clear that an indistinct exception of the type in RPFJ § III(J)(1) would allow Microsoft to disclose "crippled" versions of APIs and Communications Protocols. Microsoft's sudden dedication to security leaves no doubt that it will inject security aspects into its proprietary APIs and its proprietary, extended implementations of Communication Protocols. Under the terms of Section III(J)(1), Microsoft can easily argue that disclosure of those aspects -- necessary for one machine to communicate with another -- will compromise the security from any installation or group of installations. See also Stiglitz/Furman Dec. 30.

The CIS maintains that Section III(J)(1) simply protects Microsoft and its customers from disclosure of customer-specific "keys, authorization tokens, or enforcement criteria," and states that the exception "does not permit [Microsoft] to withhold any capabilities that are inherent in the Kerberos and Secure Audio Path features as they are implemented in a Windows Operating System Product." CIS 52, 66 Fed. Reg. 59,472. But that reading does not square with the text of the exemption. The quoted examples are specifically presented "without limitation." RPFJ § III(J)(1). The RPFJ language easily permits Microsoft to contend that any release of the way its proprietary security protocols work "would compromise the security of a particular installation." Most important, Section III(J)(1) clearly permits Microsoft to withhold portions of APIs or Communications Protocols, but the examples given of keys and authorization codes are not parts of APIs or Communications Protocols. They may be part of customer-specific Documentation, rather than the Documentation used by customers, consultants, and developers to create or identify and implement particular keys, tokens, or enforcement criteria.) The APIs and Communications Protocols for security-related applications are not customer-specific, nor does their disclosure compromise security. To the contrary, the most powerful encryption and other security-related software is openly disclosed, as is the Kerberos standard, or even open source, as is the federal government's new encryption standard. See, e.g., Watch your AES: A new encryption standard is emerging, Red Herring (Dec. 1, 1999) (open source government standard).

Unless RPFJ § III(J)(1) refers to a null set, however, Microsoft will have a basis to withhold some parts of Communications Protocols and APIs. The CIS states that Communications Protocols "must be made available for third parties to license at all layers of the communications stack," (CIS 36-37, 66 Fed. Reg. 59,468 (emphasis added)) but the RPFJ to which Microsoft agreed -- and which alone is potentially enforceable -- says no such thing. To the contrary, Section III(J)(1) explicitly relieves Microsoft from the obligation to license some "portions or layers of Communications Protocols" (and some "[p]ortions of APIs") -- not just client-specific data. If part of a Communications Protocol is withheld, not "all layers of the communications stack" are "available * * * to license." And if part of a Communications Protocol is unavailable, interoperation is impossible; at certain points, the interaction between two computers will break down.

Limited withholding of APIs or Communications Protocols (rather than merely withholding customer-specific data) will render middleware non-functional, since software cannot interoperate with other software partially. Carving off some aspects of interoperability means that there is no interoperability, thwarting the premise of the disclosure provisions altogether.

The CIS also describes other limits that do not exist in the text of the RPFJ. The CIS claims that the RPFJ requires disclosure of the Communications Protocols used for the Microsoft-proprietary implementation of the Kerberos security standard -- a "polluted" Kerberos that is the strict analogue to the "pollute[d]" Java that figured prominently at trial. See Microsoft III, 253 F.3d at 76-77 (quoting 22 J.A. 14,514). But Section III(J) explicitly relieves Microsoft of the obligation to disclose "portions" of APIs or Communications Protocols that would "compromise the security of a particular installation or group of installations of" security software. That is an open invitation to withhold some part of the Microsoft-proprietary variation of Kerberos.

The type of customer-specific information that the CIS claims is all that can be withheld could and should be described much more accurately and specifically in the RPFJ, not as [p]ortions of APIs or * * * portions or layers of Communications Protocols," but rather as "customer-specific or installation-specific data the disclosure of which would compromise the security of a particular installation or group of installations of anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems, including without limitation keys, authorization tokens or enforcement criteria." But that is not the approach the RPFJ takes. Rather, the RPFJ makes clear that Microsoft Is entitled to withhold, not merely customer- or installation- specific data, but some "portions" of APIs and some "portions or layers" of Communications Protocols. All communication of substance between desktops (or other client computers) and server computers over the Internet increasingly involves layers of security protocols, anti-virus routines, and the like. And one of Microsoft's principal current efforts is to foist its own version of digital rights management (DRM) upon providers of copyrighted content over the Internet.

When Microsoft asserts a right to withhold information, it will be difficult indeed for the Technical Committee, DOJ, or the Court to exclude the possibility that particular "portions or layers of Communications Protocols," or "[p]ortions" of the APIs that permit middleware programs to operate atop Microsoft operating systems, in fact "compromise the security of a particular installation or group of installations." RPFJ § III(J)(1). Any such determination is likely to be time-consuming, and related enforcement therefore would be slow. It should be a simple matter for Microsoft to delay disclosures of this type long enough to disadvantage competitors.

1. 1. 2. • RPFJ III(J)(2) Permits Microsoft To Refuse Effective Disclosure To A Range Of Potentially Effective Competitors

While RPFJ § III(J)(1) allows Microsoft to refuse to disclose portions of APIs, RPFJ § III(J)(2) permits Microsoft to withhold all of any "API, Documentation, or Communications Protocol" having to do with "anti-piracy systems, anti-virus technologies, license enforcement mechanisms, authentication/authorization security, or third party intellectual property protection mechanisms of any Microsoft product." The RPFJ allows Microsoft to select to whom it will disclose this information by imposing several tests that may be based on standards apparently committed to Microsoft's sole discretion as much as is the definition of Windows Operating System Product.

Thus, RPFJ § III(J)(2)(b) permits Microsoft to evaluate whether a competitor has a "reasonable business need" for the desired information. What Microsoft Is likely to consider a "reasonable" business need by a competitor may be narrow indeed. As the D.C. Circuit observed, Microsoft viewed its desire "to preserve its" monopoly "power in the operating system market" as a procompetitive justification for exclusionary conduct. Microsoft III, 253 F.3d at 71. No doubt Microsoft will view direct or indirect efforts to undermine its hammerlock on the OS market as unreasonable efforts to confuse consumers or impair the "Windows experience."

Even bona fide attempts by a monopolist to objectively evaluate a potential competitor's "reasonable business need" can scarcely be expected to produce consistent or foreseeable results. Rather, that amorphous standard is likely to produce a flood of disputes -- each of which will delay the competitor's receipt of technical information while Microsoft gains more time to respond (by legal or illegal means) to the competitive threat. Moreover, the "reasonable business need" must be for a "planned or shipping product." If the product is already "shipping," it may be too late for disclosure to be helpful in the market. How fully "planned" a product must be raises further questions that Microsoft will be able to resolve to its own disadvantage.

In addition, Microsoft need not provide security-related APIs, protocols, or documentation to any vendor that does not "meet[] reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business." RPFJ § III(J)(2)(c) (emphasis added). That provides Microsoft with a basis for excluding almost all nascent competitors except for those associated with established, profitable companies. It would not be difficult to craft "reasonable, objective standards" for "viability of [a] business" that would exclude any Internet-focused startup, including Netscape in 1995. Indeed, the history of the software industry both before and after the dot-com bubble shows that very few software companies have had "viable" businesses. Certainly Section III(J)(2)(c) would give Microsoft at least a debatable basis for withholding the APIs and Communications Protocols needed to interoperate with Microsoft software over the Internet from all open source ISVs -- who are more interested in constantly improving the quality of software than in obtaining licensing profits. Although open source software is widely recognized as a major threat to Microsoft's monopoly power, the business models even of the leading Linux providers might fail any number of "reasonable, objective standards" for "viability." Indeed, Microsoft's CEO Steve Ballmer describes open source software as a "cancer" that threatens the viability of any software business. See Mark Boslet, Open Source: Microsoft Takes Heat, INDUSTRY STANDARD, July 30, 2001; Dave Newbart, Microsoft CEO Takes Launch Break with the Sun-Times, CHI. SUN-TIMES, June 1, 2001, at 57. For that matter, it is not entirely unreasonable to regard head-to-head competition with Microsoft In platform software as a less than viable business plan; certainly most venture capitalist and other investors hold that view. It would not be difficult for Microsoft to craft "objective" standards of business viability that would exclude Corel and Novell, to name two examples. Microsoft should be able to exclude many sources of potential cross-platform middleware threats through RPFJ § III(J)(2)(c) alone.

Yet RPFJ § III(J)(2) contains yet another method for screening competitors from access to technical information needed by Internet-centric middleware applications. Any ISV that clears the hurdles and receives the information nonetheless must submit its implementation of the APIs, Documentation or Communications Protocols for review by a Microsoft-approved third party (likely a captive commercial ally) "to test for and ensure verification and compliance with Microsoft specifications for use of the API or interface, which specifications shall be related to proper operation and integrity of the systems and mechanisms identified in this paragraph." RPFJ § III(J)(2)(d). "[P]roper" no doubt will mean "the way Microsoft does it," making this provision into yet another way in which Microsoft can control the pace of innovation to ensure that the market has no or limited access to products that improve upon Microsoft's offerings. This mechanism means that vendors who tried to adapt APIs to function as bridges to other platforms would have to give Microsoft the ammunition to defeat that function -- if not simply disapprove it and await the slow operation, if any, of the RPFJ enforcement mechanism.

The CIS suggests that there are strict limits on Microsoft's discretionary ability to deny access to security-related aspects of Communications Protocols and APIs, CIS 53, 66 Fed. Reg. 59,473, but those limits are absent from the decree language. The CIS contends that these exceptions "are limited to the narrowest scope of what is necessary and reasonable, and are focused on screening out individuals or firms that * * * have a history of engaging in unlawful conduct related to computer software * * *, do not have any legitimate basis for needing the information, or are using the information in a way that threatens the proper operation and integrity of the systems and mechanisms to which they relate." Id. Setting aside the opportunity for Microsoft to argue, as it has in other contexts, that the injection of competing software "threatens the proper operation and integrity" of its products, see Microsoft III, 253 F.3d at 63-64, the CIS simply does not address the broadest basis for withholding APIs and Communications Protocols under Section III(J)(2): Microsoft's ability to decide, based on criteria within its own discretion, that an ISV is not "authentic[]" and "viab[le]." RPFJ § III(J)(2). That provision could provide a basis for excluding all but a handful of other software companies.

1. 7. • RPFJ § III(I) Would Place A Judicial Imprimatur On Microsoft's Use Of Technical Information As A Lever To Extract Competitors' Intellectual Property

The RPFJ would actually increase Microsoft's bargaining power by explicitly placing a judicial imprimatur on demands by Microsoft that recipients of APIs crosslicense any intellectual property developed using the APIs. Section III(I) of the RPFJ permits Microsoft to use intellectual property licensing terms to impede whatever competitive benefits otherwise might have arisen from its disclosure obligations. Microsoft's licenses "need be no broader than is necessary to ensure" the licensee's ability to "exercise the options or alternatives expressly provided" by the RPFJ. RPFJ § III(I)(2). A welter of litigation over the breadth that is "necessary" -- and the collateral restrictions that are permissible -- is certain to continue through the life of the decree.

Similarly, Microsoft should have no difficulty delaying the use of any option for which it is entitled to charge a royalty, simply by setting a "reasonable" royalty (RPFJ § III(I)(1)) beyond what any OEM could afford to pay in that competitive, low-margin business. If OEMs have to pay Microsoft to exercise any of their icon-shuffling options -- a state of affairs clearly envisioned in RPFJ § III(I) -- the slim likelihood that any OEM will take advantage of those provisions will be lessened still further. Microsoft need not permit transfers or sublicenses of API rights, imposing yet another barrier to entry. Id. § III(I)(3). And Microsoft could ensure, through licenses, that end-users could not make competitively significant alterations to the Microsoft-approved package.

Most important, however, the RPFJ specifically permits Microsoft to use its monopoly as a means to force access to others' intellectual property. Microsoft can assert a right to license "any intellectual property rights" a competitor "may have relating to the exercise of their options or alternatives provided by" the RPFJ. RPFJ § III(J)(5). Thus, to take advantage of a competitive option, an ISV will need to license its product to Microsoft, and hope that Microsoft does not use that license as a means to produce a copycat program and bundle it into Windows. Many companies long since departed the software industry after entering into what they thought were limited exchanges of intellectual property with Microsoft.⁽¹⁶⁾

Although the CIS states that Microsoft could demand only any IP rights it would need to comply with its own disclosure obligations under the RPFJ, CIS 50-51, 66 Fed. Reg. 59,472, the broad "relating to" language does not compel that narrow reading, and may not support it at all. The vague limitations in Section III(I)(5) are unlikely to reassure ISVs that Microsoft will not use its license to analyze the ISV's IP rights well enough to design around it and bundle a copycat program into Windows or Office, as has happened many times before. This weapon should give Microsoft additional ability to prevent industry participants from taking advantage of the superficially appealing provisions of the RPFJ.

6. • BUILT-IN DELAYS EXACERBATE THE DECREE'S UNJUSTIFIABLY BRIEF DURATION

It is remarkable that the RPFJ would reward Microsoft for litigating and losing broadly on liability with a consent decree that is shorter than other such decrees, and may be the shortest ever. DOJ antitrust consent decrees now routinely last ten years.⁽¹⁷⁾ Section V of the RPFJ provides for a term of only five years, however, less time even than Microsoft has engaged in the illegal conduct that was the subject of this litigation. The decree plainly should be longer than the period between the initiation of the misconduct and the imposition of relief, and at least as long as the typical relief.⁽¹⁸⁾ Microsoft has enjoyed the benefits of its misconduct for at least seven years. The RPFJ not only would allow Microsoft to retain those benefits, but would subject Microsoft to its light and uncertain obligations for no more than five years, and scarcely four and one-half years for the many obligations that are delayed.

The RPFJ further abbreviates its already brief duration, and undermines its already insubstantial requirements, by building in long delays before Microsoft must comply with its limited duties. Thus, Microsoft need not comply with the icon-related requirements until November 2002, see RPFJ § III(H)(1), although Microsoft needed only two weeks after the D.C. Circuit decision to offer OEMs roughly the same flexibility with icon display as the RPFJ requires, and needed no more than three additional months to implement that flexibility on Windows XP. See Microsoft Announces Greater OEM Flexibility for Windows (Microsoft press release July 11, 2001). Similarly, Microsoft need not comply with its API disclosure requirements or the OEM flexibility provisions until November 2002, RPFJ §§ III(D), (H), and need not comply with the Communica tions Protocol disclosure requirements until August 2002. Id. § III(E). See also Stiglitz/Furman Dec. 30. These built-in delays cut far into the unusually brief term of the decree.

The "Timely Manner" governing Microsoft's disclosure obligations in RPFJ §§ III(D)-(E) -- after the initial delay -- permits Microsoft to withhold that disclosure until a product version has been distributed to 150,000 beta testers. See RPFJ § VI(R). "Beta testers" in undefined. Until recently, Microsoft, like other vendors, distinguished between "beta testers" who agreed to provide substantial feedback to the software manufacturer, and "beta copies" of a program that might be distributed without such obligations or expectations. Few, if any, beta testing programs involved 150,000 beta testers under that usage. A return to the former terminology could postpone the "Timely Manner" until commercial release. And in any event, it should be a simple matter for Microsoft to delay distribution of any beta version to 150,000 testers, however defined.

Here again, the contrast with the interim remedies of the original decree is striking. The "Timely Manner" definition in that judgment required Microsoft to disclose "APIs, Technical Information and Communications Interfaces * * * at the earliest of the time that" those items were

• (1) disclosed to Microsoft's applications developers, (2) used by Microsoft's own Platform Software developers in software released by Microsoft In alpha, beta, release candidate, final or other form, (3) disclosed to any third party, or (4) within 90 days of a final release of a Windows Operating System Product, no less than 5 days after a material change is made between the most recent beta or release candidate version and the final release.

97 F. Supp.2d at 73-74 (§ 7(ff)) (emphasis added). While the vacated judgment made a strong effort to place outside developers on the same footing as Microsoft's applications developers throughout the development process, the RPFJ permits Microsoft to delay disclosure until the last minute, without any analogue to the requirement that Microsoft promptly update changes made in the final pre-release stage.

Another significant built-in delay results from the definition of "Non-Microsoft Middleware Product" to include only products that have one million users. RPFJ § VI(N) (ii). That definition governs the extent of the anti-retaliation provisions in RPFJ §§ III(A)(1), III(C), and III(H). Moreover, the icon flexibility and information disclosure provisions apply only to Microsoft Middleware and Microsoft Middleware Products, each of which must have functionality similar to a Non-Microsoft Middleware Product. See RPFJ §§ VI(J)(3), VI(K)(2)(b)(ii). By restricting all of these protections to middleware products that have distributed more than one million copies, the RPFJ encourages Microsoft to crush new middleware threats at the earliest stages. That is, the RPFJ puts a premium -- indeed, a judicial imprimatur -- on the monopolistic exclusion of nascent threats before the innovations in those products reach a sizable mass of consumers. That flies in the face of the concerns behind the judgments of liability in this case. See Microsoft III, 253 F.3d at 54, 79.

7. • ADDITIONAL WEAKNESSES UNDERCUT THE RPFJ

1. 1. • The Anti-Retaliation Provisions Are Deeply Flawed

Although anti-retaliation provisions are clearly necessary, the provisions in the RPFJ proceed from a misguided premise that retaliation by the monopolist -- abuse of monopoly power -- is permitted unless squarely forbidden. The well-meaning restrictions in the RPFJ leave Microsoft with ample recourse to use its monopoly power to retaliate against those who aid competitive threats. See Stiglitz/Furman Dec. 31-32.

Most important, the anti-retaliation provisions permit Microsoft to withdraw the Windows license of any OEM (or other licensee) that does not serve Microsoft's anticompetitive bidding. The CIS (at 27, 66 Fed. Reg. 59,466) suggests that the provision of RPFJ § III(A) requiring notice and opportunity to cure a violation provides some kind of protection to OEMs. But the protection is evanescent, disappearing entirely after two notices within a license term. See RPFJ § III(A). See also Stiglitz/Furman Dec. 31-32.

Such notices will become routine, quickly and completely nullifying this provision. In the rough-and-tumble of everyday business, parties frequently diverge in minor respects from the terms of their agreements. The CIS admits that "Windows license royalties and terms are inherently complex." CIS 28, 66 Fed. Reg. 59,466. Given that complexity, it would be surprising if most OEMs did not transgress some term of their Windows licensing agreements every year or so, if not more often. Such transgressions would provide ample basis for Microsoft to retaliate without fear of interference from the RPFJ.

There is no limit on what Microsoft can invoke as a reason for termination, that is, there is no requirement that terminations be for cause, much less for a material breach of the license agreement. Indeed, the sudden termination that Microsoft may impose after two notices -- even notices of purported violations that were promptly and completely cured -- need not even be based on something the OEM could cure.

The anti-retaliation provisions for software and hardware vendors contain another weakness. Section III(F)(1)(a) forbids retaliation against hardware and software vendors who support software that competes with Microsoft Platform Software or that runs on other platforms. But that provision therefore permits Microsoft to use its Windows monopoly to crush middleware vendors if Microsoft does not yet have competing middleware (see RPFJ §§ VI(K)-(L)) and whose middleware applications are used on the Windows platform -- where any middleware would have to start in order to be a practical bridge to another platform.

Moreover, when prohibiting a specific type of retaliation would also help undermine the applications barrier to entry, the RPFJ hews to a general approach rather than focusing on precise adjudicated conduct. For example, Microsoft threatened to discontinue its port of Microsoft Office for the Macintosh unless Apple ceased supporting Netscape Navigator. See Microsoft III, 253 F.3d at 73-74. Yet the RPFJ does not require Microsoft to continue to offer Mac Office (much less to keep the port current) -- an expedient that would take away Microsoft's weapon rather than merely admonishing it to behave well, and would tend to undermine the applications barrier to entry as well.

1. 2. • Microsoft Can Evade The Price Discrimination Restrictions

The uniform pricing provisions in RPFJ § III(B) have too narrow a reach to provide significant limits on Microsoft's ability to engage in price discrimination in order to force OEMs to eschew non-Microsoft products that may threaten Microsoft's OS monopoly. Microsoft's well-known market position in other products permits easy evasion of these limits. For example, nothing prevents Microsoft from discriminating in the pricing of its monopoly suite of desktop productivity applications, Microsoft Office, to which every OEM of any size needs access. Moreover, the leading PC OEMs all build server computers using Intel-based hardware, and increasingly rely on revenue from servers to make up for the exceptionally low margins on desktop PCs. To continue in the Intel-based server business, PC OEMs must license Microsoft's server operating systems, which are dominant on the Intel-based platform. The RPFJ places no limits on Microsoft's pricing of server operating systems, providing another outlet for the nullification of RPFJ § III(B).

Even on their own terms, however, the RPFJ pricing provisions contain a substantial loophole. Microsoft can reward an OEM for an "absolute level * * * of promotion" of Microsoft products. RPFJ § III(A). That provides a means for Microsoft to distinguish between OEMs who make sure that Microsoft software dominates their offerings, and OEMs who either promote competing software or simply do not interfere with consumers' choices.

1. 3. • Microsoft Can Enforce De Facto Exclusivity

Despite a superficial prohibition, Sections III(F)(2) and III(G) permit Microsoft to impose practical, effective exclusivity obligations on ISVs and others who need access to Windows to develop their products. Microsoft need do no more than recast its agreements with ISVs as contracts to "use, distribute, or promote * * * Microsoft software" or "to develop software for, or in conjunction with, Microsoft," RPFJ § III(F)(2), or as a "joint venture," joint development * * * arrangement" or "joint services arrangement." id. § III(G). New "joint development agreements" or "joint services arrangements" likely will supersede the current licenses for use by ISVs of Microsoft software developments tools and perhaps also the current arrangements for preferential access under MSDN. At best, a decree court would have to undertake a full antitrust analysis of whether the joint venture was "bona fide." id. § III(G). To nullify RPFJ § III(F)(2), Microsoft could simply change its development tools agreements to require use of Microsoft software -- which literally would be "a bona fide contractual obligation * * * to use * * * Microsoft software." Since any ISV that wants its software to run on Windows almost certainly would need to use Microsoft's development tools, the anti-exclusivity provision, like so many others in the RPFJ, would have no practical effect.

DOJ has defended this provision as necessary to permit legitimate "procom petitive collaborations." CIS 44, 66 Fed. Reg. 59,470. But the broad terms of the RPFJ itself provide little basis for hope that the objects of joint ventures permitting exclusivity will not include a variety of "new" products that amount to little more than routine alterations to Windows and other Microsoft products in conjunction with requests from other industry participants. It is not uncommon for an ISV to ask for a new API, or for an IHV to ask for some other specification in Windows. These exercises soon may become objects of "joint ventures" or "joint development agreements" under RPFJ § III(G).

RPFJ § III(G)(1) undercuts its superficial prohibition on contracts that would require participants at different levels of the market to install or promote Microsoft Platform Software to a "fixed percentage" of those participants' own customers. Section III(G)(1) permits Microsoft to impose such contracts so long as it "in good faith obtains a representation that it is commercially practicable for the entity to provide equal or greater distribution, promotion, use or support for software that competes with Microsoft Platform Software." Such representations should be easy to come by, so long as Microsoft pays enough. There is nothing to require a single party making such a representation actually to carry out the parallel distribution that it told Microsoft was "commercially practicable." And it should be easy enough for Microsoft, through a wink and a nod, to ensure that any such representations were not accompanied by efforts to prove that commercial practicability to Microsoft's detriment.

8. • THE RPFJ'S ENFORCEMENT MECHANISMS ARE FUNDAMENTALLY INADEQUATE.

As we have shown above, the RPFJ fails adequately to prevent Microsoft from engaging in illegal and anticompetitive practices, and allows it to continue the patterns of behavior that led to this litigation in the first place. The RPFJ suffers from an important secondary flaw, however: the enforcement mechanisms contained in Section IV are fundamentally inadequate. The RPFJ commits much of the practical enforcement responsibility to a "Technical Committee," RPFJ § IV(B), that would monitor "enforcement of and compliance with" the RPFJ. Id. § IV(B)(1). The Technical Committee is likely to impede enforcement rather than aid it.

First, Microsoft -- the antitrust violator -- could exert inappropriate control over the membership of the Technical Committee. Rather than creating a special master or an independent review committee to monitor compliance with the consent decree, the RPFJ allows Microsoft to have an equal voice with the plaintiffs in choosing the members of the Technical Committee; indeed, Microsoft may choose one of the three members outright. Id. § IV(B)(3). Although appointing a special master with real (though reviewable) power might make sense as a matter of judicial administration, allowing Microsoft to choose its own monitor makes no sense at all.

The composition of the Technical Committee suffers from a second defect. The RPFJ provides that "[t]he Technical Committee members shall be experts in software design and programming." RPFJ § IV(B)(2) (emphasis added). The interpretation of the RPFJ is largely a legal matter, however, dependent on adequate knowledge of the antitrust Section after section of the RPFJ is extraordinarily vague.⁽¹⁹⁾ Experts in software design simply will not have any basis adequately to review complaints that Microsoft's behavior fails to comply with the RPFJ. However, that is the entire purpose of the Technical Committee.

Not only is the selection and composition of the Technical Committee problematic; the RPFJ's restrictions on how the Technical Committee can go about its business are equally inadequate. For example, it is likely that all third-party allegations of misconduct by Microsoft will be reviewed by the Technical Committee.⁽²⁰⁾ But the Technical Committee lacks any real power, and operates almost entirely in secrecy. Even if the Technical Committee finds Microsoft to be violating the RPFJ, its sole recourse is to "advise Microsoft and the Plaintiffs of its conclusion and its proposal for cure." id. § IV(D)(4)(c). If DOJ or the settling State plaintiffs proceed with a complaint, none of the "work product, findings or recommendations by the Technical Committee may be admitted in any enforcement proceeding before the Court for any purpose, and no member of the Technical Committee shall testify by deposition, in court or before any other tribunal regarding any matter related to [the RPFJ]." id. § IV(D)(4)(d). Enforcement would have to start over from scratch.

In effect, the Technical Committee's investigation is simply a waste of time. Even were the plaintiffs to decide, based on a Technical Committee report, that Microsoft had violated the RPFJ, the plaintiffs would need independently to investigate that violation under Section IV(A)(2). Indeed, the Technical Committee's reports to the plaintiffs will be secret. See RPFJ § IV(B)(8)(e), (9). Ultimately, the Technical Committee simply injects delay into the process. But delay is indisputably in Microsoft's interest; Microsoft's monopolies bring it $1 billion each month in free cash flow, see Rebecca Buckman, Microsoft Has the Cash, and Holders Suggest a Dividend, WALL ST. J., Jan 18, 2002, at A3. Microsoft not only can afford to contest enforcement vigorously, but would not have to postpone enforcement for long before the RPFJ expires.

Finally, the "crown jewel" provision in the RPFJ is grossly inadequate. If at any point the court were to find that Microsoft had "engaged in a pattern of willful and systematic violations," RPFJ § V(B) (emphasis added), the RPFJ provides only one remedy for plaintiffs or the court: to extend the inadequate, and already overly-short, consent decree by "up to two years." But that is no deterrent. Willful and systematic violations should result in divestiture that terminates the illegally maintained monopoly once and for all. See Microsoft III, 253 F.3d at 103; United Shoe, 391 U.S. at 250. Slightly prolonging a failed decree makes no sense at all.

CONCLUSION

The Revised Proposed Final Judgment should be rejected as contrary to the public interest.

FOOTNOTES

1. Indeed, in denying rehearing, the D.C. Circuit made crystal clear that "[n]othing in the Court's opinion is intended to preclude the District Court's consideration of remedy issues." Order, at 1 (D.C. Cir. Aug. 2, 2001) (per curiam).

2. RPFJ § III(H) contains two subsections (1) and (2). We distinguish between the two sets of subsections with the bracketed terms "first" and "second."

3. See also, e.g., United States v. Robertson, 250 F.3d 500, 509 (6th Cir. 2001); United States v. Greener, 979 F.2d 517, 521 (7th Cir. 1992); United States v. McGovern, 822 F.2d 739, 742 n.4 (8th Cir. 1987); United States v. Randahl, 712 F.2d 1274, 1275 (8th Cir. 1983).

4. Decided in an equally remote context was United States v. BNS, Inc., 858 F.2d 456 (9th Cir. 1988), in which the Ninth Circuit approved a preliminary injunction, entered over DOJ's objection, against a tender offer for an acquisition that a proposed consent decree would have permitted.

5. See generally Declaration of Edward Roeder (attached). See also, e.g., Ian Hopper, Microsoft Lobbied Congress Over Case, SAN JOSE MERCURY NEWS, Jan. 11, 2002, at C3; Heather Fleming Phillips, Washington Politicians Chime In On Microsoft, SAN JOSE MERCURY NEWS, June 30, 2001, at A1; Rajiv Chandrasekaran & John Mintz, Microsoft's Window of Influence; Intensive Lobbying Aims to Neutralize Antitrust Efforts, WASH. POST, May 7, 1999, at A1; James Grimaldi & Jay Greene, Microsoft Hard At Work Outside Courtroom, SEATTLE TIMES, Feb. 17, 1999, at A1. See also Microsoft's Political Donation In Question; South Carolina GOP Says Decision To Quit Lawsuit Coincidental, CHI. TRIB., Dec. 25, 1998, at 3.

6. See, e.g., Williams v. Brooks, 945 F.2d 1322, 1325 n.2 (5th Cir. 1991) ("a congressman is an 'officer of the United States' within the meaning of [28 U.S.C. § 1442(a)(1)]"); Nebraska v. Finch, 339 F. Supp. 528, 531 (D. Neb. 1972) ("It is * * * clear that a representative to the Congress of the United States is an officer of the United States, not an officer of the district in which he was elected."); United States v. Meyers, 75 F. Supp. 486, 487 (D.D.C. 1948) ("Obviously, a Senator of the United States is an officer of the United States.").

7. See Chandrasekaran & Mintz, supra, WASH. POST, May 7, 1999, at A1; Grimaldi & Greene, supra, SEATTLE TIMES, Feb. 17, 1999, at A1.

8. That final proposal, known as Draft 18, was formerly posted on a now-defunct website, www.contentville.com, in connection with a review of a book that detailed the progress of this case. The text of Draft 18 may now be viewed at www .ccianet. org/legal/ms/draft18.php3.

9. It is telling that the CIS ignores the remedial standard that the D.C. Circuit set out. See CIS 24, 66 Fed. Reg. 59,465. The CIS submerges the need to craft relief that tends to "terminate" the illegally maintained monopoly, despite the court of appeals' contrary instructions. See 253 F.3d at 103. Rather, the CIS endorses a watered-down standard in order to set a lower bar for the RPFJ to clear, in tacit recognition that the RPFJ cannot satisfy the D.C. Circuit's standard. The CIS would require relief only to "[e]nd the unlawful conduct," to prevent recurrence of the violation "and others like it," and to "undo its anticompetitive effects." CIS 24, 66 Fed. Reg. 59,465. The RPFJ falls short even of these modified, more modest objectives, however, particularly when measured by its failure to prevent future violations that work slight variations on the conduct condemned by two courts, and its failure to "undo" any of the "anticompetitive effects" of Microsoft's sweeping, coordinated, and successful anticompetitive campaign.

10. See n.2, supra.

11. The user interface is especially insignificant because the browser window already can serve as the user interface for many products, and could easily be adapted to serve as the user interface for many more.

12. Similarly, the RPFJ places no limits on Microsoft's conduct toward one of its largest current groups of licensees -- direct corporate licensors of bulk Windows licenses. The corporate market has always been Microsoft's point of leverage, and those buyers now often buy direct. Microsoft has made clear its intention to make Windows and other software a renewable "service." Microsoft can undo all of the provisions applying to OEMs upon the first license renewal with an end-user.

13. Mr. Barksdale's letter in lieu of hearing testimony is available at http://java.sun.com/features/2002.01.barksdale-letter.html, and the attachment is available at http://java.sun.com/features/2002.01.barksdale-attach.htm

14. Moreover, the term "interfaces" is not defined in the RPFJ. The CIS explains that "'[i]nterfaces' includes, broadly, any interface, protocol or other method of information exchange between Microsoft Middleware and a Windows Operating System Product." CIS 33-34, 66 Fed. Reg. 59,468. But that definition would not be part of the judgment.

15. In this discussion we set aside the non-trivial question whether "Windows" itself is a generic, or at best descriptive, mark for the type of "windowing" graphical user interfaces invented at the Xerox Palo Alto Research Center in the 1970s, popularized by the Apple Lisa and Macintosh in the 1980s, and since used by Microsoft and many other software vendors.

16. See, e.g., Testimony of Mitchell Kertzman before the Sen. Jud. Comm., July 23, 1998 (detailing Sybase's difficulties in this regard); Statement of Michael Jeffress before the Sen. Jud. Comm., July 23, 1998 (after TVHost revealed its intellectual property to Microsoft In failed negotiations to sell the company, Microsoft Imitated the product).

17. As of 1998 it was the policy of the Antitrust Division that consent decrees last for at least 10 years. See ANTITRUST DIVISION MANUAL, at IV:54 (3d ed. Feb. 1998); see also V VON KALINOWSKI ET AL., ANTITRUST LAWS AND TRADE REGULATION §§ 96.01[2], at 96-4; 96.02[1] at 96-10 (2d ed. 2000).

18. If Microsoft actually and convincingly lost its monopoly before the expiration of a decree of appropriate length, it could, of course, move for modification or termination of the decree under Rufo v. Inmates of Suffolk County Jail, 502 U.S. 367 (1992).

19. For example, as we discussed above the RPFJ relies heavily on a "reasonableness" standard of conduct that simply reproduces a full analysis under the antitrust laws. Antitrust remedies, like other injunctive decrees, are supposed to be amenable to swift and sure enforcement, according to standards that give warning of what is forbidden and what is permitted both to the wrongdoer and to its potential victims. But again and again, the RPFJ would require both the Technical Committee and eventually the decree court to determine whether Microsoft's conduct was "reasonable."

20. While third parties have the right to raise complaints with the Internal Compliance Officer, see RPFJ § IV(C)(3)(g), the RPFJ gives them no incentive to do so; such complaints would merely allow a proven antitrust violator itself to determine whether it has violated the RPFJ or again violated the antitrust laws. Although the RPFJ also allows third parties to submit complaints directly to the plaintiffs, see id. § IV(D)(1), the plaintiffs can thereafter at their sole discretion refer any such complaints to the Technical Committee, id. § IV(D)(4)(a), or to the Internal Compliance Officer, id. § IV(D)(3)(a).