Attached please find Novell Inc's Comment to the Proposed Settlement between Microsoft and the Department of Justice, pusuant to the Tunney Act. Please acknowledge receipt of this comment at your convenience.
FOR THE DISTRICT OF COLUMBIA
In a unanimous en banc decision, the District of Columbia Circuit affirmed the trial court's ruling that Microsoft Corporation ("Microsoft") violated Section 2 of the Sherman Act by unlawfully acting to maintain its monopoly over Intel-compatible PC operating systems. See United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001), cert. denied, 122 S.Ct. 350 (2001) ("Microsoft"). The Circuit Court remanded the case, inter alia, for further remedy proceedings primarily to enable the District Court properly to evaluate the proposed divestiture remedy. See id. at 105-07. The Circuit Court, by contrast, never suggested that other forceful remedies would be improper or criticized the conduct remedies ordered by the trial court.
On remand, the U.S. Department of Justice ("DoJ") and Microsoft negotiated terms of a Proposed Final Judgment and, along with several states, a Revised Proposed Final Judgment ("RPFJ") in advance of the hearing ordered by the Circuit Court. 66 Fed. Reg. 59,452 (Nov. 28, 2001). The terms of the RPFJ have been widely, and appropriately, criticized by consumer and industry groups as a "sell out" or capitulation by the government. See, e.g., James Barksdale, A Monopoly Unbound, Wash. Post, Dec. 4, 2001, at A25; Lawrence Lessig, It's Still a Safe World for Microsoft, N.Y. Times, Nov. 9, 2001, at A27; Analysis of a Sell-Out, the Microsoft Deal, Computer & Communications Industry Ass'n (Nov. 21, 2001), available at http://www.ccianet.org/papers/ms/sellout.php3 (visited Jan. 24, 2001). Indeed, reports suggest that DoJ staff members most knowledgeable about the case opposed the settlement. See Letter from Rep. John Conyers, Jr. to U.S. Att'y Gen. John Ashcroft (Nov. 6, 2001), available at http://www.house.gov/conyers/pr110601.htm (visited Jan. 24, 2001). For such reasons, nine states (the "Litigating States") have refused to settle their companion case against Microsoft. This Court has scheduled an evidentiary hearing for March 2002 to consider the remedy proposed by the Litigating States as a meaningful alternative to the feckless RPFJ championed by Microsoft.
As required by the Tunney Act, 15 U.S.C. § 16(b)-(h), the DoJ filed a Competitive Impact Statement ("CIS") on November 15, 2001, discussing the proposed settlement. 66 Fed. Reg. 59,452, 59,460 (Nov. 28, 2001). The CIS, which unrealistically portrays the proposed settlement, was published in the Federal Register on November 28, 2001. The following Comments on the RPFJ are submitted pursuant to 15 U.S.C. §16(d) on behalf of Novell, Inc. ("Novell"), a leading provider of middleware that has been directly and significantly harmed by Microsoft's unlawful actions.(1)
In evaluating the proposed settlement under the Tunney Act, the Court must scrutinize the language of the proposed remedy, rather than rely upon the pollyannaish interpretation propounded in the CIS. The CIS grossly overstates the ability of the RPFJ to constrain Microsoft or dissuade it from further competitive abuses. Whether as the result of indifference on the part of DoJ or crafty negotiating by Microsoft, the RPFJ is replete with limitations and loopholes that utterly deprive it of effectiveness. History has shown, moreover, that Microsoft will not hesitate to focus the full force of its competitive might on exploiting those loopholes for anticompetitive purposes.
Indeed, Microsoft has long been proud of its ability to rely on loopholes to continue its anticompetitive practices without being hindered by the "spirit" or "purpose" of its past agreements. For example, in 1997, one of Microsoft's lawyers, Charles F. Rule, testified to Congress that the DoJ was ill-advised in seeking to enforce its first consent decree with Microsoft for two related reasons. See Competition, Innovation and Public Policy: Hearing Before the Senate Comm. On the Judiciary, 105th Cong. (Nov. 4, 1997) (statement of Charles F. Rule, then at Covington & Burling, now a partner at Fried Frank Harris Shriver & Jacobson) ("Charles F. Rule Testimony"). Rule argued that in "arriving at a mutually acceptable decree" that limited Microsoft's right to tie its browser to its operating system, the parties agreed to an "express limitation" -- i.e., a loophole -- that permitted Microsoft to develop "integrated products." Id. Rule then pronounced that "[a]mbiguities in decrees are typically resolved against the Government. In addition, the Government's case must rise or fall on the language of the decree; the Government cannot fall back on some purported 'spirit' or 'purpose' of the decree to justify an interpretation that is not clearly supported by the language." Id. (citation omitted). Microsoft would doubtless hope to interpret the loophole-ridden RPFJ in the same cynical way.
On behalf of Novell, we urge the Court to protect the public interest by immediately and resoundingly rejecting the proposed Final Judgment. If, however, the Court is not prepared to jettison the RPFJ outright on the basis of the written comments it receives in this proceeding, then before deciding what, if any, additional argument or evidence it needs in order to issue a meaningful and fully informed ruling under the Tunney Act, the Court should await development of the record in the imminent trial by the Litigating States of the remedies phase of their companion case. Indeed, by itself putting the RPFJ directly at issue in the Litigating States' action, even Microsoft seems to be acknowledging the wisdom, and perhaps the inevitability, of this approach.(2)
The RPFJ utterly fails to protect the public interest, because it offers no relief against Microsoft's monopolistic abuses and it fails to "pry open to competition a market that has been closed by defendants' illegal restraints."Int'l Salt Co., Inc. v. United States, 332 U.S. 392, 401 (1947). Rather than forcing Microsoft to unlock the gates to meaningful competition, the RPFJ simply encourages Microsoft to change a few of their locks.
The failings of the RPFJ are numerous and overlapping. In these Comments, Novell will focus on only five of the RPFJ's most prominent defects:
The RPFJ Allows Microsoft to Decide for Itself the Scope of its Responsibilities to Restore Competition: The CIS recognizes that "[a]number of definitions are essential to understanding the proper construction and the scope of the requirements contained in the Proposed Final Judgment." CIS, 66 Fed. Reg. at 59,464. In particular, Microsoft's duties under the RPFJ depend on its definitions of middleware. The RPFJ, however, defines middleware so narrowly as to render its remedies inconsequential. See RPFJ, 66 Fed. Reg. at 59,459. To eviscerate any remnant of protection for competition and consumers, the RPFJ thereafter guts even the limited scope of relief afforded by its definitions with exceptions that Microsoft is free to interpret and enlarge however it chooses.
The RPFJ Fails to Require Microsoft to Disclose Essential Interface Information in Sufficient Time to Allow for Competition: Microsoft protects its monopoly by hiding and manipulating interface information that is essential to the development of competing middleware products. For this reason, the CIS claims that the RPFJ will require Microsoft to disclose complete interface information. See CIS, 66 Fed. Reg. at 59,460. In fact, the disclosure requirements of the RPFJ are illusory, because: (1) they are limited in scope and subject to continued manipulation by Microsoft; (2) they are trumped by an exception for "security information" that is so broad as to render any remaining obligations trivial; and (3) they fail to obligate Microsoft to disclose interface information in time to allow for meaningful competition.
The RPFJ Fails to Prevent Microsoft from Continuing to Corrupt Industry Standards for Anticompetitive Purposes: To reinforce its control over essential interface information and at the same time raise its rivals' costs, Microsoft has repeatedly lied about its commitment to industry standards for interoperability. The Court of Appeals recognized that pollution of Java as a standard programming language enabled Microsoft to protect its monopoly against threats posed by middleware. See Microsoft, 253 F.3d at 76-77. Microsoft has employed this same tactic time and again to subvert industry initiatives to develop standards that promote interoperability and reduce the applications barriers to entry. The RPFJ, however, is shockingly silent about such matters.
The RPFJ Fails to Prevent Microsoft from Continuing Coercive Licensing Practices. Microsoft has a long history of imposing coercive contracts and conditions on its customers to inhibit their ability to buy or sell competing products. See Microsoft, 253 F.3d at 64. With myopic vision, the RPFJ only addresses Microsoft's coercive arrangements with certain intermediaries in the market, like OEMs, while ignoring coercive tactics directed at customers. See CIS, 66 Fed. Reg. at 59,460, 59,471.
The RPFJ Fails To Adopt Effective Enforcement Procedures. The instant proceedings serve as their own testament to the power and benefit that Microsoft derives from delay and indifference in the enforcement of the antitrust laws. Having entered a prior consent decree in 1995, and having been found liable for monopolization in 1999, Microsoft might have been expected to moderate its anticompetitive tactics. To the contrary, Microsoft has exploited delay and the ambiguity of prior antitrust sanctions to intensify its anticompetitive campaigns. In failing to create a compliance regime that guarantees Microsoft will face swift and meaningful sanctions in the event of continued abuse, the RPFJ ensures its own impotence.
Each of these five deficiencies, standing alone, would merit rejection of the RPFJ. Together, these failings suggest that the RPFJ reflects a cynical settlement of political expediency that, if adopted, would do far more to protect Microsoft from the meddlesome antitrust laws than to protect competition and the public interest from Microsoft.
Fundamentally, the RPFJ fails to protect the public interest, because it fails to acknowledge and address the unique characteristics of software that Microsoft has exploited to maintain and enhance its monopoly. Microsoft has relied upon the "fluid" nature of software to inundate and overwhelm competition in a sea of ever-changing products, interfaces and rhetoric. Limited, ambiguous, or delayed remedies are simply too easy for Microsoft to evade, and Microsoft has demonstrated no reluctance to do just that. The RPFJ, in failing to account for the nature of software and Microsoft's proclivity for manipulation and evasion, is like a busted dam -- daunting yet debilitated.
The judgment against Microsoft primarily rests on the conclusion that Microsoft has unlawfully interfered with the development, marketing, and use of middleware offered by competitors.(3) Any credible remedy, therefore, must deprive Microsoft of the power to foreclose competition by driving middleware alternatives from the market.
But what is middleware? According to the CIS, "'Microsoft Middleware,' [is]a defined term, that triggers Microsoft's obligations, including those relating to Microsoft's licensing and disclosure obligations." CIS, 66 Fed. Reg. at 59,464. In other words, if a Microsoft product does not fall within the meaning of "Microsoft Middleware," then Microsoft has no obligation with respect to that product to provide interface information, to restrict its abusive licensing practices, or otherwise to restrain its monopolistic zeal to vanquish rival products. Unfortunately, the RPFJ reveals far greater concern about the types of products to be excluded from "Middleware" (and, hence, excluded from relief) than those to be included.(4)
Indeed, the RPFJ defines "Microsoft Middleware" so narrowly as to render any safeguards for consumers and competition inconsequential. Worse, the RPFJ allows Microsoft -- hardly the guardian of the public interest -- to decide what future products will, and will not, be considered "Microsoft Middleware!" Thus, the RPFJ puts the fox in charge of the hen house.
As noted above, the scope of protection afforded by the RPFJ depends entirely on its definition of "Microsoft Middleware." Rather than defining Microsoft Middleware in a manner that provides a concrete foundation for meaningful relief, the RPFJ offers a convoluted definition that provides a foundation no stronger than the shifting sands.
Specifically, the RPFJ defines "Microsoft Middleware" as "software that provides the same or substantially similar functionality as a Microsoft Middleware Product." RPFJ, 66 Fed. Reg. at 59,459. In turn, the RPFJ specifies two criteria for "Microsoft Middleware Products." See id. First, the RPFJ simply chooses a few types of software-- namely, Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express, and their successors -- to be deigned "Microsoft Middleware Products." Id.
Second, the RPFJ declares that other types of software may be considered "Microsoft Middleware Products" if (and only if) three conditions are met; specifically, if the software:
Together, these definitions of "Middleware" assure that the protections of the RPFJ will never apply to more than a few forms of middleware and, in particular, to middleware that Microsoft has already crushed by anticompetitive means. Indeed, the inconsequential scope of the RPFJ will embolden Microsoft in its continuing quest to extinguish any new, or competitively significant, middleware offered to consumers.
The RPFJ further ensures its own futility by allowing Microsoft to decide when, or if, to trigger any duty to comply. Thus, to qualify as a "Microsoft Middleware Product" or as "Microsoft Middleware," software must at some time be distributed separately by Microsoft from one of its "Windows Operating System Products." Id. Nothing in the RPFJ, however, prohibits Microsoft from rolling all important middleware into its operating system products. To the contrary, the RPFJ remarkably provides that "[t]he software code that comprises a Windows Operating System Product shall be determined by Microsoft in its sole discretion." RPFJ, 66 Fed. Reg. at 59,459 (emphasis added).
To make its scope even more trivial (if that is possible), the RPFJ further provides that software code will not be considered either "Microsoft Middleware" or a "Microsoft Middleware Product," unless it is "Trademarked" by Microsoft. See id. at 16. In other words, even if Microsoft finds it necessary, for some reason, to distribute new software separately from a "Windows Operating System Product," such software still will not fall within the remedy, if Microsoft decides in its sole discretion not to seek trademark protection for the product. This is absurd.(5)
Finally, even assuming the RPFJ retains some sliver of significance despite its slight scope, additional broad and pliable exclusions assure that Microsoft would be well protected against any meaningful duty to comply. For example, the RPFJ provides that any "Microsoft Middleware" must "include at least the software code that controls most or all of the user interface elements of that Microsoft Middleware." Id. Thus, Microsoft could avoid any compliance duties simply by breaking up code for middleware into small units of code, none of which "controls most or all of the user interface elements."(6) Likewise, the RPFJ excludes from the definition of "Microsoft Middleware" any "updates" to existing "Microsoft Middleware Products," unless Microsoft, in its sole discretion, decides to label the update a "major version" of the product. Id. To avoid compliance, therefore, Microsoft need only rely on "minor" updates to impede competition, or call every update "minor," regardless of import.
In sum, the RPFJ ultimately allows Microsoft to decide for itself the scope of its duties. In view of Microsoft's demonstrated enthusiasm for legal loopholes, it is hard to imagine a remedy proposal of lesser value.
The faulty (and nearly non-existent) scope of the RPFJ is made especially clear when it is compared with the broader definition of middleware proposed by the Litigating States in their proposed remedy. In contrast to the RPFJ, the Litigating States define middleware in conformity with the judgment against Microsoft and would not permit Microsoft to continue its abusive practices simply by making discretionary and trivial changes to its own business practices.(7) Plaintiff Litigating States' Remedial Proposals at 34-35 (Dec. 7, 2001), United States v. Microsoft Corp., No. 98-1232 ("States' Remedy").
Remarkably, the DoJ's own prior submission to the Court belies any arguments that the RPFJ is sufficiently broad in scope to protect the public interest. Although Microsoft hopes to limit any relief to forms of middleware that no longer threaten its monopoly, the DoJ has explained:
Plaintiff's Memorandum in Support of Proposed Final Judgment ("DoJ Mem. In Supp.") at 27-28, United States v. Microsoft Corp., No. 98-1232 (emphasis added).
Elsewhere, the DoJ has admitted that important new middleware technologies that must be protected from Microsoft's tactics may include "voice recognition software, media streaming technology and e-mail software," as well as "many server-based middleware products that have historically been sold or distributed separately by Microsoft or other firms, including a directory service (Active Directory), an application server (Microsoft Transaction Server - MTS), and a web server (Internet Information Server - IIS)". Id. at 28; Affidavit of Rebecca Henderson, attached as Exhibit to DoJ Mem. Of Supp. ("Henderson Aff.").
In sum, the RPFJ protects Microsoft, rather than the public, by limiting restrictions on Microsoft monopolistic tactics to forms of middleware that Microsoft has already, and unalterably, made irrelevant. Meanwhile, the RPFJ will only fuel Microsoft's zeal to replicate its unlawful victories over Netscape and Java in its continuing efforts to extinguish other middleware threats to its monopoly.
Perhaps the most insidious characteristic of the RPFJ is that it appears specifically written to impart antitrust immunity to Microsoft for using the same unlawful tactics against competition threatened by directory services middleware that it used to destroy competition threatened by Netscape's internet browser. Remarkably, the RPFJ would not require Microsoft to lift a finger to avail itself of such protection. With utter disregard for the public interest, the RPFJ attempts to legitimize conduct that has already been declared unlawful by both the District Court and the Court of Appeals.
Specifically, the RPFJ permits Microsoft to engage in any anticompetitive tactic of choice against middleware threats, so long as Microsoft chooses to bundle, bind, or even just market, competitively critical middleware with its monopoly operating system products. Although memories can be short in the fast-paced technology industry, it defies credulity that the RPFJ ignores six years of antitrust litigation and the Court of Appeals' judgment against Microsoft, which directly resulted from Microsoft's simple, but unlawful, decision to combine middleware with its monopoly operating systems.
As discussed below, there can be no question that directory services software, such as Novell's "eDirectory,"TM Microsoft's "Active Directory," and iPlanet's "Directory Server," have become competitively critical links between the desktop and network computing that threaten Microsoft's monopoly. For this reason, it is hardly surprising that Microsoft hopes to insulate directory services software from antitrust scrutiny. See Defendant Microsoft Corporation's Remedial Proposal at 9 (Dec. 12, 2001), United States v. Microsoft Corp., No. 98-1232 (arguing that "directory services and management softwareare plainly not 'middleware' within the meaning of the Court of Appeals' decision"). Yet, Microsoft offers only rhetoric to support its wish for directory services middleware to be excluded from any remedy in this case.
Indeed, Microsoft refutes its own claim. Microsoft notes that "[a]s the Court of Appeals used the term, 'middleware' refers to software products that are capable of running on multiple client operating systems and that could provide a general-purpose platform for applications, such that 'developers might begin to rely upon APIs exposed by the middleware for basic routines rather than relying upon the API set included in Windows' and the middleware 'could take over some or all of Windows' valuable platform functions.'" Id. (citing Microsoft, 253 F.3d at 53). Technology consumers, middleware competitors, and independent experts all agree that directory services software falls squarely within even Microsoft's definition of "middleware."
For example, Internet2 is a consortium of technology consumers that includes over 180 universities working in partnership with industry and government on advanced network applications and technologies. Internet2 explains:
Internet2 Middleware, at http://middleware.internet2.edu/ (visited Jan. 22, 2002) (emphasis added).
Likewise, the well-respected Gartner Group, a leading provider of technology research, has emphasized that "directory services" are playing an increasingly important role as middleware platforms for integrating diverse applications and other forms of software, including other middleware products and operating systems. See Conference Presentation, Active Directory, Gartner Group at 5, available at http://www.gartnerweb.com/public/static/win2000/actdirect.pdf (visited Jan. 23, 2002). The Gartner Group notes:
Thus, directory services fall squarely within Microsoft's admitted definition of middleware. See Microsoft's Remedial Proposal at 9 (citing Microsoft, 253 F.3d at 53).(8) Directory services expose APIs as an alternative to Windows APIs, and serve as platforms for diverse applications.
In view of the competitive importance of directory services as middleware, it is hardly surprising that Microsoft has attempted to drive products that compete with its Active Directory software from the market by using the same unlawful tactics that it used against Netscape. For example, Microsoft has commingled code to bind Active Directory to its Windows operating systems. In recent versions of Windows, Microsoft has also manipulated interfaces specifically to prevent users from replacing Active Directory with eDirectory. (Although eDirectory can be used with recent Microsoft operating systems, it can only be used concurrently with Active Directory.)(9) Second, Microsoft has undermined the use of a standard industry protocol in this case Light Directory Access Protocol or LDAP in favor of proprietary protocols that inhibit development of multi-platform (or non-Microsoft) networks.(10) Third, Microsoft has employed coercive licenses, called client access licenses or CALs, to discourage users from installing non-Microsoft directory services.(11)
More than surprising, however, is that the RPFJ will sanction such unlawful conduct for the simple reason that Microsoft has had the foresight (in light of this litigation) to decide against ever distributing Active Directory separately from Windows. Although Microsoft's decision, standing alone and without regard to any anticompetitive consequences, will exempt Microsoft's conduct relating to Active Directory from antitrust scrutiny under the RPFJ, the notion that such conduct does nothing to entrench Microsoft's monopoly is preposterous.
The next extraordinary deficiency of the RPFJ is the manner in which it purports to require Microsoft to disclose critical interface information that would allow for the development and effective implementation of competing middleware products. The disclosure requirement of the RPFJ can be summarized as: (1) too little; (2) too late; and (3) too full of loopholes. In fact, the RPFJ would expressly allow Microsoft to continue the same anticompetitive practices that have already enabled it to buttress its monopoly.
The RPFJ defines interface information so narrowly and incompletely that any compliance by Microsoft with its disclosure requirements would have little, if any, effect. The RPFJ includes the following definitions:
RPFJ, 66 Fed. Reg. at 59,458.
The first, and most obvious, defect of the proposed disclosures is the scope of Microsoft's duty. Under the definitions of the RPFJ, Microsoft would need only to disclose certain interface information affecting interoperability of "Microsoft Middleware" and a "Windows Operating System Product." See id. at 59,459. As discussed above, those terms are defined by the RPFJ to allow Microsoft to avoid compliance altogether, because "Microsoft Middleware" is defined absurdly narrowly and "Windows Operating System Products" are defined as whatever Microsoft wants them to be. See id. Microsoft's history makes clear that it will simply evade this remedy by declining ever again to offer middleware products separately from its operating systems (or at least it will not assert trademark protection for them).
Second, the interface definitions fail to articulate an objective standard for evaluating Microsoft's compliance. To date, Microsoft has never admitted that it has withheld interface information to competitors; instead it points to volumes of information it provides to independent developers through its Microsoft Development Network (MSDN). Meanwhile, it is obvious to competitors and independent observers that while Microsoft has often published interface information that allows competing products to work with Microsoft's operating system products, it frequently refuses to publish information that allows competing products to work well with Microsoft's productsor in the same way as Microsoft's products. Indeed, Microsoft has notoriously allowed its own programmers and developers to access and rely upon secret or unpublished APIs, calls, or other interface information to assure full interoperability of its products, while forcing competitors to use only limited sets of information that allow for "interoperability" -- but only in inefficient and constrained ways.(12) Nothing in the RPFJ clearly prohibits Microsoft from disclosing selective interface information that provides for limited interoperability. Indeed, paragraph E. of the RPFJ makes clear that Microsoft need not offer any better "Documentation" than it does at the present time. See id. at 59,458. For all the foregoing reasons, the information currently available has proven grossly inadequate to allow for meaningful competition. See id.
The RPFJ acknowledges that disclosures of interface information must be sufficiently timely to enable competing providers of middleware to develop alternatives in a commercially reasonable time frame. The CIS explains:
CIS, 66 Fed. Reg. at 59,468 (emphasis in original).(13)
Notwithstanding the wishful (and unrealistic) analysis of the CIS, the language of the RPFJ fails to offer any meaningful assurance of timeliness. The specified date for release of interface information for new middleware products is the last "beta" release, which is typically very shortly before the final version of the software is released to the public. Such beta releases are generally made a year or a year and a half after early code is provided to Microsoft operating systems and applications developers. In effect, under current practices the proposed finding would allow Microsoft to give its own middleware developers a year and one-half head start over competitors.
In fact, the head start the RPFJ affords Microsoft is likely to be far longer (or even infinitely long). By triggering the disclosure obligation on the date of the "last" beta release that includes at least 150,000 testers, the RPFJ would, once again, allow Microsoft to decide if and when (if ever) the disclosure obligation would take effect. Nothing in the RPFJ would prevent Microsoft from delaying the "final" beta release for more than a year and a half, or even from deciding to test new software exclusively in stages released to groups of less than 150,000 testers.
The RPFJ has been described as "Swiss cheese without the cheese." Of the numerous loopholes and deficiencies of the RPFJ, none is larger than the broad and general exclusion it affords Microsoft for "security" information, as follows:
1. Require Microsoft to document, disclose or license to third parties:
RPFJ, 66 Fed. Reg. at 59,455-56.
DoJ attempts to justify this security exception on grounds that "[it] is a narrow exception, limited to specific end-user implementations of security items such as actual keys, authorization tokens or enforcement criteria, the disclosure of which would compromise the security of 'a particular installation or group of installations' of the listed security features." CIS, 66 Fed. Reg. at 59,472. In fact, this exception is fatal to the efficacy of the RPFJ. Much of what software developers like Novell need in order to develop products that efficiently interoperate with Microsoft Windows products is now being encrypted by Microsoft.
Under the rubric of security, Microsoft harms interoperability by manipulating the encryption, signing or tagging of calls made between its operating systems and middleware. Encrypted or signed calls made by Microsoft's operating systems can be seen by competing middleware, but either cannot be read by them or the calls cannot be executed properly and with full function. Calls made by competing server operating systems are rejected by Microsoft's products because they are not encrypted or signed in the Microsoft way.
Microsoft, for example, now encrypts information exchanged between its directory service (Active Directory) and its operating systems. The effect of such "security" is to prevent Novell's eDirectory or other directory services from replacing Active Directory in a network. Even if Novell discovers, or is provided with, the interfaces between Active Directory and Windows, Microsoft's encryption of the information exchanges will effectively prevent the use of an alternative directory service. This tactic, moreover, could be replicated wherever middleware exchanges information, or calls, with Windows.
Although encryption or signing of calls may, in fact, promote security, there is no legitimate reason for such security methods to harm interoperability. In simplest terms, information security is generally afforded by encrypting or "locking up" sensitive information and safeguarding the "keys" to those locks. Rather then relying on well established technologies to protect the "keys" to sensitive information, Microsoft routinely prevents competitors from using the same types of locks that its uses for its own products. This tactic unnecessarily inhibits interoperability, because information security invariably depends not on the type of lock that is used (since a variety of tamper-proof locks have been developed), but solely on protection of the keys.(14) Microsoft routine ignores such distinctions to enable it to harm interoperability under the rubric of security.
In sum, the "security" exception to the RPFJ harms, rather than protects, the public interest. As interpreted by Microsoft, the exception will enable it to withhold information that is irrelevant to securing networks from hacking, viruses and the like, but highly relevant to securing networks from meaningful competition.
As recognized in the CIS and D.C. Circuit Court opinion, Microsoft has prevented competitors from offering meaningful Middleware alternatives in three main ways: (1) Microsoft has taken advantage of the fluidity of software to continually reconfigure its products in ways that make it difficult or impossible for even superior middleware offerings of competitors to remain viable; (2) Microsoft has refused to disclose interface information that would enable competitors to offer middleware products that operate effectively; and (3) Microsoft has engaged in coercive sales and marketing tactics that force distributors and consumers to favor even inferior Microsoft products over those of competitors. See CIS, 66 Fed. Reg. at 59,461.
Microsoft's refusal to disclose meaningful and timely interface information has been especially damaging to competitors, like Novell, who have repeatedly demonstrated their ability to develop superior alternatives to Microsoft products in the increasingly rare instances in which they have been able to obtain, or ascertain on their own, the critical interface information that allows for the effective interoperation of their middleware with Microsoft operating systems. As a result, the public is denied the benefits of innovation and the opportunity to choose among competing alternatives.
The CIS recognizes that meaningful disclosure of interface information by Microsoft is essential to effective relief. The CIS explains: "[T]he effect of Section III.D [of the RPFJ] is to assure to Non-Microsoft Middleware meaningful access to the same services provided by the operating system as those available to Microsoft Middleware. Microsoft Middleware will not have access to any hidden or proprietary features of Windows Operating System Products that might allow it to operate more effectively." Id. at 59,468. Unfortunately, the RPFJ again fails to deliver on DoJ's purported goal.
In contrast to the RPFJ, a meaningful remedy must account for the fact that Microsoft manipulates interface information in a variety of ways to preclude competition. Although too numerous to recount, Microsoft's tactics include:
The typical result of such tactics is that Microsoft makes competing products appear inferior to Microsoft's products. Microsoft's actions may make a competing product appear slower, require more memory, or perform with limited functionality. These tactics also enable Microsoft to persuade customers to buy Microsoft's inferior and/or more expensive products simply to avoid Microsoft's roadblocks.(15)
The remedy proposed by the Litigating States, in contrast to the RPFJ, would prevent continued exploitation and manipulation of critical interface information by Microsoft and thereby protect the public interest.
First, the Litigating States have proposed definitions of interface information that clearly obligate Microsoft to provide the same interface information that is made available to its own programmers and developers to allow for "full" and "efficient" interoperability of products. See States' Remedy at 31-32. Further, the Litigating States' proposal would provide for monitoring and review of Microsoft's disclosure by creating a clean room in which qualified industry representatives could examine and test the underlying computer code. See id. at 11-12.
Second, the proposed remedy of the Litigating States, in contrast to the RPFJ, would require disclosures to be sufficiently timely to allow for meaningful competition. The Litigating States define "Timely Manner" to mean:
Id. at 36-37.
Third, the Litigating States would close the gaping "security" loophole of the RPFJ by requiring disclosure of information that allows competitors to participate with Microsoft in security mechanisms without compromising security.
Although the D.C. Circuit expressly held that Microsoft acted to protect its monopoly through undermining industry standards by deceiving software developers, the RPFJ fails to address this concern at all. Industry standards are often the key to interoperability among products that must communicate with each. Time after time, Microsoft has undermined or corrupted such standards to prevent competing middleware products from interoperating effectively with its dominant operating systems.
For example, Kerberos is an industry standard for encryption, in which certain fields are reserved for optional use. Microsoft, however, has used one of those fields to produce its own proprietary version of the standard. In itself, this is unobjectionable.
Microsoft, however, has gone one step further: it has manipulated its operating systems and middleware so that they will use and accept only the Microsoft version of the Kerberos standard.(16) This is diametrically contrary to the purpose for which standards, even with optional fields, are developed. Optional fields are included in standards to enable firms to add information to a message. Ordinarily, if an optional field is used in creating standard messages, those messages can still be sent and received among all products that comply with the standard. In such cases, the information included in the optional field may simply be ignored. Optional fields are never, however, intended to enable a firm -- i.e., Microsoft -- to subvert the standard and preclude its widespread usage.(17)
Thus, by polluting industry standards, such as Java and Kerberos (among others), Microsoft can further impede the use and development of competing middleware. Any calls encrypted with Kerberos sent by Microsoft Windows can be read only by other Microsoft Middleware and not by Novell's middleware. Similarly, Novell's middleware cannot send calls encrypted with Kerberos (the industry standard), because Windows will reject them.
In contrast to the RPFJ, the remedy proposed by the Litigating States addresses the problems created by Microsoft's manipulation of industry standards in two complementary ways. First, by requiring meaningful disclosures of interface information, the Litigating States would effectively impair Microsoft's ability to corrupt third party standards surreptitiously. Second, the Litigating States' proposal would expressly preclude Microsoft from misrepresenting its compliance with industry standards or imposing proprietary (i.e., Microsoft-owned) versions of such standards on the industry. See States' Remedy at 20-21.
As recognized in the RPFJ, Microsoft has a long history of imposing coercive contracts and conditions on its customers to inhibit their ability to buy or sell competing products. See RPFJ, 66 Fed. Reg. at 59,453-55. Once again with myopic vision, the RPFJ ignores the full scope of Microsoft's abusive contracts. Specifically, the RPFJ addresses only Microsoft's arrangements with intermediary technology vendors like OEMs. See id. Microsoft, however, has redirected its muscle at direct purchasers of its software.
Microsoft, for example, forces networking customers to purchase Client Access Licenses or "CALs." A CAL is merely one example of coercive licenses directed at users, rather than intermediaries. In connection with Windows 2000, Microsoft began to require customers to purchase a CAL whenever the customer uses a device that authenticates (i.e., identifies) itself and its relation to other elements of the network with Microsoft's Active Directory middleware. In other words, in addition to requiring users to purchase a license for using Windows 2000 on a server, Microsoft also requires users to purchase enough CALs to cover the maximum level of devices that will have concurrent access to that server.
The beauty of a CAL, from Microsoft's standpoint, is that it raises prices for Microsoft software, while at the same time raising the costs to users of using non-Microsoft middleware. The Gartner Group explains:
See Win2000 Licensing: Raising Prices, Squeezing Competitors, Gartner Group (Feb. 16, 2000) (italics in original) (boldface added).
Microsoft's CAL licensing policy forecloses competition and reduces consumer choice, because it forces customers to pay Microsoft, even if they prefer to use non-Microsoft middleware. For example, if a customer has fifty personal computers attached to a network composed of nine Novell servers and one Windows XP server, and the customer uses Microsoft's dominant email software, "Exchange" (or any other software that authenticates to Active Directory), then the customer will need to buy fifty CALs from Microsoft -- even if the customer would prefer to use Novell's eDirectory for all authentication services.
Why? Because the customer has no choice: (1) Microsoft bundles Active Directory with Windows 2000 and Windows XP; (2) Microsoft has technologically prevented Novell's eDirectory from replacing Active Directory to provide authentication services for Microsoft products like Exchange; and, therefore (3) virtually all network devices require "access" to Active Directory which must be paid for under a Microsoft CAL!
Further, the CAL policy coerces customers into replacing all server software with Microsoft software. Otherwise, the customer will be forced to pay a substantial tax to Microsoft simply to be able to use a competitor's networking software. In the foregoing example, the customer would need to pay for fifty CALs regardless of the number of its ten servers that it converts to Windows XP or Windows 2000. Because Microsoft loads the bulk of pricing into the CALs, rather than into software licenses for its server software, the net effect of this strategy is make it prohibitively expensive for customers to continue to operate servers with non-Microsoft software, such as Novell's NetWare and/or eDirectory, even if they would prefer to do so. In many instances, Microsoft's strategy would effectively force a customer to pay twice for networking software if it had the temerity to rebuff Microsoft by insisting on using a competitor's networking middleware, rather than Windows 2000 or Windows XP (and Active Directory).
The significance of CALs in the overall cost to customers is shown by Microsoft's own estimated retail prices. Microsoft estimates that the Windows 2000 Server license sells at around $799.(18) This is also the price of twenty CALs. Thus, using Microsoft's own estimates, as soon as the customer has more than twenty client PCs, the cost of the CALs is greater than the cost of the server license itself. Most enterprises will use far more than twenty client PCs in a network and the greater the number of client PCs, the greater the relative significance of CALs to the customer's overall cost. As a result, customers with large networks are essentially forced to pay for Microsoft's server software, whether or not they prefer that software or even use it. Eventually, however, many customers simply cannot afford to pay the tax imposed by Microsoft for using even superior networking software offered by its competitors.
In sum, Microsoft has repeatedly devised coercive licenses that raise costs to users of non-Microsoft products. The ability of consumers to avoid CALs is ever diminishing as more and more applications that authenticate only to Active Directory are aggressively promoted by Microsoft. By changing the way it charges for CALs in recent versions of Windows, Microsoft assures "that it makes more money while making it difficult to cost-justify the use of alternative vendors' products." Win2000 Licensing, Gartner Group, supra. Here again, the RPFJ gives Microsoft a mandate to monopolize by limiting one set of coercive licensing practices while condoning another.
The RPFJ's enforcement provisions, while elaborate and creative, fail to ensure Microsoft's full and timely compliance with its obligations. The RPFJ fails to impose meaningful time limits on enforcement proceedings, it fails to threaten adequate sanctions to deter Microsoft from ignoring its duties, and it fails to appoint a Special Master to facilitate enforcement. These failings virtually guarantee Microsoft's non-compliance.
In failing to impose time limits on enforcement review and resolution, the RPFJ will allow complaints against Microsoft to languish. Under the RPFJ, a complaint would require an investigation by the DOJ to be followed, to the extent appropriate, by judicial proceedings before this Court. Any enforcement matter before the Court would be complex, even with the able assistance of the Technical Committee. As those investigations crept along, Microsoft would persevere. The history of this action shows that Microsoft sees no reason to take a "time out" during periods of antitrust review. Indeed, Microsoft effectively used the time since the entering of the consent decree to complete its annihilation of Netscape's threat to its monopoly. As in its campaign against Netscape, by the time any sanctions under the RPFJ are imposed, challenged conduct will have long since taken its toll and Microsoft will have already repositioned its monopolistic artillery.
Given Microsoft's history of thumbing its nose at the antitrust laws, any remedy must include severe penalties for non-compliance. Absent powerful deterrents, any final judgment in this case will have no more influence over Microsoft than the Treaty of 1839 had over Germany when it decided to invade Belgium in 1914. German Imperial Chancellor Theobald von Bethmann-Hollweg, in an August 4, 1915 conversation with Sir Edward Goschen, British Ambassador to Germany, characterized the Treaty, which guaranteed Belgian neutrality and which had been signed by Germany, as "a scrap of paper," at the very time that the Imperial German Army had begun its invasion of Belgium. Sir E. Goschen, Report to Sir Edward Grey, British Foreign Secretary, 1914, available at http://library.byu.edu/~rdh/wwi/1914/ paperscrap.html(visited Jan. 18, 2002).
The enforcement provisions proposed by the Litigating States are far more likely to disarm Microsoft than the RPFJ. Under the proposal of the Litigating States, a Special Master would be required to "conduct prompt investigations of any complaints and to propose resolutions within the short time frame necessary to be meaningful in such a fast-moving market." See States' Remedy at 24. The proposal of the Litigating States contains strict time limits for investigating and resolving any third-party complaints. See id. at 26-27. The Litigating States' enforcement provisions, moreover, would impose severe penalties on Microsoft in the event it perpetuates its monopolist campaign. See id. at 28-29.
The Tunney Act was intended as a safeguard to ensure that antitrust consent decrees were within "the public interest." The Act provides procedural requirements for publication of proposed consent decrees in the Federal Register and provides a sixty day comment period during which any person may file written comments to the consent decree. The government is required to respond to any filed comments. Tunney Act, 15 U.S.C. §§16(b)-(d). As one commentator has noted, "[t]hese procedural provisions were designed to satisfy two of the three major criticisms of prior practice by opening up the process to participation by interested third parties and by requiring the government to reveal its justifications for settling the case on the terms provided in the consent decree." Lloyd C. Anderson, United States v. Microsoft, Antitrust Consent Decrees, and the Need for A Proper Scope of Judicial Review, 65 Antitrust L.J. 1, 9 (Fall 1996).
The Tunney Act further provides that a district court may only approve a proposed consent decree if it is in "the public interest." The Act lists the following factors which may be considered by a district court: (1) the "competitive impact" of the decree; (2) provisions for enforcement and modification of the decree; (3) the duration of the decree; (4) the anticipated effects of alternative remedies; and (5) "any other considerations bearing upon the adequacy of such judgment," as well as "the impact of the entry of such judgment upon the public generally." 15 U.S.C. §16(e).
Since the Tunney Act was enacted in 1974, courts have used varying standards to evaluate consent decrees under the Act based in large part on the posture of the case at the time the consent decree was entered. See, generally, Anderson, supra. In cases in which the consent decree and DoJ complaint were filed simultaneously, and no evidence was introduced concerning the allegations in the complaint, the court's Tunney Act review was extremely limited. See United States v. Microsoft, 159 F.R.D. 318 (Sporkin, J.) (D.D.C. 1995), rev'd 56 F.3d 1448 (D.C.Cir. 1995) ("Microsoft I").(19)
In cases in which substantial evidence was adduced at trial before the consent decree was entered, the court's "public interest" determination was significantly more in-depth based largely on the district court's evaluation of the record before it. See, e.g., United States v. A.T.&T, 552 F. Supp. 131 (D.D.C. 1982) ("AT&T").(20)
Here, in contrast to Microsoft I, there is a robust evidentiary record that must be considered if the Court is even to contemplate accepting or modifying, rather than rejecting outright, the RPFJ. Indeed, the principle reason that the Court of Appeals remanded this case was to assure that the remedy imposed on Microsoft was consistent with the facts established at trial. In the absence of a meaningful review of the facts of this case (including the judgment against Microsoft), and implications of the proposed remedy on the public interest, the Court's proper role under the Tunney Act will not be fulfilled. In fact, this case requires a far more detailed review under the "public interest" standard than was undertaken by Judge Greene in the AT&T case.
In that case, the Court, as here, was asked to consider the propriety of a proposed consent decree issued after trial commenced and extensive evidence was presented. Foreshadowing the issue squarely before this Court, Judge Greene explained that evaluation of a settlement prior to a finding of liability is a different analysis than "fashioning a remedy as it would be upon a finding of liability." AT&T, 553 F. Supp. 131, 151 (emphasis added). Judge Greene further stated:
Id. at 151.
Judge Greene explained, moreover, that the consent decree in AT&T required "more than normal scrutiny" because of the size of AT&T, the complexity of the proposed decree, the "potential for substantial private advantage at the expense of public interest," and the "potential impact of the proposed decree on a vast and crucial sector of the economy." Id. at 151-52. Further, Judge Greene noted that although "courts would generally not be able to render sound judgments on settlements because they would not be aware of the relevant facts . . .," that concern was not relevant in the AT&T case because the district court "already heard what probably amount[ed] to over ninety percent of the parties' evidence both quantitatively and qualitatively, as well as all of their legal arguments." Id. at 152.
Also relevant here, Judge Greene emphasized that greater scrutiny was required because of the "unfortunate" history in the prior AT&T actions and settlement:
None of this means, of course, that the Court would be justified in simply substituting its views for those of the parties. But it does mean that the decree will receive closer scrutiny than that which might be appropriate to a decree proposed in a more routine case.
Id. at 153.
Based on such concerns, Judge Greene held that the appropriate standard of review under the Tunney Act in such cases is to assure, as a factual matter, that the decree will protect the public interest. He explained:
AT&T, 553 F. Supp. at 153.
Judge Greene's reasoning in the AT&T case applies with even greater force to the case at hand. Here, as in AT&T, Microsoft and DoJ previously entered into a consent decree (Microsoft I) which was summarily approved and which, in part, enabled Microsoft to engage in the prohibited conduct in violation of the Sherman Act which is at issue in this case. Here, as in AT&T, Microsoft and DoJ conducted a full trial on the merits. Here, as in AT&T, close scrutiny of the decree is imperative, because of the size and strength of Microsoft, the complexity of the remedies at issue in this case, the clear "potential for substantial private advantage at the expense of public interest," and the "potential impact of the proposed decree on a vast and crucial sector of the economy." Id. at 151-52. Unlike the AT&T case, however, here Microsoft has already been adjudged to have abused its monopoly power and it is incumbent upon this Court, in reviewing the RPFJ, to determine whether Microsoft's confirmed antitrust liability is sufficiently addressed to protect the public interest.
In sum, Microsoft, and relief from its pervasive abuse of monopoly power, are far too important to allow this proceeding to serve merely to "rubber stamp" a remedy negotiated behind closed doors. To do so, would render the Tunney Act utterly meaningless. Equally important: Microsoft has already been found liable for violating Section 2 of the Sherman Act. The remedies now proposed by DoJ and Microsoft are far less exacting than the remedies initially proposed by either Microsoft or DoJ, are far more lenient than the original remedies fashioned by the district court, and, if adopted would make a "mockery" of the legal process. See Microsoft I, 159 F.R.D. at 318.
For all the reasons discussed supra, Novell believes that the RPFJ is so blatantly inadequate and contrary to the public interest that it should immediately be rejected out of hand. Cf., In re Microsoft Corp. Antitrust Litigation, MDL 1332, Slip Op., Motz, D.J. (D.Md. Jan. 11, 2002) (rejecting settlement of class action against Microsoft in the absence of an factual record sufficient for assessment of the public interest). If the Court declines to reject the RPFJ based on the Tunney Act comments alone, then the Court must undertake a rigorous legal and factual analysis to assess how adoption of the RPFJ would affect the public interest.
Under the terms of the Tunney Act, in making such an analysis, a court may:
15 U.S.C. §16(f).
Because of the impending trial on the Litigating States' proposed remedies, and the fact that Microsoft has chosen to proffer the RPFJ as its own remedies proposal in that Litigating States' case, the record developed therein is likely to obviate what would otherwise be the clear need for a full evidentiary hearing if the court were even contemplating adoption or modification the RPFJ. Novell respectfully suggests that, in lieu of holding a separate Tunney Act hearing, this Court refrain from ruling on the RPFJ until the conclusion of the hearing in the Litigating States' case. In that way, the Court will have the opportunity, after a full exposition of the relevant facts, to order a single remedy in the public interest.
To protect the public interest, antitrust relief must look not only backwards at past unlawful conduct, but also forward at foreseeable risks. An antitrust remedy must "unfetter a market from anticompetitive conduct," Ford Motor Co. v. United States, 405 U.S. 562, 577 (1972), and "terminate the illegal monopoly, deny to the defendant the fruits of its statutory violation, and ensure that there remain no practices likely to result in monopolization in the future." United States v. United Shoe Mach. Corp., 391 U.S. 244, 250 (1968); see also United States v. Grinnell Corp., 384 U.S. 563, 577 (1966). The RPFJ fails this test.
Indeed, the RPFJ even ignores Microsoft's aggressively anticompetitive past. Microsoft has persistently manipulated interface information to cut lines of mooring between the middleware of its competitors and its own monopoly operating systems and to repel any incursions onto the beachfront of competition. Microsoft moreover, has cynically sought to recast its malevolent monopolization as the harmless development of "integrated products" under the "Windows" name. In spite of this well-documented history, the RPFJ replenishes Microsoft's arsenal of technological knives and linguistic camouflage and encourages it to develop additional anticompetitive weaponry in its assault on the public interest.
Much has been made of the fact that, at the end of the negotiations that resulted in the Proposed Final Judgment, it was Microsoft's counsel, Charles F. Rule, a former Assistant Attorney General for Antitrust in the second Reagan Administration, and Charles James, the current head of DoJ's Antitrust Division, who hammered out the final provisions of the settlement now before this Court. This was the very same Charles Rule who, testifying before Congress in 1997, reminded the Senate Judiciary Committee that ambiguities in consent decrees are typically resolved against the Government (and, assumedly, against the public interest, which the Government should represent) and that, in interpreting a decree later, "the Government cannot fall back on some purported 'spirit' on 'purpose' of the decree to justify an interpretation that is not clearly supported by the language." Charles F. Rule Testimony, supra at 3. If this Court does not act to reject this settlement, for Microsoft it will be "been there, done that;" for the rest of us, it will be "déjà vu all over again." For the foregoing reasons, Novell respectfully requests that the Court reject the RPFJ as contrary to the public interest.
Dated: January 28, 2002
1. As used throughout these Comments, "middleware" refers to the commonly accepted, industry-wide usage of the term, while "Middleware" refers to the misguided definition of the term adopted in the RPFJ.
2. Defendant Microsoft Corporation's Remedial Proposal (Dec. 12, 2001), State of New York, ex rel. Spitzer, et al. v. Microsoft Corp., No. 98-1233.
3. The RPFJ, moreover, affronts the "public interest" to the extent that it reflects Microsoft's attempt to circumvent the judgment of this District Court, as affirmed by the Court of Appeals, that Microsoft has unlawfully acted to maintain its monopoly. Microsoft's hope to succeed in negotiation where it failed in court is arrogantly proclaimed in the preamble to the RPFJ, which asserts that "this Final Judgment does not constitute any admission by any party regarding any issue of fact or law;" and in Paragraph VIII, which proffers that
5. The ridiculous implication of this loophole is that there exists some correlation between a decision by Microsoft to assert trademark protection for software and Microsoft's ability to exploit such software for anticompetitive purposes. To the contrary, this limitation on the scope of the RPFJ is simply a "give away" that enhances the misdirected protection afforded by the RPFJ to Microsoft.
6. Notably, the DoJ appears to have misread, or misunderstood, the import of this element of its own definition. The CIS asserts that this last element of the definition is:
CIS, 66 Fed. Reg. at 59,464. In fact, the language of the RPFJ has precisely the opposite effect of what DoJ claims. Because the proposed four elements of "Microsoft Middleware" are all required, this last element further limits, rather than expands, the scope of relief.
7. The Litigating States would define middleware as follows:
x. "Microsoft Middleware Product" means:
i. Internet browsers, e-mail client software, media creation, delivery and playback software, instant messaging software, voice recognition software, digital imaging software, directories, Exchange, calendaring systems, systems and enterprise management software, Office, Handheld Computing Device synchronization software, directory services and management software, the Common Language Runtime component of the .Net framework, and Compact Framework, whether provided in the form of files installed on a computer or in the form of Web-Based Software, or
ii. Middleware distributed by Microsoft that (1) is, or in the three years preceding this Judgment has been, distributed separately from an Operating System Product, any successors thereto, or (2) provides functionality similar to that provided by Middleware offered by a Microsoft competitor. States' Remedy at 34-35.
8. See also Windows 2000: Blueprint for Domination, Computer & Communications Industry Ass'n at 24 (Apr. 2000), available at http://www.ccianet.org/papers/ms/blueprint_for_domination.pdf (visited Jan. 24, 2001) ("CCIA White Paper") ("Active Directory is the integrated directory service for Windows 2000. It is the glue that binds Windows desktops to Windows 2000 Servers. Active Directory is a critical component for any end user, Application Developer, and IT manager that is using, developing, or managing computers and applications in a Microsoft distributed computing environment.").
9. In Windows 2000, Microsoft redesigned its authentication system and refused to disclose the APIs necessary for Novell to continue "redirecting" Microsoft calls for Active Directory to eDirectory. Novell used a technique called "redirection" to allow an earlier version of its directory services software, called NDS, to interoperate effectively with WindowsNT. By moving and encrypting interface information in Windows 2000 and Windows XP, Microsoft has prevented Novell from using redirection and has forced Novell to "synchronize" its directory services software, now called eDirectory, with Active Directory. As a result of this tactic, customers may not run eDirectory alone, but can only use it as a supplement to Active Directory. See CCIA White Paper, supra ("The way Microsoft's Active Directory is implement on the client-side makes it impossible to redirect services to alternative directory service providers such as Novell's NDS. This means Active Directory must be present on a network of Windows 2000 machines and that Novell can no longer compete as a substitute for directory services as they did with Windows NT."); Active Directory, Gartner Group, supra, at 9 ("With [Windows] NT v. 4, Novell has used a redirection model with its NDS for NT product to provide a solution for managing heterogeneous NDS and NT domain environments. We believe this approach will be difficult, if not impossible, for Novell to implement with Active Directory in Windows 2000.").
10. See CCIA White Paper, supra ("Active Directory is also used as Microsoft's vehicle for locking customers into a Microsoft proprietary standard. Active Directory supports standard interfaces such as Lightweight Directory Access Protocol (LDAP) and Domain Name Service (DNS). These protocols are subsets of what Active Directory supports, meaning that no other directory services can substitute for Active Directory.") For a discussion of LDAP, see Novell Technical Information Document:GroupWise and LDAP Whitepaper (Feb. 15, 2000), available at http://support.novell.com/cgi-bin/search /searchtid.cgi?/2955731.htm (visited Jan. 22, 2002).
11. See discussion of CALs, infra at Section II.D.
12. See, e.g., Jesse Berst, APIs: Microsoft's Hidden Full Nelson, ZDNet (Jun. 28, 2000), available at http://www.zdnet.com/anchordesk/stories/story/0,10738,2595479,00.html (visited Jan. 22, 2002); Sven B. Schreiber, Undocumented Windows 2000 Secrets: A Programmer's Cookbook (2001); Prasad Dabek, Sandeep Phadke & Milind Borate, Undocumented WindowsNT (1999).
13. The RPFJ defines "Timely Manner" for disclosure of interface information as "the time Microsoft first releases a beta test version of a Windows Operating System Product that is distributed to 150,000 or more beta testers." RPFJ, 66 Fed. Reg. at 59,459.
14. One of the most remarkable aspects of modern encryption technology is that it allows for virtually complete security of a "key" needed to unlock an encrypted message. In the world of physical locks and keys, a key is never entirely secure (even if it is never shared), because a locksmith can reproduce a key if he or she is given the lock. By contrast, in the world of bits and bytes, modern encryption can prevent a "key" from being copied, even if an expert knows how the key was made and is given the locked (i.e., encrypted) message
15. Perhaps most remarkable, is the arrogance with which Microsoft exploits its anticompetitive efforts to impede interoperability. Microsoft, for example, repeatedly issues marketing materials that criticize products offered by Novell and other competitors for technical problems cause by Microsoft's refusal to allow effective interoperability with Windows.
Thus, in 1998, Microsoft's Website criticized Novell's directory services product, NDS for NT, because "[i]t is not integrated with the operating system." Further, Microsoft proclaimed that Windows NT is "successful," because " customers have found that Windows NT Server suits most of their needs now and they are confident that Microsoft will deliver on other functionality that they need in the near future. Such is the case with directory services." In other words, in 1998, Microsoft admitted that it did not yet offer a competitive directory services middleware product, but it aggressively discouraged customers from using Novell's product based on interoperability limitations created by Microsoft and its "promise" of improving its software sometime in the future. See NDS for NT: Increases Complexity and Cost Without Adding Value, available at http://www.strom.com/awards/98a.html (visited Jan. 13, 2002) (republication of paper appearing on Microsoft's website until Jan. 22, 1998). Four years later, Microsoft's Active Directory is still generally regarded as inferior to Novell's eDirectory, yet continues to increase market share at Novell's expense as a result of Microsoft's anticompetitive acts. See, e.g., Products of the Year, Network Magazine (May 7, 2000), available at http://www.networkmagazine.com/article/NMG20010413S0005 (visited Jan. 15, 2002).
16. The CCIA explains that "[w]hile the Kerberos Version 5 Microsoft uses for their security services is a standard, the way they have implemented Kerberos is not a standard and renders it nearly inoperable with any other implementation." CCIA White Paper, supra, at 24.
17. Not content with Microsoft's corruption of the Kerberos standard, Microsoft has filed for a patent on its proprietary version. Consequently, not only will Microsoft products fail to interoperate with non-Microsoft products (because of the modification), but Microsoft will not allow anyone else to use its version unless they purchase a license from Microsoft.
18. The server license and five CALs is shown as costing $999 in Windows 2000. See Microsoft Windows 2000 Pricing and Licensing, available at http://www.microsoft.com/ Windows2000/server/howtobuy/pricing/ (visited Jan. 10, 2002). The cost of five CALs is shown separately as $199. Thus the server license is around $799 and each CAL is around $40. This is consistent with the prices shown for the server license and ten CALs ($1,199 - $799 plus 10 x $40), for the server license and 25 CALs ($1,799 - $799 plus 25 x $40) and for a 20 CAL pack ($799 - around 20 x $40).
19. In this instance, Microsoft will no doubt argue that this Court has limited authority to review the Proposed Final Judgment based, in large part, on the D.C. Court of Appeals' decision overturning Judge Sporkin's ruling which rejected the proposed consent decree entered by DoJ in Microsoft I. Rather than undermining the District Court's authority here, Microsoft I demonstrates the critical importance of a fact-based review of the RPFJ. Although the Court of Appeals rejected Judge Sporkin's decision in Microsoft I, its grounds for reversal are inapplicable here. Further, the Court of Appeals emphasized in Microsoft I that a "court may (1) insist upon correction of ambiguous provisions, (2) require adequate implementation provisions, (3) consider injury to third parties, and (4) reject decrees that 'make a mockery of judicial power.'" Anderson, supra, at 17; Microsoft I, 56 F.3d 1448, 1461-62.
Judge Sporkin's decision to reject the proposed decree in Microsoft I was overturned, because his decision had no grounding in the record of the case. Rather than consider only the complaint and decree (the only record before him), Judge Sporkin improperly based his decision on facts alleged in a book about Microsoft. Id. at 1453. Neither the book, nor the claims asserted in the book, were properly before the court, and Judge Sporkin's decision to rely on such an extraneous source of information was roundly rejected by the Court of Appeals. In reversing Judge Sporkin's decision, the D.C. Court of Appeals' emphasized that Judge Sporkin's reliance on such information amounted to unconstitutional usurpation of the Attorney General's role. Id. See also Anderson, supra, at34.
20. It is important to note that the D.C. Court of Appeals in Microsoft I clearly cites to the AT&T case as the most prominent post-Tunney Act case, without ever overruling that case. See Microsoft I, 56 F.3d at 1458, et. seq.