U.S. Department
of Justice
Argument
| This document is available in two formats: this web page (for browsing content) and PDF (comparable to original document formatting). To view the PDF you will need Acrobat Reader, which may be downloaded from the Adobe site. For an official copy, please contact the Antitrust Documents Group. |
| IN THE UNITED STATES DISTRICT COURT
COMMENTS OF SOFTWARE & INFORMATION INDUSTRY ASSOCIATION
Dated: January 28, 2002 COMMENTS OF SOFTWARE & INFORMATION INDUSTRY ASSOCIATION Pursuant to Section 2(b) of the Antitrust Procedures and Penalties Act (the "Tunney Act"), 15 U.S.C. § 16(b)-(h) (2000), the Software & Information Industry Association ("SIIA") submits these comments on the Proposed Final Judgment ("PFJ") filed by the United States Department of Justice ("DOJ") on November 6, 2001. SIIA is the principal trade association of the software code and information content industry. SIIA provides global services in government relations, business development, corporate education, and intellectual property protection to more than 800 leading software and information companies. Our members develop and market software and electronic content for business, education, consumers, and the Internet. SIIA's membership is comprised of large and small software companies, e-business and information companies, as well as many other traditional and electronic commerce companies of varying sizes. Among SIIA's key public policy issues is the promotion of competition in the software industry.1 SIIA has promoted these principles of competition in a variety of fora, including the federal courts.2
The PFJ proffered by DOJ represents a remarkable change of heart- or, perhaps more accurately, a loss of heart.3 For whatever reason, DOJ proposes to end one of its most important and successful monopolization cases with a settlement that reflects neither its litigating position nor the decisions it won at trial and on appeal. A settlement as weak as this would have been disappointing, but perhaps understandable, if it had been reached before trial. In such a situation, litigation is uncertain, and sometimes DOJ must take a bird in the hand. But in this case, much of the litigation is past; and the new Administration arrivals are not free to decide what legal theories apply to this case. The law of this case is settled. The trial and appeals courts have already made findings of fact and conclusions of law. These findings and conclusions cannot be ignored in a proceeding whose raison d'etre is protecting against an improperly motivated or expedient compromise of the public's interest in enforcement of the antitrust laws. Appropriate relief in an antitrust case should end the unlawful conduct, pry open the market to competition, avoid a recurrence of the violation and others like it, and undo its anticompetitive consequences. Unfortunately, SIIA submits that the PFJ does not accomplish these goals and ignores significant parts of the Court of Appeals's decision regarding Microsoft's antitrust violations and their consequences. Even where it seems to address the violations identified by the Court, the PFJ is so porous that it provides little or no protection against a repetition of Microsoft's past anticompetitive acts. 1. Flaws in the PFJ's Remedies. The two most salient remedies imposed on Microsoft under the PFJ concern flexibility for OEMs to install competing middleware and APIs. DOJ's Competitive Impact Statement ("CIS") stresses the importance of preventing future abuses in these areas.4 The theme of the CIS and PFJ is that competition was injured in this case principally because Microsoft's illegal conduct maintained the applications barrier to entry in the personal computer operating system market by thwarting the success of middleware that would have helped competing operating systems gain access to applications and other needed complements. The PFJ is intended to restore competition. In fact, however, the PFJ is so loosely written that it is likely to have only the most modest effect on Microsoft's actions - and none at all on its ability to monopolize new sectors of the information technology market. a. Middleware. Middleware was at the heart of the case.5 Impelled by enthusiasm for the Internet, PC users embraced Netscape's browser, and Netscape (particularly in combination with JAVA) was able to provide applications developers with a new, non-Microsoft path to the desktop. This is not simply an academic observation on the part of SIIA and its members. For practically every one of our members, the rise of independent middleware opened new opportunities that were the objects of intense strategic focus. The reason for this focus was that our members' programs suddenly could use Netscape and JAVA as mediators to install, launch, and run on the desktop. For the first time in years it seemed possible that independent software vendors (ISVs) would have a way to reach the great majority of computer users independent of Microsoft. Indeed, because they could run on other operating systems, JAVA and Netscape's browser suddenly offered these ISVs an even broader market than they could obtain by developing for the Microsoft operating system. The CIS describes how this competitive threat struck at the heart of Microsoft's monopoly, and Microsoft's counterattack used every possible weapon, including such unlawful tactics as "leveraging" its operating system monopoly. The PFJ seeks to prevent Microsoft from repeating these tactics by ensuring that future middleware vendors are not denied access to the desktop. But the measures chosen are unlikely to have that effect. As a matter of drafting, they are fatally weak. Microsoft itself is expressly granted nearly complete control over the meaning of "middleware" under the PFJ. Equally important, these measures are written for a world that no longer exists. The market has moved on. The PFJ grants to hardware makers the right to add middleware icons to their PCs, but these companies simply lack the financial strength and the motivation to develop new software that might threaten Microsoft. To take one example, OEMs have been assured by Microsoft for several months that they may customize their desktops by uninstalling Microsoft's Internet Explorer; not one has actually done so. Meanwhile, the PFJ does not give independent software vendors who might challenge Microsoft the one thing that would tempt them - a channel to users that is not subject to exclusionary practices by Microsoft. On the contrary, the PFJ protects middleware only after Microsoft has launched a similar product, by which time it is too late. Developers of applications will always develop first and most enthusiastically for the most widely deployed platform, because that platform offers them the largest market-the most users. Users, in turn, will typically choose the most widely deployed platform because it offers them the greatest choice of applications. This reinforcing circle-a well established network effect--is at the heart of Microsoft's dominance of the industry. Cross-platform middleware threatened Microsoft in 1995-98 because it could offer developers an even bigger market - a "Microsoft plus" market. But Microsoft cannot be seriously challenged in that way again because no new entrant to the middleware market can hope to equal the ubiquity of Microsoft in that market, let alone achieve the "Microsoft plus" market that Netscape and JAVA offered in 1995-98. b. APIs. The PFJ also requires that Microsoft disclose the APIs used by Microsoft middleware to interoperate with the Microsoft operating system. Here, too, the PFJ suffers both from porous drafting, and from a curious blankness regarding the sources of Microsoft's dominance of the market. The provision is replete with terms that are not defined ("interoperate"), are defined only vaguely ("API"), are defined based on how a product is named or distributed ("Microsoft Middleware") or, most remarkably, are left to be defined by Microsoft's "sole discretion" ("Windows Operating system Product"). In any event, the PFJ does little more than throw Microsoft into a briar patch it has long called home. Microsoft's competitive dominance depends on having the largest stable of application developers writing for its users. To write programs for Microsoft users, the developers must have access to Microsoft's APIs. The APIs are their air supply, and Microsoft has every reason to give developers access to that air supply - within limits. As long as Microsoft can keep its hand on the valve, as long as it can cut off the air supply to developers who are too independent or too successful, it has every incentive to provide extensive information about its APIs. And the PFJ leaves the valve firmly in Microsoft's hands by allowing Microsoft to impose royalties and other restrictions on developers who obtain access to the APIs. The PFJ thus requires little or nothing more than Microsoft would provide on its own. Unless developers can be guaranteed an air supply that does not depend on Microsoft, they will not challenge the company that can unilaterally cut them off. 2. Backward-Looking Remedies. In short, when all is said and done, this PFJ wagers everything on a series of measures that might have prevented Microsoft from unlawfully destroying Netscape in the browser wars. Even this is open to question, but the real problem with the PFJ lies deeper, for there is not the slightest chance that these measures will allow a new competitor on the order of Netscape to emerge. The market has moved on. Focusing only on preventing a repetition of the unlawful actions Microsoft took in 1995-98 is like negotiating an end to World War II by letting the Germans keep Paris as long as they promise to rebuild the Maginot Line. Such a limited focus is not just improvident, it ignores the instructions of the Court of Appeals that any relief "terminate" Microsoft's unlawful monopoly and "deny" the company the "fruits" of its unlawful conduct. This cannot be accomplished by relying on the emergence of some yet-to-be-identified middleware challenger. To the contrary, Microsoft has already solidified its unlawful victory into a browser monopoly, and it now bids fair to make the entire Internet into a proprietary Microsoft environment. Any remedy that seeks to deny Microsoft the fruits of its unlawful conduct must at a minimum prevent Microsoft from using the same conduct to extend its control of services that rely on Internet Explorer. For that reason, SIIA urges that the PFJ be expanded to address present and future conditions, and not just the dead past. The PFJ must take steps to reduce the massive structural advantage that Microsoft has achieved by unlawfully leveraging its operating system monopoly into an Internet-access monopoly. These steps include opening the code of Internet Explorer ("IE"), restricting exclusionary uses of Windows XP and the tools that make up Microsoft's .NET initiative, preventing Microsoft from "polluting" standards by adding proprietary extensions, and inclusion of Microsoft's productivity applications in any relief. 3. Missing Principle. One further gap in the PFJ deserves mention. If the specific changes required by the PFJ are of very dubious force, the only provisions likely to have continuing value are those that spell out broad principles of conduct. Here too there is much room for disappointment. The PFJ does not prohibit Microsoft from intentionally disabling or adversely affecting the operation of competing products. No explanation is offered for this omission. 4. Procedure. Finally, SIIA wishes to address one procedural point. At the center of this proceeding are the decisions of the Court of Appeals and the District Court. What they say about Microsoft's conduct and about the appropriate remedies are an essential part of the public interest analysis. But they are also at the heart of the case between the remaining litigating States and Microsoft. It may be difficult to reach a conclusion about this PFJ without prefiguring a decision on the very issues that the parties intend to litigate before the Court in the near future. To do so on the basis of a few Tunney Act filings rather than a full record might do an injustice to the parties to that litigation. SIIA therefore respectfully requests that this Court take the PFJ and its terms under advisement until the conclusion of the litigation. In sum, the PFJ, as written, represents a failure of will and technological wisdom that cannot be approved by this Court consistent with the unanimous liability decision of the Court of Appeals, traditional standards of antitrust remedy law, or the Tunney Act.
Under the Tunney Act, this Court is required to review a proposed settlement to determine whether it serves the "public interest."6 In most instances Tunney Act proceedings occur prior to trial and without any judicial findings of liability. The Act was passed to open this stage of the proceedings to the sunlight of public scrutiny.7 In the unique procedural context of this case, however, where the Court of Appeals issued an opinion on the merits prior to the initiation of Tunney Act proceedings, the "public interest" standard must necessarily be applied consistent with the Court of Appeals opinion. The Court of Appeals ruled, "[t]he Supreme Court has explained that a remedies decree in an antitrust case must seek to `unfetter a market from anticompetitive conduct,' Ford Motor Co., 405 U.S. at 577, 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.'"8 Thus, this Court must consider each of these factors in its public interest analysis. Ordinarily, the Department of Justice is given prosecutorial discretion in deciding whether to bring a civil antitrust action. As a result, courts generally require that a proposed settlement only be "`within the reaches of the public interest',"9 for which approval is warranted "even if it falls short of the remedy the court would impose on its own."10 Thus, in typical Tunney Act cases, courts have permitted entry of consent decrees which were merely "consistent with the government's general theory of liability as manifested in its complaint"11 and that "grant[ed] relief to which the government might not be strictly entitled" under the antitrust laws, Bechtel, 648 F.2d at 660. In this case, after trial and with the benefit of an extensive factual record, the Court of Appeals held specifically that relief must seek to "terminate" Microsoft's operating system monopoly, "unfetter" barriers to competition to the OS market, and "deny" Microsoft the "fruits" of its statutory violations.12 DOJ itself has emphasized to this Court that "both the applicable remedial legal standard and the liability determination of the Court of Appeals are clear."13 Here, there is no question that the Court of Appeals is binding on this Court as well as the litigants. Consequently, the Court of Appeals' mandate is the "public interest as expressed in the antitrust laws." The CIS, however, articulates a different and considerably less rigorous standard for a remedy in an antitrust case. According to the CIS, "[a]ppropriate injunctive relief . . . should: (1) end the unlawful conduct; (2) `avoid a recurrence of the violation' and others like it; and (3) undo its anticompetitive consequences."14 Significantly, the formulation advocated by DOJ does not require the remedy to `terminate' the illegal monopoly, or to `deny the defendant the fruits' of its unlawful conduct. Regardless of whether the DOJ formulation may have been appropriate in past cases, it is simply the wrong standard of review for the remedy in this case, where the District Court and Court of Appeals have clearly outlined how Microsoft violated the Sherman Act. The PFJ is deficient under either formulation. There are substantial disparities between the CIS and the PFJ. And the DOJ has not even attempted to defend the PFJ under the more stringent, and binding, Ford/United Shoe/Grinnell standard that this Court must seek to enforce.
SIIA's proposed modifications to the PFJ, described in detail below, are both numerous and substantial. Regrettably for consumers, Microsoft's already proven monopolistic acts have so destroyed competition in the operating systems market that adoption of these proposals is critical if the PFJ is to "unfetter" the market from Microsoft's anticompetitive conduct, "terminate" Microsoft's illegal monopoly, deny Microsoft the "fruits" of its Sherman Act violations, and prevent future monopolistic acts, in accordance with the Ford/United Shoe/Grinnell standard for remedies. There are similarities between this case and the AT&T divestiture,15 the last large monopolization settlement under the Tunney Act. SIIA submits that in this case the PFJ is similarly completely inadequate to remedy the serious antitrust violations in this matter. In the former matter Judge Greene reviewed the evidence on all issues except remedy. After evidentiary hearings, third-party submissions, and lengthy oral argument, Judge Greene declined to approve the consent decree as proposed because he concluded that it was inadequate in certain areas and precluded the Court from effective oversight and enforcement. Judge Greene required significant changes to the proposed decree before he would consent to enter the settlement under the Tunney Act's public interest standard, holding that "[i]t does not follow. . . that [the Court] must unquestioningly accept a [consent] decree as long as it somehow, and however inadequately, deals with the antitrust. . . problems implicated in the lawsuit."16 SIIA respectfully requests that this Court follow Judge Greene's prudent actions and send the parties back to the negotiating table to formulate an appropriate PFJ. This Court should reserve its conclusion on the PFJ until after the pending State case has been litigated.
As the CIS indicates, the core manner in which Microsoft unlawfully maintained its Windows Operating System ("OS") monopoly was by bundling and tying platform middleware to the OS. Microsoft used this strategy to defeat the alternative platform threats posed by Netscape and JAVA. The D.C. Circuit ruled that these actions constituted unlawful maintenance of monopoly under Section 2.17
It is critical for this Court to understand that the business and economics that drive the software industry demonstrate conclusively that the ubiquity of a development platform will almost always beat technological superiority. The common interest of software developers and consumers in adopting the most uniform platform is the basis of the Microsoft monopoly. As a result, if Microsoft is allowed to continue to bind or bundle its middleware offerings with the Windows OS, the ubiquity of its middleware will be permanent, and active middleware competition will never emerge. Microsoft will enjoy a perpetual maintenance of its monopoly, codified and reinforced by to the PFJ, and consumers will suffer a significant retarding of innovation that would have otherwise occurred. The negative consequences of this outcome on innovation cannot be overstated. If there is no way to reach consumers except through Microsoft's platform, and if Microsoft remains free to cut off the access of applications that are "too successful," then there are few incentives for independent innovation in the fields that Microsoft occupies. Yet one of the principal comparative advantages currently enjoyed by the United States' economy and its consumers is generally superior technological development and innovation. Allowing Microsoft's monopoly to continue unfettered (as the PFJ does) would significantly erode this advantage over a short time. The CIS recognizes this central fact and claims to have addressed it. The CIS says that the PFJ will ensure that OEMs (manufacturers of PCs) have the contractual and economic freedom to distribute and support non-Microsoft middleware products without fear of coercion or retaliation by Microsoft. Further, the CIS claims the PFJ will ensure that OEMs have the freedom to configure the personal computers they sell to feature and promote non-Microsoft middleware, and will ensure that developers of these alternatives to Microsoft products are able to feature those products on PCs. The CIS also claims the PFJ will ensure that OEMs have the freedom to offer non-Microsoft middleware, by requiring Microsoft to provide the OEMs with the ability to customize the middleware installed.18 SIIA considers these goals to be laudable. But flaws in the PFJ as written mean that it cannot achieve these goals, or even reduce the monopoly Microsoft currently enjoys.
First, merely allowing OEMs and end-users (individuals and businesses) to remove icons and shortcuts (so-called "end user access") does not solve the underlying problem. The PFJ leaves all of the browser middleware on the PC hard disk, which means that it is available to Windows, and all Windows applications. In other words, the PFJ does nothing to remove or modify the code itself - the hidden "plumbing" by which Microsoft has bound Internet Explorer (IE) to Windows. As a result, third-party software developers can continue to rely on Microsoft's middleware plumbing - as long as they write Windows applications. None of the incentives that bind developers to Microsoft will change under the PFJ because developers will still be assured that Microsoft's middleware will be installed on about 95 percent of desktop PCs whether or not the "end user access" is removed. In short, Microsoft can still enjoy the benefit it wrested from Netscape and JAVA when it forced their middleware out of the mainstream. That benefit was not a ubiquitous icon - it was ubiquitous plumbing. The PFJ thus fails to address the network effect that drives the Microsoft monopoly: competitors will still face the same applications barrier to entry because Microsoft's development platform will still be ubiquitous. ISVs will therefore continue to write applications to the Microsoft APIs, ignoring the more narrowly distributed-and therefore higher cost per-unit-alternatives. If anything, the PFJ helps to lock in this network effect by merely giving OEMs and end users the option to remove the icons and shortcuts rather than allowing them to decide whether to add the Microsoft middleware in the first place. For this reason alone the PFJ fails to meet even the requirements of antitrust remedies law and does not comport with the D.C. Circuit opinion.
As is detailed throughout these comments, it is important for this Court to understand that Microsoft currently enjoys a monopoly in the distribution channel - namely, the Windows operating system. The PFJ does nothing to alter this monopoly since Microsoft is allowed to continue integrating its middleware into its ubiquitous OS. The "removal" of the middleware in the superficial manner proposed by the PFJ permits Microsoft to commingle code for middleware with the OS, and does nothing to prevent Microsoft from protecting its Windows monopoly power through the same exclusionary means used against Netscape and JAVA. Nothing is more persuasive than experience, and experience suggests that granting OEMs the right to "uninstall" IE is a meaningless remedy. In fact, Microsoft has already revised Windows XP so that OEMs may "uninstall" end user access to IE. Not one OEM to date has taken advantage of this option.
SIIA also believes that the PFJ's reliance upon OEMs in this section of the PFJ is misplaced. OEMs have historically been low-margin economic dependents of Microsoft, and they have therefore been reluctant to challenge Redmond. Since 1995-98, this situation has worsened. Currently, PC manufacturers face falling prices and demand. It is not economically rational in this market environment to expect OEMs to invest in the research and development, and product design work, necessary to replace Microsoft's "free" middleware with the products of competing vendors. OEMs should have the option to ship Microsoft middleware if they choose to do so by obtaining it from Microsoft, and not because they were forced to do so by Microsoft's bundling or bolting of the middleware to the OS.
Another essential element of the PFJ's supposed remedy to Microsoft's monopoly is to create a "marketplace" for competitive middleware on the PC desktop. This "marketplace," however, is illusory. It will never occur under the current structure of the PFJ. Developers cannot be offered the "Microsoft plus" market that Netscape and JAVA offered before Microsoft's unlawful counterattack. Microsoft will still have access to all PCs for free by virtue of its distribution monopoly. Consequently, its competitors can only hope to be installed alongside Microsoft's middleware on some of the machines sold by OEMs. Instead of "Microsoft plus" they will have to settle for "Microsoft minus." Since software developers write first to the most widely available middleware (the applications barrier to entry19), competing middleware vendors will not pay much for the chance to run a distant second to Microsoft in ubiquity. Nor does the PFJ allow independent middleware companies to purchase a "Microsoft-free" market; without the commingling remedy, alternative middleware vendors cannot pay for exclusivity. The PFJ only permits competitive middleware vendors to pay for shared access to some PCs. SIIA's proposed anti-bundling remedy, in contrast, would immediately increase the value and competitiveness of the "marketplace" by permitting PC manufacturers to truly differentiate their products with competing middleware.
The appropriate remedies proposed by SIIA for this bundling problem are numerous because the problem is so central:
Three other remedial points bear discussion here. First, the current definitions of Microsoft Middleware or Microsoft Middleware Product allow Microsoft to unilaterally determine the scope of its obligation simply by deciding whether to ship a product separately from Windows. The definition under the PFJ provides that if Microsoft has distributed middleware separately from the OS, it is a Middleware Product.21 In SIIA's view the revised definition should provide that if anyone distributes middleware separately from the OS, it is a Middleware Product, and subject to the binding prohibition. Thus, if a competitor created a new middleware technology, Microsoft would therefore be precluded from introducing its own version integrated with the OS, and thereby stifling the potential for the new middleware technology to erode the applications barrier to entry. In other words, the proposed revised definition would ensure that Microsoft cannot "gate" the development of middleware by integrating new innovations pioneered by third-parties into its OS, instead of distributing a Microsoft "clone" as a separate retail product. Second, the Office Suite of productivity applications and the Outlook email and personal information management program should be added to the definition of Middleware Product in order preclude Microsoft from evading the constraint of this section of the PFJ by binding Office or Outlook technology (each of which exposes APIs and can erode the applications barrier to entry) to the OS. Third, Microsoft should be required to provide IE source code on an open source basis, as described below. This is necessary because IE, which once was a classic example of middleware, has now been so thoroughly integrated into the OS by Microsoft that permitting Microsoft to bind middleware to IE would allow Microsoft to circumvent the anti-binding provision. Under a properly revised PFJ:
The Court of Appeals' decision in this matter supports the SIIA's proposed alternative remedy. While the Appellate Court reversed the District Court's conclusion that Microsoft's exclusionary conduct violated Section 1 as a per se unlawful tying arrangement, it unanimously affirmed liability for monopoly maintenance under Section 2 for this same behavior, ruling that "[t]echnologically binding IE to Windows . . . both prevented OEMs from pre-installing other browsers and deterred consumers from using them."22 The Court specifically found that Microsoft's commingling of software code for Windows and IE was unlawful and recognized that its remand of the Section 1 tying claim was wholly consistent with imposing Section 2 liability for essentially the same conduct: "The facts underlying the tying allegation substantially overlap with those set forth . . . in connection with the § 2 monopoly maintenance claim."23 Thus, this Court is not limited in any fashion in altering the PFJ to restrict Microsoft's ability to bundle and bind other software with the OS. The D.C. Circuit's express affirmance of liability for binding IE to Windows OS is significant because Microsoft sought to limit the Court's holding solely to the more narrow issue, on which the D.C. Circuit also affirmed, of excluding IE from the so-called "add/remove" utility. Microsoft argued that its commingling of code was appropriate and that the Court should only affirm on the ground that it had not allowed end users a means of deleting the IE icon from the desktop. The Court of Appeals rejected Microsoft's argument out-of-hand.24
The current computing market is shifting away from client-side software, toward an environment of Internet-based ("distributed") applications and Web services. Everything from spreadsheets and music to air travel reservations and photo development can be offered as a web service. Microsoft has made clear its desire to shift its entire business from a product licensing model to a model in which it derives revenue from a subscription of services. Microsoft has designed Windows XP to distribute key middleware components such as Passport, Windows Messenger, and Windows Media Player, while at the same time making them architecturally necessary for the provision of many Internet services. In addition, Microsoft has increasingly been bundling Web-based services into its Windows operating system, thereby placing competitive and innovative services at a great disadvantage. This is an all-too-familiar tactic. By bundling and tying its Web-based services and Internet middleware to Windows XP, Microsoft further reinforces the applications barrier to entry achieved by locking users into its own Web-based services and proprietary Internet interfaces. The CIS states that the PFJ is designed to prevent recurrence of the same or similar practices that Microsoft employed to reach its current monopoly position.25 As discussed above, however, the PFJ does not achieve the goal stated by the CIS because it fails to prohibit Microsoft from continuing to bundle and tie middleware to its Windows operating system, despite the Court of Appeals' conclusion that these same acts were among Microsoft's core Sherman Act violations. The PFJ does nothing to impede Microsoft from repeating its pattern of exclusionary conduct because the PFJ is restricted to the software market and products that existed in 1995-98, and does not address today's Web-based market in which services and multimedia are replacing client-side software. The PFJ does not cover Web services, Web-based applications, or Internet content, all of which Microsoft has integrated into Windows XP. Therefore, Microsoft is free simply to continue using its familiar repertoire of anticompetitive tactics (e.g., tying, technical restrictions on user choice, etc.) to protect its OS against threats in the Web-based market through its Windows XP design. These inadequacies of the PFJ run completely counter to the public interest and only compound the problems caused by Microsoft's unlawful conduct by enabling Microsoft to extend its unlawfully-won monopoly to the next generation of technology.
The PFJ should be modified to explicitly foreclose Microsoft's use of Windows XP features to protect its Windows monopoly against Internet-based competition from server products and Web-based services. More specifically, with respect to the PFJ's OEM provisions, SIIA proposes the following:
Only with these modifications can the PFJ satisfy DOJ's own remedial goal and the Court of Appeals' requirement to prevent future monopolistic practices. The modifications to the OEM provisions are essential to enabling OEMs' flexibility to differentiate their products. OEMs must be free to eliminate or alter start menus and to integrate value-added technologies in their offerings. This ability must not be constrained by first having to remove or otherwise change the Windows bundle. The key to an effective remedy is changing the ability of Microsoft to make all systems integration and software bundle decisions, and moving some of that decision-making power down the supply chain either to the OEMs, or integrators, acting on their behalf. Moreover, this ability should not be limited to "fringe" applications, but should give OEMs the ability to focus on the core applications actually driving PC sales and demand at any given point. This modification is designed to prevent the further reinforcement of the applications barrier to entry by locking users into Microsoft's Web-based services. Microsoft's control over interoperability interfaces is anticompetitive; it directly reinforces the applications barrier to entry, reduces opportunities for ISVs and competing platform suppliers to create cross-platform applications, and prevents emerging computing platforms (e.g., handheld devices, digital telephones, etc.) from evolving into at least partial substitutes for desktop PCs. Finally, it is critical to give OEMs the ability to customize and earn revenue from desktop and browser configuration. Unfortunately, Microsoft's ability to impose its product placement and icons on the browser and the desktop for both products and services, without "paying" for the placement, undercuts the ability of OEMs to earn revenue primarily because it eliminates the ability of the OEMs to provide exclusivity. This was most evident in Summer 2001, when AOL's deal with a major OEM for placement of an AOL icon on the Windows desktop was thwarted by Microsoft's insistence that its corresponding icons also be included by the OEM, without compensation. Microsoft's action undercut the economic value of the AOL exclusive arrangement and the OEM's ability to exercise its right to desktop flexibility. The Court of Appeals's remedial standard in this case supports SIIA's proposed ban on contractual tying, which goes directly to Microsoft's ability to control the applications barrier to entry. The District Court is specifically obligated under the D.C. Circuit's standard to "ensure there remain no practices likely to result in monopolization in the future." This requires a contractual tying prohibition to include not just the markets in which tying was used previously to maintain Microsoft's OS monopoly, but also the markets, such as the Web-based services and applications integrated in Windows XP, in which tying would likely result in new monopolies in the future. A prophylactic ban on contractual tying is necessary, taking into account the Court of Appeals' remand of the Section 1 claim, because without it Microsoft could easily evade a prohibition on technical bundling middleware with Windows. With respect to Web-based services, two additional points directly support this contractual remedy. First, "Hailstorm" - now renamed NET MyServices - is a development platform that industry experts agree is middleware under any definition. Second, unlike products, there has never been a claim that technological efficiency is achieved by tying Web-based services to the OS. Therefore, the Section 1 tying issues addressed by the Court of Appeals are immaterial to a tying ban on Web-based services. The Appellate Court quite clearly recognized that "[t]he facts underlying the tying allegation substantially overlap with those set forth in Section II.B in connection with the § 2 monopoly maintenance claim."27 Because OEM and IAP contractual tying was a central element of Microsoft's unlawful monopoly maintenance, it should equally be a central component of any remedy. In its discussion of relief, the Court of Appeals did not indicate that any particular form of exclusionary behavior was off-limits, but at most that there should be an "indication of significant causal connection" between a remedy and maintenance of the Windows monopoly.28 Curiously, Assistant Attorney General James has reportedly argued that elimination of tying relief from the PFJ was required because the D.C. Circuit "excluded" the tying claim.29 In the context of the Court's actual decision, that is plainly incorrect. Regardless of the decision by DOJ and the State plaintiffs not to retry Section 1 liability, the Court of Appeals remand was based solely on application of the particular elements of Section 1 tying law, independent of both Section 2 liability (which it affirmed) and remedy.
The PFJ does not adequately remedy Microsoft's monopolistic conduct because it grants Microsoft complete freedom to decide what constitutes middleware and what qualifies as a platform software product. Under the PFJ, Microsoft Middleware is limited to software code that Microsoft (1) distributes separately from the OS, and (2) trademarks.30 A related deficiency of the PFJ is its provision that "[t]he software code that comprises a Windows Operating System Product shall be determined by Microsoft in its sole discretion."31 This ability to categorize its own products gives Microsoft enormous flexibility to circumvent the requirements of the PFJ, many of which hinge on product definitions. For example, merely by placing a product that would ordinarily be considered middleware "inside" the OS, or by adding the trademark "Windows" to a generic designation, Microsoft can exclude the product from the PFJ's middleware definition, thereby avoiding the triggering of the API disclosure provisions. According to the CIS, the PFJ will ensure that OEMs have the freedom to offer non-Microsoft middleware by requiring Microsoft to provide the OEMs with the ability to customize the middleware installed.32 More specifically, the CIS asserts that "[t]he limits in the definitions ensure that the provisions of the Proposed Final Judgment apply to products that can credibly be said to pose, alone or in combination with other products, nascent threats to the applications barrier to entry."33 The PFJ cannot possibly achieve the stated goals of the CIS if it continues to allow Microsoft to determine for itself what middleware can be included in the OS, and the scope of a Windows Operating System Product. By unilaterally exercising its powers under the PFJ, Microsoft can target competing middleware providers and deny ISVs and others the APIs needed to interoperate with Windows. As a result, the PFJ permits competitive gaming of the settlement in order to maintain Microsoft's monopoly power, thus reducing innovation and channeling OEM flexibility into those areas chosen by Microsoft because they do not threaten Microsoft's market power. Microsoft's ability to manipulate these crucial product definitions would deprive consumers of whatever limited benefits that the PFJ does provide.
To have any hope of achieving the CIS's goals, the PFJ must be modified to remove from Microsoft the power to unilaterally decide the scope of its provisions. The trademark limitation in the Middleware definition, and the "sole discretion" proviso in the Windows Operating System Product definition, should both be removed from the PFJ. The concept of "redistributable"34 should be eliminated as well from the PFJ. This would foreclose Microsoft's ability to keep key technologies outside the definition of Middleware by simply declining to make stand-alone versions available and thereby harming those few platforms (such as the Apple Macintosh) to which it ports Middleware today. As discussed above, the CIS asserts that the PFJ's definitional limits will ensure the PFJ's application only to competitively significant products. Contrary to this claim, however, there is no rational connection between trademark status or stand-alone distribution and the competitive significance of middleware. Indeed, in some respects these factors act at cross-purposes to the PFJ because they encourage the same type of technical integration with new middleware that Microsoft used with IE to eliminate the threat from Netscape and JAVA.
According to the CIS, the API disclosure provisions of the proposed decree will "creat[e] the opportunity for software developers and other computer industry participants to develop new middleware products that compete directly with Microsoft by requiring Microsoft to disclose all of the interfaces and related technical information that Microsoft's middleware uses to interoperate with the Windows operating system."35 While SIIA concurs with the intent of the CIS, a careful examination indicates that this statement cannot be reconciled with the terms of the PFJ. The PFJ would not provide middleware competitors with the information needed to interoperate. If anything, it allows Microsoft itself (as it does now) to decide whether, when, and which APIs to release to potential competitors, and includes mitigating provisions that undermine any apparent disclosure and fortify the applications barrier to entry. The information disclosure and interoperability sections of the PFJ are among its most complex. The core of the provisions are found in Section III.D, which addresses the issue of API disclosure, and Section III.E, which addresses the disclosure of communications protocols. These core provisions rely on numerous definitions which serve to undercut the effectiveness of these sections. SIIA describes below the impact of each definition. While Section III.J appears at the end of the PFJ, and III.D and III.E appear toward the beginning of the PFJ, Section III.J is directly relevant to the scope of the disclosures (and, in fact, relevant to no other provision of the PFJ). Section III.I.5 is also carefully examined in SIIA's analysis as it appears to grant Microsoft unique rights to insist on cross licenses to "any" intellectual property developed through the use of Microsoft's APIs.
PFJ provision III.D requires Microsoft to disclose "the APIs and related documentation that are used by Microsoft Middleware" (defined in the PFJ) "to interoperate" (undefined in the PFJ) "with a Windows Operating System Product" (defined in the PFJ).36 This provision simply restates Microsoft's current business practices. Relevant to the question of whether any new information is actually required is the definition of "documentation" within the context of API disclosure. "Documentation" is defined in Section VI.E of the PFJ as all information regarding the identification and means of using APIs that a person of ordinary skill in the art requires to make effective use of those APIs. Such information shall be of the sort and to the level of specificity, precision and detail that Microsoft customarily provides for APIs it documents in the Microsoft Developer Network.37 It is therefore unclear whether any information disclosure is required under this section of the PFJ that is not already part of Microsoft's information disclosure regime through the Microsoft Developers Network. The fact that the critical term "interoperate" is left undefined suggests that the parties did not have a meeting of the minds regarding the kind of information disclosure that is required under the PFJ. Likewise, the decree does not specify what is meant by "use" of APIs. In fact, the phrase "technical information" does not even appear in the proposed decree.38 In contrast, the 2000 Decree's interim conduct remedies included a detailed definition of "Technical Information" (Section 7.dd) that the Department and Microsoft have without explanation eliminated from the proposed decree.39 The utility of the information disclosure is also constrained by what Microsoft is permitted to define under the PFJ. As previously noted, Microsoft "in its sole discretion" shall determine the software code that comprises a Windows Operating System Product. Microsoft, therefore, could redefine some or all of a particular "middleware" technology as part of Windows and escape any of the disclosure requirements of Section III.D. Similarly, the definition of "Applications Programming Interfaces" lacks clear and effective meaning. APIs are defined as "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."40 This definition is inherently ambiguous because it depends on two terms, Windows Operating System Product and Microsoft Middleware, which are self-defined by Microsoft alone. It also remains unclear when there would be any information disclosure required by the PFJ. API disclosure for new "Windows Operating System Products" is required in a "timely manner." This term is defined as "at the time Microsoft first releases a beta test version of a Windows Operating System Product to 150,000 or more beta testers."41 In the software industry, the term "beta tester" has a meaning distinct from "beta copy." In the context of specific Microsoft products, even assuming that Microsoft has ever had 150,000 "beta testers," it would be easy to circumvent the timeliness requirement of this provision by limiting distribution to under 100,000 beta testers - a number that is substantial. The professed objective, as stated by the government, is to encourage "middleware innovations."42 Yet, according to the specific terms of the PFJ, innovators are precisely those who are not entitled to APIs under the proposed decree. What innovators require is not the APIs that Microsoft middleware calls upon to perform its functions, but rather others, like Windows APIs, that the new or broadened competing programs can call when executing their code.43 By limiting the disclosure requirement to only APIs that are used to interoperate with Microsoft middleware, the proposed decree is self-defeating. Middleware innovations cannot emerge if Microsoft's own products define the scope of the interoperability information that Microsoft is prohibited from refusing to competitors. Simply put, "old" APIs just do not do the trick. Furthermore, Section III.D will not allow competing middleware vendors to write software that is interoperable with Microsoft's middleware. By limiting the scope of APIs disclosable to the middleware-Windows interface, the decree permits Microsoft to continue to refuse to disclose to competitors the APIs exposed by its own middleware. Thus, if a competitor wishes to develop an application that plays Windows Media music files, or that otherwise calls upon Windows Media APIs, it has no right to obtain this information. If competing middleware developers cannot interoperate with Microsoft's existing middleware products, then Microsoft will retain the ability to leverage its Windows monopoly power to defeat middleware competition. Only by requiring the disclosure of Microsoft middleware APIs can a remedy ensure that competition in this market segment occurs on the technical merits, rather than as a result of the continued exercise of monopoly power.
The CIS asserts that the provisions in Section III.E of the proposed decree will "prevent Microsoft from incorporating into its Windows Operating System Products features or functionality with which its own server software can interoperate, and then refusing to make available information about those features that non-Microsoft servers need in order to have the same opportunities to interoperate with the Windows Operating System Product."44 Like the decree's API disclosure provisions, the specific obligations of Microsoft found in the PFJ do not meet the Department's own test articulated in the CIS. Section III.E of the decree does not require the disclosure of any APIs to competitors, only the release of "Communications Protocols." Microsoft is free to refuse to disclose to competitors any of the APIs that enable its server OS products to interoperate with Windows, with Microsoft Middleware, or with Microsoft applications such as Office and Outlook. Thus, the APIs used by Windows to interoperate with Microsoft's server OS, and vice-versa, are simply not disclosable under the proposed decree. Nothing in the PFJ prevents Microsoft from building "features and functionalities" for server interoperability into Windows. The definition of "Communications Protocols" itself is extraordinarily ambiguous. The decree defines Communications Protocol in Section VI.B as: the set of rules for information exchange to accomplish predefined tasks between a Windows Operating System Product and a server operating system product connected via a network, including, but not limited to, a local area network, a wide area network or the Internet. These rules govern the format, semantics, timing, sequencing, and error control of messages exchanged over a network. This definition does not prescribe what "predefined tasks" are encompassed, and the phrase "format, semantics, sequencing, and error control of messages" can just as easily be read to apply only to the physical means of sending information to or from a server (the rules for transmitting information packets over a network) rather then the content of such information (the rules for structuring and interpreting information within such packets). Indeed, although the CIS describes Section III.E as providing support for "features and functionalities," those terms do not appear either in the substantive provision or the definition of Communications Protocol. Moreover, the key terms of Section III.E (like Section III.D, described above) are undefined. Microsoft is allowed to define the term Windows Operating System Product. The corresponding prong of Section III.E is that Communications Protocols are disclosable when used by a Windows Operating System Product to interoperate with "a Microsoft server operating system product." This important term, which provides the boundary for Microsoft's obligation to disclose crucial information to rivals, is nowhere defined in the PFJ. Likewise, as with Section III.D, the failure of Section III.E to define "interoperate" reminds one of the Justice Department's prior failure to define "integrate" in the 1995 consent decree. The CIS asserts the term "server operating system product" includes, but is not limited to, the entire Windows 2000 Server product families and any successors.45 The PFJ, however, does not contain any of this language. Since consent decrees are interpreted as contracts, the use of the CIS to supplement a decree in ways in which the parties did not agree is arguably unenforceable.46 As with the definition of Windows Operating System Product, the scope of "Windows server operating system product" - and thus Microsoft's Communications Protocol disclosure obligations - as a matter of law is subject Microsoft's sole discretion. Therefore, Section III.E requires only the disclosure of the rules to accomplish "predefined tasks" (defined by Microsoft) by which a "Windows Operating System Product" (defined by Microsoft) interoperates with a "Microsoft sever operating system product" (defined by Microsoft). Section III.E does not cover protocols that are implemented in Internet Explorer to support interoperability with Microsoft's server OS products. Many, if not most, PC interactions with servers occur via the Internet browser. Therefore, Microsoft can easily evade any remaining scope of this provision by incorporating proprietary interfaces and protocols into IE rather than Windows. The obligations of Section III.E only apply to Communications Protocols that are "implemented ... on or after the date this Final Judgment is submitted to the Court." Consequently, all of the Communications Protocols built into Windows 2000 and Windows XP are exempt from disclosure because they were implemented before the proposed decree was submitted. This timing proviso thus provides a "safe harbor" for all current Microsoft server products since under the language of Section III.E their means of interoperating with Windows need never be disclosed.47
Any disclosure provided by Sections III.D. and III.E. is mitigated by the carve out in Section III.J, which permits Microsoft to refuse to disclose, in its discretion, protocols, API's, and technical information that are necessary for competition in the market and which Microsoft has withheld.48 This Section of the PFJ is overbroad given the District Court findings, and the Court of Appeals ruling. For example, this Section would arguably allow Microsoft not to disclose any APIs between the IE browser and the Windows OS, and the Communications Protocols between IE and ISS, Microsoft's web server, because of the browser's reliance upon authentication and encryption technologies. Section III.J.2 is even more troubling because it appears to give Microsoft the right to refuse disclosure requests even where legitimate needs are shown to promote interoperability. For example, based upon highly subjective criteria determined by Microsoft, it could refuse to supply an API, Documentation or Communications Protocol if: i) Microsoft determines that there is not a "reasonable business need" for the information, or ii) if the entity fails to meet "reasonable objective standards established by Microsoft for certifying the authenticity and viability of its business," or iii) if the entity does not agree "to submit at its own expense, any computer program using such APIs, Documentation or Communication Protocols to third-party verification approved by Microsoft."49
The requirements of Section III.I.5. reinforce the monopoly position of Microsoft and are inconsistent with the abuses found by the Courts. This Section is sweeping in its breadth by providing Microsoft with the right to insist upon a cross license to "any" intellectual property rights "relating" to the exercise of a third-party's options under the PFJ, including accessing APIs and Communications Protocols granted under Sections III.D. and III.E.50 The ostensible safety provided by the last clause is entirely illusory due to the breadth of the cross-license. SIIA submits that this Section magnifies the limitations of the limited information disclosure regime provided under the PFJ, and provides a severe disincentive to companies looking to achieve interoperability by having access to Microsoft's technical information.
The CIS claims that the PFJ will prevent Microsoft from hampering the development or operation of "potentially threatening software" by withholding interface information, or permitting its own product to use hidden or undisclosed interfaces.51 The PFJ's treatment of APIs fails to achieve the goal stated by the CIS for several reasons. APIs are central to the applications barrier - Microsoft's control of Windows APIs reduces costs for Windows developers and raises costs for rivals. As the Court of Appeals explained, because Microsoft controls the APIs, "porting existing Windows applications to the new version of Windows [is] much less costly than porting them to the operating systems of other entrants who could not freely include APIs from the incumbent Windows with their own."52 More fundamentally, merely focusing upon Windows APIs used by Microsoft Middleware Products is not enough to create conditions necessary for effective competition by alternative operating systems, or even alternative Middleware. By requiring that APIs and similar information relate to "the sole purpose of interoperating with a Windows Operating System Product"53 the PFJ does not undermine, but instead reinforces, the applications barrier to entry. Disclosing Windows APIs merely makes it easier for ISVs to write more middleware applications for the Windows OS platform. As described in Section II.C.1 above, by limiting the add/remove provisions in the PFJ to "access" to middleware, the PFJ allows the code itself to remain on all Windows machines, which reinforces incentives for ISVs to write to the APIs exposed by Microsoft middleware, instead of competitors. Thus, removing the obstacle of hidden or delayed APIs will not revive non-Microsoft Middleware, since Microsoft Middleware code will continue to be ubiquitous. Additionally, failing to require Microsoft to disclose APIs and similar interfaces (file formats, data structures, codecs, and protocols) needed to interoperate with Microsoft Middleware and the Microsoft Office family allows Microsoft to repeat its anti-Netscape tactic of hampering cross-platform middleware that poses a competitive threat. The PFJ's failure to require disclosure of Platform Interfaces similarly allows Microsoft to hamper ISVs and competing platform developers in the competition for other platforms, such as non-PC desktops, handhelds, and mobile phones.
In order to create the appropriate market incentives necessary to reduce the applications barrier, SIIA urges that any effective remedy must:
To be more specific, the following changes should be made to the PFJ:
SIIA's proposal to expand the availability of API information to include Platform Interfaces (PIs), as well as Windows APIs, ensures that both ISVs and competing platform software vendors will have adequate technical information to develop applications on other OS platforms that can "Interoperate Effectively" with the Windows OS and other Microsoft applications and middleware software. As a result, ISVs would face lower economic obstacles in porting Windows applications to other OS platforms, and would have an incentive to attempt to develop cross-platform applications that would run equally well on any PC operating system, or other computing device such as a desktop, handheld, or mobile device. In considering this remedy it is important for the Court to understand that API disclosure sets the rules by which third-party software products run on the Windows OS, but not on competing PC and non-PC platforms. Therefore, API disclosure alone has a counterproductive competitive impact by reinforcing both the Windows platform, and the applications barrier to entry. The communications protocols go to the broader question of allowing third parties to interoperate and add value to the operating system environment by better understanding the way in which its different pieces communicate. By expressly including file formats and data structures for Microsoft applications (e.g. Office, Outlook, Exchange) in the information that Microsoft is required to disclose to ISVs, the proposed remedy would reduce Microsoft's ability to exploit its control of these critical interfaces (its ability to cut off the air supply of ISVs) to reinforce the applications barrier and to disadvantage competing middleware and platform software vendors. SIIA's proposed remedy would benefit consumers by providing a uniform basis on which middleware and applications developers unaffiliated with Microsoft could design, develop, and ship competing software products that are interoperable with the Microsoft OS and with Microsoft's dominant applications and middleware products, thus eliminating excess costs and complexity stemming from software incompatibilities. Consumers would benefit from an expanded choice of timely, interoperable software products, allowing them to make purchasing decisions on the objective merits of product features and functions, rather than Microsoft's unilateral power to control and offer interoperable software products. As expanded, the remedy would also facilitate entry by independent platform software vendors and act to diminish the applications barrier to entry protecting Microsoft's OS monopoly. First, by requiring the disclosure of file formats and related technical information for Office and Outlook--two Microsoft applications products that dominate their respective categories--the proposal would support the competitive development of applications that can read/write files created by these Microsoft products, thereby providing consumers with a choice of applications in these key product categories for non-Microsoft PC platforms. Second, the inclusion of PIs and the extension of APIs to include technical information for Office/OS interoperability would provide a level playing field on which unaffiliated platform software vendors and middleware developers could write cross-platform software and competing OS products. In the absence of the market incentives that would have been created by divestiture, these informational parity provisions will ensure, if enforced effectively, that the Windows OS monopoly is not used by Microsoft to constrain the development of competing platforms and applications through the control of PIs and related technical information.
Microsoft has developed its .NET Framework (and has also designed Windows XP) with the intention of protecting its underlying Windows franchise and leveraging its desktop OS monopoly into the broader realm of Internet-based applications, Web services, and handheld OS software. Microsoft's efforts to develop proprietary APIs and interfaces for its .NET framework, including the Common Language Runtime (CLR) it has now substituted for Java, have been discussed in detail in a number of trade and general business publications. In short, after first extinguishing the cross-platform threat posed by JAVA technology, Microsoft developed a substitute executable runtime environment, limited to the Windows platform only. The .NET Framework is the functional equivalent of JAVA, but is compatible only with the Windows client and server OS products, and with Microsoft's COM software design structure. Consequently, by maintaining the proprietary and Windows-centric nature of this .NET Framework, Microsoft has succeeded in locking Web server providers into use of its Windows server OS products, and it has precluded other OS platform vendors from competing for the "cream" of today's networked PC users. The impact on consumers and on competition resembles the effect in 1995-98 of Microsoft's campaign against Netscape and JAVA. Consumers are denied a choice of runtime environments, the applications barrier to entry is strengthened against competition from non-Microsoft runtime environments, and Microsoft's Windows OS monopoly is protected against the newer threat from server-based applications. The CIS claims generally to prevent a repetition of Microsoft's past exclusionary conduct and, more specifically, to protect the competitive significance of non-Microsoft Middleware, which depends on content, data, and applications residing on servers and passing over networks such as the Internet.54 The PFJ neither accomplishes the stated goals of the CIS nor satisfies the Court of Appeals standard of review. The 2000 Decree included a broad API and "Communications Interface" provision that required disclosure of interface information for interoperability between non-Microsoft OS platforms or non-PC platforms (handhelds, phones, etc.) and Windows. The PFJ, however, takes a more narrow approach, limiting API disclosure requirements to middleware alone and failing to address interoperability with other platforms or applications. As a result, Microsoft's strategy of "Windows everywhere" is essentially unaffected by the PFJ.
In order to prevent further monopolistic practices by Microsoft in relation to its .NET initiative, SIIA proposes to include in the PFJ a remedy that maximizes the degree of interface information disclosed by Microsoft, including with respect to its .NET framework for PC-server interoperability, and requires that Microsoft port .NET to non-Windows client and server operating systems. Specifically, Microsoft should be required:
As discussed in Section II.C.7 below, the appropriate remedy for Microsoft's unlawful conduct specifically directed against JAVA, designed to restore a "but for" market that is "`unfettered'" by Microsoft's illegal activities55, is to require the inclusion of JAVA in the Windows OS. The remedy proposed here with respect to .NET is similar. Since Microsoft has substituted its own, proprietary middleware for JAVA - seeking to use its ubiquitous distribution capability to extinguish rival technologies - it should be prevented from profiting by its foreclosure of rival platforms. Indeed, the PFJ includes JAVA expressly in the definition of Middleware, but has no provisions designed to restore the competitiveness of this technology or constrain Microsoft's present efforts to make a proprietary substitute for JAVA. By opening the .NET Framework interfaces, thereby permitting competing server vendors to interoperate with Windows PCs running .NET, and by porting .NET to other PC platforms, SIIA's proposed modification would help to prevent the end user lock-in reinforced by .NET. Effective relief in this case must prevent Microsoft's further reinforcement of the applications barrier to entry, which the Court of Appeals expressly found to be the single most important factor protecting Microsoft's Windows OS monopoly.56 This remedy is necessary both to achieve the stated goals of the CIS and, as required by the Court of Appeals, to deny Microsoft the "fruits" of its exclusionary tactics directed to Java and favoring the .NET Framework.
As the Court of Appeals affirmed, Microsoft's exclusionary practices illegally maintained its OS monopoly against the threats posed by Netscape and JAVA.57 Since the beginning of Microsoft's campaign against the middleware threat, Netscape's market share has declined from over 80 percent to less than 10 percent. Microsoft's product - IE - has swept the field, rewarding Microsoft's anticompetitive conduct by eliminating the browser as a viable distribution channel for non-Microsoft middleware and APIs. As a result, developers' most important distribution channel - other than Windows itself - is now subject to Microsoft's monopoly control. Moreover, IE provides Microsoft with the power to require the use of Microsoft's proprietary APIs, communications interfaces, and/or security protocols for interoperability with desktop PCs via the Internet. As Microsoft's recent exclusion of JAVA from IE and Windows XP amply demonstrates, Microsoft has used its browser monopoly to exclude the distribution of any non-Microsoft platform software. Unfortunately, under the PFJ it can continue to do so.
The CIS claims that the PFJ will prevent recurrence of the same or similar practices employed by Microsoft to reach its current monopoly position, and restore the competitive threat posed by middleware prior to Microsoft's unlawful conduct.58 Further, under the remedial standard mandated by the Court of Appeals in this case, the PFJ must deny Microsoft the "fruits" of its Sherman Act violations.59 The PFJ plainly fails to meet both the stated goals of the CIS, and the Court of Appeals standard. Despite Microsoft's dominance of the Web browser market, which it obtained as a direct result of its unlawful conduct, the PFJ does not provide any remedy for IE, whether open source, licensing, source code access, or even API availability. In addition, with the PC interface migrating rapidly from the desktop to the Web browser, this shortcoming of the PFJ will permit Microsoft to do with IE whatever the PFJ precludes it from doing with Windows desktop.
It is therefore SIIA's position that the PFJ should require Microsoft to license the source code of IE on an "open source" basis, thus removing from Microsoft the ability to use browsers as an applications and Internet gateway that further preserves its OS monopoly. Specifically:
The proposed open source approach is linked directly to the central charge of monopoly maintenance affirmed by the D.C. Circuit. Not only is Microsoft's IE monopoly a "fruit" of its unlawful OS monopolization, but the browser represents one of the best API platforms on which ISVs can develop cross-platform software applications that would help erode the applications barrier to entry. Moreover, an open source requirement would reinforce the standards-related provisions discussed in Section II.C.10 below by eradicating Microsoft's ability to use proprietary IE browser standards to extend its desktop OS monopoly into Internet- and server-based applications. Because the browser has become the de facto standard interface for Internet audio, video, e-commerce and electronic mail applications, an open source remedy prevents Microsoft from biasing these crucial digital markets to Microsoft's own software and formats by supporting only proprietary interfaces in IE. Finally, an open source requirement is the only mechanism that creates a "but for" market; i.e., restores the market to what it would have been but for Microsoft's successful anticompetitive strategy of foreclosing Netscape from the market, and eliminating the threat posed by the browser to the applications barrier to entry. Thus, the open source browser remedy would address the browser-specific unlawful conduct central to the monopoly maintenance violation affirmed on appeal.61 The proposed modification to the PFJ would eliminate Microsoft's "fruits" and foreclose the source protecting its OS market power. This would serve the interests of consumers by restoring competition and innovation in browsers and precluding Microsoft from using IE as a vehicle for controlling the Internet standards, protocols and interfaces that lie at the heart of a networked PC marketplace. In addition, it would:
As discussed above, the proposed IE remedy is necessary to satisfy the requirement that any relief in this case remove from Microsoft the "fruits" of its monopoly maintenance violation. The Court of Appeals opinion also supports the open source remedy in other respects. In its reversal of the attempted monopolization claim, the Court chastised DOJ and the trial court for not specifically defining Internet browsers as a relevant product market.62 It is clear, however, that like the Section 1 tying claim, the attempted monopolization claim was simply another legal theory arising from the same set of operative facts. As the Court recognized, the plaintiffs "made the same argument under two different headings - monopoly maintenance and attempted monopolization."63 As a form of unlawful monopoly maintenance, the Court had no difficulty holding that "Microsoft 's efforts to gain market share in one market (browsers) served to meet the threat to Microsoft's monopoly in another market (operating systems) by keeping rival browsers from gaining the critical mass of users necessary to attract developer attention away from Windows as the platform for software development."64 Thus, DOJ's failure to introduce affirmative evidence defining a relevant market for Internet browsers cannot stand as a barrier to fashioning relief that restructures IE in order to eliminate its use as a vehicle for maintaining Microsoft's desktop OS monopoly. In sum, Microsoft's abuse of monopoly power through IE must be remedied by provisions directed specifically at IE, something the PFJ completely fails to address. It is one of the many ironies of the settlement proposed by DOJ that in a case centered around IE, neither the API provisions nor any other section of the PFJ redresses Microsoft's acquisition of power in Internet browsers, and its concomitant effect of reinforcing Microsoft's Windows monopoly power. By ignoring the browser issue the PFJ ensures that there will never be a competitive opportunity to reinvigorate browser competition, or to provide middleware competition in the range of Internet-based technologies controlled by the browser.
The CIS states that the PFJ is designed to restore the competitive threat that middleware products, such as Sun Microsystems JAVA, posed prior to Microsoft's unlawful actions.65 The PFJ, however, fails entirely to address the fact that Microsoft's illegal tactics thwarted JAVA technology, which would have significantly eroded the applications barrier to entry. The Court of Appeals found that Microsoft violated Section 2 by entering into exclusive ISV deals for distribution of Microsoft's own, incompatible version of JAVA, and by deceiving developers into writing JAVA applications with Microsoft tools that produced only Windows-compatible code.66 Microsoft also unlawfully destroyed Netscape as a viable distribution channel for JAVA technology.
SIIA's proposed remedy therefore requires inclusion of the JAVA runtime environment in Microsoft's OS products, and prohibits Microsoft from distributing any JAVA development tools. Specifically, for a period of seven years, Microsoft should be required to distribute free of charge in binary form in all copies of its Platform Software (including upgrades and revisions such as Service Packs) the latest version of the JAVA Middleware as delivered to Microsoft, at least 90 days prior to Microsoft's commercial release of any such Platform Software. In addition, Microsoft should be enjoined from distributing:
The D.C. Circuit explicitly upheld Microsoft's Section 2 liability for exclusionary conduct directed specifically at JAVA. The Court affirmed Judge Jackson's conclusion that Microsoft took steps to "`maximize the difficulty with which applications written in Java could be ported from Windows to other platforms, and vice versa.'"67 To eliminate the threat posed by JAVA, Microsoft acted to destroy the value of the technology by polluting the industry standard set of JAVA interfaces and protocols. Microsoft then abused its monopoly power by requiring its customers to adopt and distribute its incompatible, non-standard JAVA runtime and tools implementations. As the CIS notes Microsoft tried to "extinguish Java" because "a key to maintaining and reinforcing the applications barrier to entry has been preserving the difficulty of porting applications from Windows to other platforms, and vice versa," which JAVA was designed to eliminate.68 SIIA's proposed remedy would increase consumer choice by fostering competition and innovation in middleware. Similarly, it would foster competition and create innovation among operating systems by promoting the competitive distribution of middleware, and erode Microsoft's power to dictate the APIs, and related interfaces by which PCs interoperate with networked devices. It would also redress Microsoft's specific acts of monopolization directed at JAVA, and thus deny Microsoft "`the fruits of its statutory violation.'"69
Another significant shortcoming of the PFJ is its failure to mandate that Microsoft port its key productivity (Office), browsing (IE), and other Microsoft Middleware Products to non-Microsoft operating systems. In the current market, such operating systems (Apple, Linux, etc.), as well as handhelds (Palm, etc.), set-top boxes (Liberate, etc.), phones (Nokia, etc.) and other Internet-enabled appliances will only be provided with a level playing field to compete if Microsoft provides porting of its now-dominant products. Microsoft's ability and willingness to exploit the porting issue to its advantage has been specifically demonstrated in this case. Both the District Court and the Court of Appeals acknowledged that Microsoft previously used its monopoly power over Office to impose an unlawful exclusionary deal on Apple for distribution of IE on the Macintosh.70 This type of misuse of monopoly power by Microsoft is not specifically prohibited by the PFJ. As a result, Microsoft could continue to use its monopoly power over Office, and the overwhelming dominance of IE, to constrain and eliminate competition from other OS platforms by refusing, or threatening to refuse, to port Office or IE to those platforms. By ignoring this reality the PFJ neglects a critical component of the Microsoft monopoly, and significantly compromises its ability to effectively eliminate what the Court of Appeals identified as the single most important factor protecting Microsoft's Windows OS monopoly: the applications barrier.71
The CIS asserts that the PFJ will ensure that OEMs have contractual and economic freedom to make decisions about distributing and supporting Non-Microsoft Middleware Products without fear of retaliation or coercion by Microsoft. The foregoing will purportedly be achieved simply by prohibiting Microsoft from retaliating against an OEM that supports or distributes alternative middleware or operating systems.72 But OEMs will not be economically free to support or distribute alternative operating systems until control of the applications barrier is seized from Microsoft. Since the porting of Office, IE and other Microsoft Middleware Products is a crucial element in re-establishing competition in the market for operation systems, SIIA proposes that Microsoft should be required:
Without modifying the PFJ to include such specific language, the only way to prevent "porting blackmail" by Microsoft would be lengthy and expensive litigation attempting to show that a refusal, or threat to refuse, porting would constitute a change in Microsoft's "commercial relations" with an OEM. Requiring Microsoft to port its Office and IE Middleware Products to non-Microsoft operating systems is essential to overcoming the applications barrier - and thereby providing OEMs with the contractual and economic freedom the CIS promises - for at least four reasons, described below. Without a remedy specifically addressing Office, the OEMs will not be free of Microsoft's monopoly pressure. For example, Microsoft would be free to condition pricing advantages for Office on an OEM's adoption of Microsoft middleware. First, Microsoft's monopoly power over the Office business applications suite - Word, Excel, PowerPoint, Access, Outlook - provides it with the ability to constrain and eliminate competition from other OS platforms by refusing (or as in the case of Apple, threatening to refuse) to port Office. The most important contributor to the applications barrier to entry is MS Office, which currently holds a dominant share of over 95 percent of the business productivity software applications market. Without the ability to run MS Office on a PC, users have little or no choice except to select a Microsoft platform in order to maintain read/write interoperability with the most important applications product in today's software market. Second, MS Office serves as the basis for Microsoft's current strategy of extending its desktop OS dominance into the broader realm of handheld and other non-PC computing systems. Thus, the porting of Office would directly address the applications barrier to entry, and would provide increased incentives for investment in, and consumer purchase of, competing OS software for both PCs and other computing devices, such as handhelds. In addition, by exposing its own set of APIs, Office itself can represent a useful means of encouraging cross-platform middleware, but only if it is available on non-Microsoft platforms. Microsoft's refusal to port MS Office, except in return for Apple's agreement to make IE the default browser for the Macintosh, was thus manifestly anticompetitive and a major reason for Microsoft's maintenance of its OS monopoly. Third, ISVs and consumers today effectively have no choice in browser functionality other than Microsoft's IE browser. As a consequence, Microsoft can now choose to advantage its OS over any competing operating system either by refusing to port IE to the competing OS, by doing so significantly later than for its OS products, or by porting only inferior versions of IE. Likewise, Microsoft can use the dominance of its IE product to extend its desktop OS monopoly to that of non-PC devices, such as handheld computers. Unlike virtually every ISV, Microsoft has refused to port either its Office software or Internet Explorer to the Palm OS. An open source version of IE, as proposed in Section II.C.6 above, can eliminate Microsoft's ability to preserve IE as a proprietary interface to the Internet; however, it cannot alone rectify the porting problem due to the lack of browser competition. Because Microsoft has established the browser as a zero-revenue product, there is no profit opportunity for any ISV or platform competitor to create a Linux, Palm (or other handheld, digital phone, set-top box, etc.) or other version of Internet Explorer. Fourth, because Microsoft's anticompetitive conduct destroyed the Internet browser as an economically significant market, it should be required to redress that harm by porting IE to other platforms. This flows directly from the recognition in the CIS that "Microsoft's actions succeeded in eliminating the threat that the Navigator browser posed to Microsoft's operating system monopoly . . .. The adverse business effects of these restrictions also deterred Netscape from undertaking technical innovations in Navigator that might have attracted consumers and revenues."73 Because porting the Navigator browser to all significant PC platforms was an integral part of Netscape's competitive strategy until Microsoft began its unlawful campaign, a remedy should restore the pro-competitive effect - a ubiquitously available browser that exposes uniform APIs on all OS platforms - that has been lost as a result of Microsoft's violations. Arguments that porting is impossible or too costly are not legitimate. Microsoft ports versions of Office, Outlook, Media Player, IE and other middleware to the Macintosh today, some of which are available free, and others for purchase. Furthermore, as the Court of Appeals explained, the important economic consideration in porting is usage, as opposed to absolute volume. Particularly as to software (like IE and Outlook) that exposes its own APIs, "usage share, not the underlying operating system, is the primary determinant of the platform challenge a [product] may pose."74 Thus, requiring that Microsoft port to other OS platforms the principal, ubiquitous middleware/applications it now controls merely replicates what would be an easy decision for a stand-alone company that, unlike Microsoft, did not have an economic incentive to disadvantage other OS platforms. Because a firm that did not have a Windows monopoly would port both Office and IE, Microsoft should be required to port these crucial products. Finally, creating a viable market for Linux would immediately introduce price competition to the Windows OS. Linux - which is currently free - would be a potentially attractive alternative to Windows, even in the OEM channel, if Office, IE and Outlook were all available for that client platform.
As noted previously, the PFJ's overwhelming reliance on OEMs as the principal means for injecting competition into the OS market is unjustifiable. Rather than adopt a multi-faceted approach focusing on all of the contributors necessary to adequately reinvigorate competition in the OS market, the PFJ mistakenly focuses merely on allowing OEMs greater "flexibility" to customize Windows icons and non-Microsoft middleware. By doing so, the PFJ turns a blind eye to the economic realities of today's market. OEMs are currently under such extraordinary financial pressures today that, even if they had the business experience necessary to enter the software business, they have no financial incentive to purchase and incorporate into their PCs anything other than the full Microsoft software package. The failure of any OEM to act on Microsoft's offer last summer to replace icons in the Windows XP desktop makes plain this reality. The PFJ is purportedly designed to restore the competitive threat that non-Microsoft middleware products posed prior to Microsoft's unlawful undertakings.75 As noted above, the CIS claims that the PFJ does this by giving OEMs "the contractual and economic freedom to make decisions about distributing and supporting non-Microsoft software products that have the potential to weaken Microsoft's personal computer operating system monopoly without fear of coercion or retaliation by Microsoft."76 The PFJ only provides such freedom to OEMs in form, however, not in substance. Changes in OEM and retail PC market conditions - unacknowledged by the DOJ - make it highly unlikely that contractually liberating the OEM distribution channel, without significantly more, can effectively serve as the prime vehicle for restoring OS competition. Such market changes include dramatically shrinking margins, price pressures, and slowing demand in the PC sector - trends that are the opposite of the high-flying economic indicia of the PC hardware market from 1995-98 when Microsoft's vertical restrictions foreclosed OEM distribution to its middleware rivals. In this current economic environment, provisions which merely give OEMs the ability to remove products or services, or that give OEMs the ability to make changes to the operating system, will not succeed in achieving the stated goal of the CIS. The competitive landscape of the PC sector today is one of rapid commoditization with shrinking R&D budgets.
Creating choice and differentiation in the PC sector is dependent upon two steps: First, the PFJ must fundamentally redefine the relationship between Microsoft and all OEMs by affirmatively transferring some design and bundling decisions from Microsoft to the OEMs (in the PC supply chain); second, the PFJ must create a regime in which OEMs have an economic incentive to choose alternative bundles of products and services for the Windows OS platform from other vendors, thereby encouraging competition on the merits in the applications, middleware and other non-OS markets. In order to accomplish these objectives SIIA proposes that Microsoft be required to license Windows to independent ISVs and software integrators (including platform sofware competitors) who would be protected by the same API disclosures, desktop configuration flexibility, and pricing nondiscrimination guarantees as provided to OEMs under the PFJ. More specifically, Microsoft should be required to license the base binary code of Windows (including new versions and upgrades of Windows at a reasonable time before shipping of that product to OEMs) to all third parties so that the licensees may create and license competitive bundles comprised of Windows and non-Microsoft applications, middleware, services and tools.77 This licensing proposal would foster wholesale-level competition for combined OS and application bundles, thereby making available critical systems integration services to OEMs seeking to provide alternative software packages to retail customers. The SIIA proposal recognizes the realistic limitations on OEMs in creating and defining alternative software bundles (including middleware) and therefore creates opportunities for systems integrators and others to "stand in the shoes" of the OEMs and exercise their same rights to modify and customize the Windows desktop and middleware selections. This remedy works in tandem with the ban on middleware bundling, the provisions regarding OEM restrictions, and the API and technical information disclosure. It would limit Microsoft's ability to choke off the development of new middleware and potential rival platforms by creating an alternative means for makers of those software products and services to distribute them to OEMs and, potentially, consumers. By producing potential rival, retail-level bundles of software applications and services with the OS, the licensing proposal could offer an important means to foster the technological development and consumer acceptance of non-Microsoft middleware and potential alternative platforms. Adoption of the licensing provision would result in at least three major benefits to consumers and competition. First, the provision would allow the market, rather than Microsoft, to determine the applications on, and configuration of, consumers' PC desktops. The license would limit Microsoft's ability to use its OS monopoly to favor its own products over competitors' software. End users would be able to choose among competing, customized bundles of applications that are as seamlessly integrated into the operating system as Microsoft's products are today. Second, in addition to to promoting consumer choice and creating competition for retail-level OS/Application bundles, the licensing proposal would help preserve competition in applications, e-commerce, and other markets that Microsoft has targeted with its illegal tactics. By giving these applications/services - and the investors, engineers, developers, and others behind them - an alternative means to obtain access to consumers, the licensing proposal would give competitors in these markets a new protection from Microsoft's anticompetitive tactics. Consumers would benefit from the new choices, new applications, and new services that would result. Third, with a variety of licensees potentially acting as systems integrators and resellers, this remedy would provide the OEMs an efficient way of procuring bundles of specialized software to resell to consumers.
The CIS states that the PFJ is designed to prevent recurrence of the same or similar practices that Microsoft employed to reach its current monopoly position.78 Microsoft's monopoly over the PC operating system market gives it a unique ability to appropriate for its sole use and benefit technology first developed by others. By embracing industry standard technology, Microsoft ensures that its products benefit from the innovations of others. By adding proprietary extensions to industry standards, Microsoft can effectively appropriate those standards for its sole benefit and can also extinguish the threat to Microsoft's proprietary standards posed by voluntary, open industry standards. The Court of Appeals affirmed that this is what Microsoft did to JAVA. It intentionally deceived JAVA developers and entered into exclusive ISV deals for distribution of Microsoft's own, incompatible version of JAVA.79 The Court explained that Microsoft fragmented the JAVA standard in order to "thwart Java's threat to Microsoft's monopoly in the market for operating systems," and to "`[k]ill cross-platform Java by grow[ing] the polluted Java market.'"80
The PFJ, however, does not restrict Microsoft's ability to modify, alter, or refuse to support computer industry standards, including JAVA, or to engage in campaigns to deceive developers of rival platform, middleware, or applications software. By choosing to support only its own, proprietary implementation of open industry standards, Microsoft can continue to exclude meaningful competition from alternative platform vendors. In addition, Microsoft will be in a position to dictate the interfaces and protocols by which products other than PCs, such as servers, handhelds, or telephones, can interoperate with PCs running Microsoft's desktop OS, and the applications that run on those PCs.
SIIA proposes as a remedy that the PFJ constrain Microsoft's ability to convert open industry standards into exclusive Microsoft protocols through "extension" or other unilateral conduct. Specifically, Microsoft should be enjoined from modifying, altering, sub-setting or super-setting any industry-standard Communication Interface or Security Protocol, except to the extent that such modified Communication Interface or Security Protocol is compliant with, and approved by, an independent, internationally recognized industry standards organization. Security Protocol should be defined as set forth in Appendix A. This proposed remedy would protect consumer choice in platform software by ensuring that consumers are not required to purchase only Microsoft applications and other software products in order to interoperate with Windows. It would foster innovation by ensuring that Microsoft has a business incentive, reinforced by the PFJ, to extend industry standards for sound engineering reasons, rather than anticompetitive foreclosure. The PFJ would require that Microsoft additions to open industry standards be approved as compliant with a voluntary industry standard available for support by all competitors; importantly, however, it would not otherwise restrict Microsoft from developing new technologies, interfaces, or standards in proprietary format.
Microsoft Office, a hybrid of application and middleware is a significant component of the current applications barrier to entry. The Court of Appeals relief standard in this case, tracking United Shoe, requires that a remedy "`ensure that there remain no practices likely to result in monopolization in the future.'"81 To foreclose prospective antitrust practices, it is settled law that a remedy is not limited merely to the proven violations, but should encompass "untraveled roads" the monopolist could use into the future to protect its market power: "when the purpose to restrain trade appears from a clear violation of the law, it is not necessary that all of the untraveled roads to that end be left open and that only the worn one be closed."82
The CIS states that the PFJ is designed to prevent recurrence of the same or similar practices that Microsoft used to reach its current monopoly position.83 The PFJ does not achieve these stated goals because the PFJ's API, pricing, exclusive dealing, and OEM flexibility provisions are all limited to Windows platform software. Due to the dominant market share of MS Office-around 95 percent of the business productivity suite market-Microsoft is dangerously positioned to evade any relief by repeating the same exclusionary and illegal acts employing Office, instead of Windows OS, to the same devastating effect upon the consumer. Moreover, as previously described, Office exposes its own set of APIs and can therefore essentially function as a middleware alternative to operating system software.
A remedy must cover MS office in order to foreclose Microsoft's ability to evade the PFJ's provisions by engaging in the same conduct with Office that is prohibited with Windows. Specifically, MS Office, the largest component of the applications barrier to entry, should be included in a number of provisions in order to prevent evasion of the remedy. These include:
As noted above, the existing scope of the API provisions is overly narrow since they seemingly require transparency in the OS/middleware interface, but not corresponding openness in the interface between either applications or Office and the Windows OS. Under the SIIA proposal, Office, Outlook, and JAVA would be encompassed by the Middleware definition in order to preclude Microsoft from evading the constraint of the remedy by binding Office, Outlook, or JAVA technology (each of which exposes APIs and can erode the applications barrier to entry) to the OS. Similarly, the scope of "multimedia viewing software" should be expanded from merely viewing digital content to encompass the entire spectrum of functionalities provided by Real Player, Windows Media Player, and the like, in order to prevent Microsoft from evading the middleware bundling provisions by simply segmenting its multimedia middleware into different sub-products or applications.
The PFJ lacks any general "catch-all" enforcement provision designed to stop Microsoft from taking intentional action to disable or adversely affect the operation of competing middleware or applications products. The CIS claims that the PFJ has the teeth needed to ensure that Microsoft cannot thwart the purposes or remedies of the PFJ, and that the PFJ will deprive Microsoft of the means with which to retaliate against, or hinder the development of, competing products.84 Unlike the District Court's interim decree in 2000, however, the PFJ inexplicably fails to include a general prohibition of such conduct, relying instead upon narrowly-drawn prohibitions limited to specific forms of conduct.
In order to remedy this glaring problem, SIIA proposes that the PFJ be altered so that Section C.3 of the 2000 Decree is restored verbatim: Microsoft shall not take any action that it knows will interfere with or degrade the performance of any non-Microsoft Middleware when interoperating with any Windows Operating System Product without notifying the supplier of such non-Microsoft Middleware in writing that Microsoft intends to take such action, Microsoft's reasons for taking the action, and any ways known to Microsoft for the supplier to avoid or reduce interference with, or the degrading of, the performance of the supplier's Middleware. In addition, Microsoft should be prohibited from promoting any standard as "open" unless it has standards-body approval. As is discussed in detail above, the Court of Appeals found that Microsoft had affirmatively deceived JAVA developers and improperly entered into exclusive deals with ISVs for distribution of Microsoft's own incompatible version of JAVA. Moreover, the district court's Findings of Fact are replete with findings, none of which were overturned on appeal, to the effect that Microsoft intentionally made it more difficult for Netscape and JAVA to run on the Windows platform. For instance, Judge Jackson found that the purpose of Microsoft's technical integration of IE "was to make it more difficult for anyone, including systems administrators and users, to remove Internet Explorer from Windows 95 and to simultaneously complicate the experience of using Navigator with Windows 95." 85 "Microsoft's refusal to respect the user's choice of default browser fulfilled Brad Chase's 1995 promise to make the use of any browser other than Internet Explorer on Windows `a jolting experience.' By increasing the likelihood that using Navigator on Windows 98 would have unpleasant consequences for users, Microsoft further diminished the inclination of OEMs to pre-install Navigator onto Windows."86 The obvious adverse impact on consumers of intentional interference with competing middleware and applications is evident: consumers are denied choice of software and the market is artificially tipped toward Microsoft products on a basis other than the performance of the products themselves. This is a classic way in which Microsoft's maintenance of its OS monopoly harms both competition and consumers. In order to ensure that Microsoft cannot intentionally degrade the performance of competitors' products, including middleware, such tactics should be specifically outlawed.
As noted previously, because it may be difficult for this Court to reach a conclusion regarding the PFJ without prefiguring a decision on nearly identical "live" issues in the State case currently before this Court, SIIA respectfully requests that this Court take this matter under advisement until the State case has concluded. Alternatively, this Court should adopt SIIA's proposed remedy, as described in these comments.
Dated: January 28, 2002 APPENDIX A DEFINITIONS OF "PLATFORM INTERFACES," "Platform Interfaces" means all interfaces, methods, routines and protocols that enable any Microsoft Operating System or Middleware Product installed on a Personal Computer to (a) execute fully and properly applications designed to run in whole or in part on any Microsoft Platform Software installed on that or any other computing device (including without limitation servers, digital telephones, handheld devices), (b) Interoperate Effectively with Microsoft Platform Software or applications installed on any other device, or (c) perform network security protocols such as authentication, authorization, access control, or encryption. "Interoperate Effectively" means the ability of two different products to access, utilize and/or support the full features and functionality of one another. For example, non-Microsoft Platform Software "Interoperates Effectively" with an application designed to run on Microsoft Platform Software if such non-Microsoft Platform Software can be substituted for the Microsoft Platform Software on which such application was designed to run, and nonetheless enable the application user the ability to access, utilize and support the full features and functionality of the application without any disruption, degradation or impairment in the functionality or features of the application. "Internet Browser" means software that, in whole or in part, (i) makes hypertext transfer protocol (HTTP) requests in response to user input; (ii) converts or renders hypertext markup language (HTML) and extensible markup language (XML) to any displayed form, or any intermediate representation with the intent to display it; (iii) displays or keeps in memory or stores in any way "cookies," which are named values sent from web servers to web browsers with the expectation that the browser send back the named values back to the server in future interactions; (iv) displays, keeps in memory or otherwise stores a collection of uniform resource locators (URLs) representing a history of a use's interaction with web servers; (v) displays or keeps in memory or otherwise stores "bookmarks," which are named URLs configurable by a user; or (vi) runs JavaScript programs or runs programs in any computer programming language which is broadly compatible with JavaScript. The standards and formats referenced in this definition include all successors to those standards and formats that may arise during the term of the Final Judgment. The technical elements identified in subsections (i) to (vi) include not only the forms of these functionalities as they currently exist and have existed in the past, but also as they come to exist in the future, even if they come to be known by different names. FOOTNOTES 13 Joint Status Report, United States v. Microsoft Corp., at 28 (D.D.C. filed Sept. 20, 2001). 14 CIS at 24 (citations omitted). 17 Microsoft III, 253 F.3d at 67. 22 Microsoft III, 253 F.3d at 64. 24 Microsoft III, Order at 1 (D.C. Cir. Aug. 2, 2001) (per curiam). 27 Microsoft III, 253 F.3d at 84. 29 See Charles James Defends The Deal, Business Week, Nov. 19, 2001, at 116. 42 James Senate Testimony at http://www.senate.gov/%7Ejudiciary/te121201f-james.htm. 46 Microsoft II, 147 F.3d at 946 49 PFJ at 7. (Emphasis added.) 50 Id. SIIA urges the Court to note that Section III.E requires "consistency with Section III.I.". 52 Microsoft III, 253 F.3d at 56. 55 Microsoft III, 253 F.3d at 103 (citation omitted). 57 Microsoft III, 253 F.3d at 67. 59 Microsoft III, 253 F.3d at 103. 66 Microsoft III, 253 F.3d at 75-77. 67 Microsoft III, 253 F.3d at 74 (citation omitted). 69 Microsoft III, 253 F.3d at 103 (citation omitted). 71 Microsoft III, 253 F.3d at 54-55. 74 Microsoft III, 253 F.3d at 73. 77 The licenses should, at a minimum, include the following protections and terms: (a) licensed third parties should have all the rights to modify the OS and IE desktops, links and related interfaces as provided to OEMs in Sections III.E and III.H of the PFJ; (b) licensed third parties should have all the rights of access to APIs and other technical information as provided to OEMs in Sections III.D and III.E of the PFJ. (c) licensees should be protected by the same OEM nondiscrimination safeguards provided in Sections III.A, III.B and III.F of the PFJ; (d) Microsoft should be required to provide complete transparency of its agreements with OEMs and others; (e) the licenses should be made available for a price equal to the lowest (per volume) price that Microsoft charges for any current version of the Windows OS to OEMs or other end user licensees, including enterprise customers, and any volume discounts should be standardized and published; and (f) Microsoft should be prohibited from taking actions to interfere with or degrade the interoperability of third-party applications with Windows. 79 Microsoft III, 253 F.3d at 75-77. 80 Id. at 76-77 (citation omitted). 81 Microsoft III, 253 F.3d at 103 (citation omitted). 82 Int'l Salt Co. v. United States, 332 U.S. 392, 400 (1947). |