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.

<<0901266.DOC>>

UNITED STATES OF AMERICA,                   Plaintiff,                   v. MICROSOFT CORPORATION, Defendant. STATE OF NEW YORK, et al. Plaintiffs,                   v. MICROSOFT CORPORATION, Defendant.

| | | | | | | | | | | | | | | | | | | | | |

Civil Action No. 98-1232 (CKK) Civil Action No. 98-1233 (CKK)

1. Introduction

1. Background

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.⁽¹⁾

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, 105^th 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. Summary

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

2. The RPFJ Is Contrary to the Public Interest

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.

1. The RPFJ Protects Microsoft, Rather than the Public Interest, Because It
   Perpetuates Microsoft's Power to Preclude Competition For Middleware

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.⁽⁴⁾

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.

1. The RPFJ's Vapid Definitions of Middleware

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:

1. is, or in the year preceding the commercial release of any new Windows Operating System Product the software was, distributed separately by Microsoft (or by an entity acquired by Microsoft) from a Windows Operating System Product;

2. has functionality similar to that provided by a Non-Microsoft Middleware Product; and

3. is Trademarked.

Id.

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.⁽⁵⁾

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."⁽⁶⁾ 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.

2. The RPFJ's Limited Scope Precludes Protection of the Public Interest

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.⁽⁷⁾ 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:

In crafting an effective Sherman Act remedy, a court must use the record of a backward-looking trial to fashion forward-looking relief. Looking forward, the Court must anticipate that Microsoft, unless restrained by appropriate equitable relief, likely will continue to perpetuate its monopoly by the same anticompetitive methods revealed at trial, although directed at whatever new competitive threat arises. Neither the Netscape browser nor Java continues to have the prospect of lowering the applications barrier to entry, and it is not certain where future threats to Microsoft's operating system will arise. But there are several possibilities that ought to be taken into account in crafting an appropriate remedy for Microsoft's violations.

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.

3. The RPFJ Subverts the Public Interest By Providing
   Immunity for Microsoft's Unlawful Efforts to Destroy
   Middleware Alternatives to Active Directory

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:

[A] key part of [the Internet2] initiative is to promote open standards "middleware," or "glue", [which] is a layer of software between the network and the applications. This software provides services such as identification, authentication, authorization, directories, and security. In today's Internet, applications usually have to provide these services themselves, which leads to competing and incompatible standards. By promoting standardization and interoperability, middleware will make advanced network applications much easier to use.

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:

[O]ne of the important parts of integration middleware [such as a directory service] is the superservice. A superservice presents to the application program its own superAPI, effectively masking or superseding the API(s) exposed by other software layers. A superservice provides services, such as metadirectory, security and/or transaction management, across two or more OSs [i.e., Operating Systems], ORBs, TP monitors, DBMSs, application servers and/or networking layers.

Id.

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).⁽⁸⁾ 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.)⁽⁹⁾ 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.⁽¹⁰⁾ Third, Microsoft has employed coercive licenses, called client access licenses or CALs, to discourage users from installing non-Microsoft directory services.⁽¹¹⁾

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.

2. The Proposed Final Judgment Would Have No Effect, Because it
   Fails to Require Meaningful Disclosures by Microsoft of Interface Information

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.

1. Too Little Disclosure: The RPFJ's Inadequate
   Definitions of Interface Information

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:

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

2. "Communications Protocol" means 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.

   * * *

5. "Documentation" means 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 ("MSDN").

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.⁽¹²⁾ 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.

2. Too Late Disclosure: The RPFJ's Inadequate Definition of Timeliness

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:

Whenever Microsoft develops an updated version of a Windows Operating System Product, it must disclose all relevant APIs and Documentation in a "Timely Manner," meaning at the time Microsoft first releases a widespread beta test version of that Windows Operating System Product (i.e., one made available to 150,000 or more beta testers). If, alternatively, Microsoft develops a new "major version" of Microsoft Middleware, it must disclose any APIs and Documentation used by that middleware to interoperate with any Windows Operating System Product not later than the release of the last major beta version of that middleware (i.e., the version before the release of any "release candidate" version of the middleware). This dual-timing trigger mechanism is important to ensure that ISVs and other third parties learn of all relevant APIs and the information needed effectively to use them well in advance of the actual commercial releases of the relevant Microsoft software, so that the third parties can ensure that their own competing products function on and interoperate with Windows.

CIS, 66 Fed. Reg. at 59,468 (emphasis in original).⁽¹³⁾

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.

3. The RPFJ's Security Loophole Precludes Meaningful Relief

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:

J. No provision of this Final Judgment shall:

1. Require Microsoft to document, disclose or license to third parties:

(a) portions of APIs or Documentation or portions or layers of Communications Protocols the disclosure of which would compromise the security of a particular installation or group of installations of anti-piracy, anti-virus, software licensing, digital rights management, encryption or authentication systems, including without limitation, keys, authorization tokens or enforcement criteria; or

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.⁽¹⁴⁾ 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.

4. The RPFJ's Inadequate Disclosure Requirements
   Precludes Protection of the Public Interest

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:

• "Secret Interfaces" - Microsoft does not publish all the interfaces it uses and does not publish all the interface information that others need to develop products that interoperate with Microsoft software.

• "Crippled Interfaces" - For some functions, Microsoft publishes information about an interface that is inferior to the interface that Microsoft itself uses to accomplish a function, or publishes incomplete information about an interface.

• "Kick Me Interfaces" - Sometimes, Microsoft publishes information about an interface that Microsoft uses to perform a function, but it "marks" non-Microsoft software in a way that assures the interface will operate in an inferior way. Microsoft can "mark" competitors software through tagging, signing, encrypted passwords, or by noting the absence of such features.

• "Moving Interfaces" - If, by some means, a third party has been able to obtain adequate interface information that Microsoft doesn't want it to have, Microsoft will simply move the interface. For example, Novell successfully figured out how to enable its directory services software to interoperate with Windows NT. To counter Novell's success, in Windows 2000 Microsoft broke up and moved the computer files containing the interface information used by Novell and marked, or signed, information required for the interfaces so that Novell could neither use Microsoft's interface information nor replace it.

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.⁽¹⁵⁾

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:

...at a minimum, publication on a Web site accessible to ISVs, IHVs, OEMs and Third-Party Licensees at the earliest of the time that such APIs, Technical Information, or Communications Interfaces are (i) disclosed to Microsoft's applications developers, or (ii) used by Microsoft's own Platform Software developers in software released by Microsoft in alpha, beta, release candidate, final or other form, or (iii) disclosed to any third party, or (iv) within 90 days of a final release of a Windows Operating System Product, no less than 5 days after a material change is made between the most recent beta or release candidate version and the final release.

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.

3. The RPFJ Will Encourage Microsoft To Continue To
   Corrupt Industry Standards for Anticompetitive Purposes

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.⁽¹⁶⁾ 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.⁽¹⁷⁾

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.

4. The RPFJ Will Encourage Microsoft To Continue To
   Use Coercive Licensing Practices to Exclude Competition

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:

The most significant pricing increase for enterprises using Win2000 will come from Microsoft's licensing change requiring CALs for all authenticated users. This is considerably broader than Microsoft's previous CAL requirement with Windows NT v.4. The most common scenario for increased costs will involve users of Microsoft's Exchange using Novell for NOS [Network Operating System] services. These users will typically see Win2000 server and CAL fees increase five to eight times over their current server and CAL fees. Previously, users of Exchange were not required to Purchase an NT CAL. However, since all versions of Exchange require NT authentication [provided by Active Directory] these users will be required to purchase Win2000 CALs regardless of whether they use another vendor's NOS services. This, in effect, makes the use of Microsoft's NOS services free as compared to other NOSs. The situation is exacerbated by Microsoft's server logo program requirement that certified applications must, at a minimum, support Windows 2000 authentication -- a move that increases the number of scenarios in which CALs will be required. Furthermore, by broadening authentication to include applications "indirectly" using Win2000 sign-on services, uses of products that tap into Microsoft's security APIs (e.g., Novell's NDS for NT) must purchase CALs where they were not charged before.

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.⁽¹⁸⁾ 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.

5. The RPFJ Would Fail to Protect the Public Interest, Because It Fails To Adopt
   An Enforcement Regime That Discourages Non-Compliance By Microsoft

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.

3. Legal Standards

1. In Evaluating the Proposed Final Judgment and the Public Interest, the Court Must Consider Microsoft's Status as a Defendant That Has Already Been Found to Have Abused its Monopoly Power

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").⁽¹⁹⁾

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").⁽²⁰⁾

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:

It does not follow from these principles, however, that courts must unquestioningly accept a proffered decree as long as it somehow, and however inadequately, deals with the antitrust and other public policy problems implicated in the lawsuit. To do so would be to revert to the 'rubber stamp' role which was at the crux of the congressional concerns when the Tunney Act became law. This consideration is especially potent in these cases for several reasons.

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:

The 1956 Western Electric consent decreethat identical settlement, and the identical parties, are now before the Court. Nor can those events simply be dismissed as ancient history, irrelevant to the events of 1981-82These circumstances do not foster a sense of confidence that the assessment of the settlement and its implications may be left entirely to AT&T and the Department of Justice.

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:

If the decree meets the requirements for an antitrust remedy -- that is, if it effectively opens the relevant markets to competition and prevents the recurrence of anticompetitive activity, all without imposing undue and unnecessary burdens upon other aspects of the public interest -- it will be approved. If the proposed decree does not meet this standard, the Court will follow the practice applied in other Tunney Act cases and, as a prerequisite to its approval, it will require modifications which would bring the decree within the public interest standard as herein defined.

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.

2. If the Court Does Not Reject the RPFJ Outright, It Should ­ At a Minimum ­ Await the Outcome of the Hearing on the Litigating States' Proposed Remedies Before Ruling on the Adequacy of the RPFJ

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:

1. take testimony of Government officials or experts or such other expert witnesses, upon motion of any party or participant or upon its own motion, as the court may deem appropriate;

2. appoint a special master and such outside consultants or expert witnesses as the court may deem appropriate;

3. authorize full or limited participation in proceedings before the court by interested persons or agencies, including appearance amicus curiae, intervention as a party pursuant to Federal Rules of Civil Procedure, examination of witnesses or documentary materials, or participation in any other manner and extent which serves the public interest as the court may deem appropriate;

4. review any comments including any objections filed with the United States under subsection (d) of this section concerning the proposed judgment and the responses of the United States to such comments and objections; and

5. take such other action in the public interest as the court may deem appropriate.

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.

4. Conclusion

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.

Respectfully submitted,   _/s/__________________________

OF COUNSEL: Joseph A. LaSala, Jr. Senior Vice President, General Counsel NOVELL, INC. 8 Cambridge Center Cambridge, MA 02142 (617) 914-8169	Judith L. Harris (D.C. Bar No. 190579) REED SMITH LLP 1301 K Street, N.W. Suite 1100 ­ East Tower Washington, DC 20005-3317 (202) 414-9276
Ryan Richards Associate General Counsel NOVELL, INC. 1800 South Novell Place Provo, Utah 84606 (801) 861-7000	Gary L. Kaplan (D.C. Bar No. 391616) REED SMITH LLP 435 Sixth Avenue Pittsburgh, PA 15219-1886 (412) 288-4268 Counsel for Novell, Inc.

Dated: January 28, 2002

FOOTNOTES

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 "[n]othing in this Final Judgment is intended to confer upon any other persons any rights or remedies of any nature whatsoever hereunder or by reason of this Final Judgment." RPFJ, 66 Fed. Reg. at 59,453, 59,460. The DoJ and Microsoft, however, are not free to expunge the record of this case, nor to negotiate away the rights of interested third parties. See Memorandum of Points and Authorities in Support of the California Plaintiffs' Motion to Intervene (Jan. 28, 2002), United States v. Microsoft Corp., No. 98-1232.

4.

10. "Microsoft Middleware" means software code that
    1. Microsoft distributes separately from a Windows Operating System Product to update that Windows Operating System Product;
    2. is Trademarked;
    3. provides the same or substantially similar functionality as a Microsoft Middleware Product; and
    4. includes at least the software code that controls most or all of the user interface elements of that Microsoft Middleware.

       Software code described as part of, and distributed separately to update, a Microsoft Middleware Product shall not be deemed Microsoft Middleware unless identified as a new major version of that Microsoft Middleware Product. A major version shall be identified by a whole number or by a number with just a single digit to the right of the decimal point.

11. "Microsoft Middleware Product" means
    1. the functionality provided by Internet Explorer, Microsoft's Java Virtual Machine, Windows Media Player, Windows Messenger, Outlook Express and their successors in a Windows Operating System Product, and 2. for any functionality that is first licensed, distributed or sold by Microsoft after the entry of this Final Judgment and that is part of any Windows Operating System Product
       1. Internet browsers, email client software, networked audio/video client software, instant messaging software or

       2. functionality provided by Microsoft software that --
          1. is, or in the year preceding the commercial release of any new Windows Operating System Product was, distributed separately by Microsoft (or by an entity acquired by Microsoft) from a Windows Operating System Product;

          2. is similar to the functionality provided by a Non-Microsoft Middleware Product; and

          3. is Trademarked.

       Functionality that Microsoft describes or markets as being part of a Microsoft Middleware Product (such as a service pack, upgrade, or bug fix for Internet Explorer), or that is a version of a Microsoft Middleware Product (such as Internet Explorer 5.5), shall be considered to be part of that Microsoft Middleware Product.

12. "Microsoft Platform Software" means (i) a Windows Operating System Product and/or (ii) a Microsoft Middleware Product.

13. "Non-Microsoft Middleware" means a non-Microsoft software product running on a Windows Operating System Product that exposes a range of functionality to ISVs through published APIs, and that could, if ported to or made interoperable with, a non-Microsoft Operating System, thereby make it easier for applications that rely in whole or in part on the functionality supplied by that software product to be ported to or run on that non-Microsoft Operating System.

14. "Non-Microsoft Middleware Product" means a non-Microsoft software product running on a Windows Operating System Product:
    1. that exposes a range of functionality to ISVs through published APIs, and that could, if ported to or made interoperable with, a non-Microsoft Operating System, thereby make it easier for applications that rely in whole or in part on the functionality supplied by that software product to be ported to or run on that non-Microsoft Operating System, and

    2. of which at least one million copies were distributed in the United States within the previous year. RPFJ, 66 Fed. Reg. at 59,459.

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:

to ensure that the definition captures situations whereMicrosoft chooses to divide up the software code...and to distribute that code not in one block but in smaller blocksthe fourth requirement sets a minimum functional requirement that in no case (regardless of the size, or manner of, distributing the code) shall the software code constituting Microsoft Middleware be less than that which controls most, or all of, the user interface elements of that Microsoft Middleware.

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:

w. "Middleware" means software, whether provided in the form of files installed on a computer or in the form of Web-Based Software, that operates directly or through other software within an Operating System or between an Operating System (whether or not on the same computer) and other software (whether or not on the same computer) by offering services via APIs or Communications Interfaces to such other software, and could, if ported to or made Interoperable with multiple Operating Systems, enable software products written for that Middleware to be run on multiple Operating System Products. Examples of Middleware within the meaning of this Final Judgment include without limitation Internet browsers, network operating systems, e-mail client software, media creation, delivery and playback software, instant messaging software, voice recognition software, digital imaging software, the Java Virtual Machine, calendaring systems, Handheld Computing Device synchronization software, directories, and directory services and management software. Examples of software that are not Middleware within the meaning of this Final Judgment are disk compression and memory management software.

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.