117 Sullivan St., 5A
New York, NY 10012
January 28, 2002
Renata B. Hesse
U.S. Department of Justice
601 D Street NW
Washington, DC 20530-0001
re. Deficiencies in Microsoft settlement.
Pursuant to the Tunney Act, I am filing these comments on the proposed resolution of United States, et al. v. Microsoft.
My Perspective, Experience, and Interest
I believe this case is tremendously important. As personal computers and the Internet have become increasingly important to our everyday lives, so too has the landscape of the technology markets become increasingly important. Not only will the outcome of this case impact the fortunes of a host of technology companies, but it will also affect how I and millions of others communicate with our friends and family, what choices we have for online services such as digital photography, and of course how much we and businesses spend on technology infrastructure.
Once the government decided not to seek a structural remedy, it necessarily embarked on a course of regulation. Regulation only works when the conduct prohibitions truly restrain anti-competitive behavior, and create a genuine opportunity for innovators to enter the market and compete in it based on their merits. Unfortunately, the Proposed Final Judgement (PFJ) presented by the Department of Justice and several states fails on all counts.
Its results will be only a mild, temporary modification to Microsoft's well-documented behavior, with no lasting or significant effect on competition. Microsoft will retain its monopoly and every incentive to maintain it through any means not specifically prohibited by the PFJ. Consumers will continue to be deprived of the innovations and other benefits of a truly competitive market, in part because innovators will be deprived of the opportunity and incentive to challenge Microsoft's monopoly as it expands and evolves. Most importantly, America's technology industry will stagnate, as ever fewer competitors see any value in entering markets dominated by Microsoft.
While I believe that many if not most Americans will be affected by the disposition of this case, I have a particular interest in it as a long-time technology consumer, entrepreneur, and enthusiast. Since 1980, I have used personal computers nearly every day, first as a hobby, then for school, and later for my career in the technology industry. In the early 1990s, I managed a small but pioneering desktop publishing department for a large advertising agency. Later, I joined a groundbreaking multimedia company that produced CD-ROMs for both Macintosh and Windows-based computers. Most recently, I was a partner in a successful Internet development firm, which designs and produces web sites and other interactive media for corporate clients. Having sold my share of that business, I currently consult for other companies in the technology industry.
Definitions Are Critical: the Devil Is in the Details
1. Most provisions of the PFJ depend on the definition of "Microsoft Middleware." Accordingly, we should expect this term to be well-defined, with clear boundaries and unquestionable meaning. Unfortunately, the reality is that it is vaguely defined, in language that grants Microsoft itself much control over what software it, and therefore the PFJ, governs.
1.1. Definition: According to the PFJ (PFJ VI.J), "Microsoft Middleware" is any software which:
- is distributed separately from the operating system,
- controls the user interface of the Microsoft Middleware,
- provides substantially similar functionality as a Microsoft Middleware Product, and
- is trademarked.
1.2. Definition gives Microsoft control. So Microsoft, which has long stated its goal of incorporating browsing and other middleware functions into its operating system products, can exclude code from the Microsoft Middleware definition simply by not distributing it separately from the operating system, or even just by not trademarking it.
Microsoft therefore will have enormous latitude in determining which new operating system features will be governed by the PFJ.
Clarity Is Essential to Compliance and Public Confidence.
2. The PFJ consists largely of vague prohibitions hobbled by numerous qualifiers and exemptions. For instance:
Limited replacement of Microsoft Middleware.
2.1. The PFJ requires Microsoft to enable users and OEMs to specify that Non-Microsoft Middleware be used in place of Microsoft Middleware (PFJ, III.H.2). This is a welcome change because it had previously been difficult to replace Microsoft's Internet Explorer (IE) without facing "considerable uncertainty and confusion" when IE would nonetheless unexpectedly be invoked under certain circumstances (Findings, 171).
2.1.1. Exemption for Microsoft servers. Unfortunately, Microsoft is exempt from this requirement when the Middleware Product would be invoked "solely for use in interoperating with a server maintained by Microsoft" (PFJ III.H). This may exempt Microsoft's current move into network services (".NET") from the judgement, inasmuch as such services communicate with Microsoft-owned servers. Microsoft considers .NET to be the next phase of the Internet, at last offering 'real' applications and services. The first .NET service, Microsoft Passport, aims at becoming a cornerstone of Internet shopping and authentication transactions, and stores its data exclusively on Microsoft-owned servers.
2.1.2. Exemption for proprietary technologies. Another exemption allows Microsoft to launch its own middleware when the Non-Microsoft Middleware "fails to implement a reasonable technical requirement" (PFJ III H 3). Microsoft will be able to capitalize on this loophole simply by emphasizing proprietary technologies not supported by Non-Microsoft Middleware. To the extent that Microsoft can implement features using proprietary technologies, it will better be able to exclude Non-Microsoft Middleware. A truly pro-competitive PFJ would encourage Microsoft to use open industry standards.
OEM Distribution Channel Opened, But For Whom?
2.2. The PFJ requires Microsoft to allow OEMs to customize the user's desktop by installing icons for Non-Microsoft Middleware and other products (PFJ, III.C.1). This is important to the PFJ because Microsoft has in the past excluded Netscape and other competitors from the valuable OEM distribution channel, often by contractually limiting an OEM's ability to customize the desktop. In addition, Microsoft has used its control over the valuable desktop real-estate as an incentive to get IAPs such as AOL to support Microsoft Middleware instead of competing products.
2.2.1. OEMs lack incentive. Unfortunately, because Microsoft's Internet Explorer is now the market leader, there is today little consumer demand for alternatives to Microsoft Middleware. This makes it unlikely that an OEM would see much gain, if any, in installing Non-Microsoft Middleware. Such distribution may benefit the middleware developers, but would not greatly benefit the OEM.
2.2.2. Customizations will be short-lived. This prohibition remains in effect only for a 14-day window starting after the end user first turns on his or her PC. Thereafter, Microsoft is free to re-arrange the desktop as it sees fit, including automatic removal of any non-Microsoft icons, e.g. by operating system features such as the "Clean Desktop Wizard" built-in to Windows XP (PFJ, III.H.3). So, any Non-Microsoft Middleware developers who do manage to secure OEM distribution could well see their products wiped off the desktop after a short two weeks.
2.2.3. Likely results. These limitations beg the question: will any OEMs risk irritating Microsoft for such minor benefits? If they do, will the results truly be increased competition in the middleware market?
General Rule on Sharing APIs.
2.3. The PFJ requires Microsoft to share APIs used by Microsoft Middleware with ISVs, et al. (PFJ III.D). In its Findings of Fact, the District Court found that Microsoft had repeatedly withheld such information from ISVs, or used its disclosure as an incentive for 'friendlier' behavior, in an effort to preserve the applications barrier to entry (Findings, 84, 90, 91). Because ISVs depend on such information to develop software for a given platform, withholding APIs can limit or destroy an ISV's ability to create competitive products. Therefore full API disclosure should be considered a basic condition for any kind of effective competition.
2.3.1. Only APIs necessary to mimic Microsoft's products will be disclosed. Unfortunately, the PFJ requires Microsoft to share only those operating system APIs used by Microsoft Middleware. This is a limited set of APIs, of use only to those ISVs who want to develop middleware products similar to Microsoft's. It does little to help ISVs offer features or innovations not already offered by Microsoft's products. Since ISVs typically must provide innovations to gain market share against an entrenched market leader, this requirement is unlikely to promote competition in the middleware market.
2.3.2. Many APIs may be withheld on dubious 'security' grounds. The PFJ allows Microsoft to exclude any APIs 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" (PFJ III.J.1).
- This is a surprising exemption because few security professionals believe API disclosure could weaken any well-designed security system. Indeed, the complete source code (a level of disclosure far greater than simple APIs) is publicly available for several operating systems and security-related products that are widely considered to be more secure than Windows (e.g. the Linux operating system).
- Yet the inclusion of this exemption implies that there in fact are such APIs whose disclosure could compromise security, and thereby opens the door for Microsoft to make claims about which ones they are. There is no basis for the Competitive Impact Statement's ("CIS") optimism that security-related exemptions will be limited to "keys and tokens" (CIS, IV.B.5) of particular installations. Nothing in the PFJ's language so limits the exemptable APIs, and such entities aren't generally visible at the API level, anyhow.
- With Microsoft's current push into network services (under the .NET moniker), we can expect privacy and security features to be suffused throughout the code, increasing the number of APIs Microsoft will try to exempt from disclosure. Indeed, Microsoft has just this month announced that privacy and security will henceforth be its main priorities.
3. The task of detecting whether Microsoft has violated these and other provisions falls to a three-person "Technical Compliance" committee (the "TC"). This committee will have access to the source code and tools used to create Microsoft's products, as well as access to the relevant Microsoft staff (PFJ IV.B.8). In theory, the TC's oversight will prevent Microsoft from using technical strategies to camouflage non-compliance, for instance by wrongly claiming that some important API should not be disclosed for security reasons. While such oversight may in fact be helpful, the TC is an inadequate, inefficient and non-transparent attempt to ensure enforcement of a Judgement that otherwise relies on voluntary compliance and enforces few penalties for transgressions.
3.1. Severe employment restrictions threaten the TC's performance. The PFJ includes employment restrictions which will dramatically narrow the pool of TC candidates-first, to those experts not currently working for Microsoft or a competitor, and then to those remaining candidates willing to forego any such employment for two years after serving on the TC. In so doing, it excludes nearly all of those experts in operating systems design and programming whom the TC most needs, since it will be very difficult to find any such experts not currently working for, and with no intention of working for, Microsoft or a competitor. As a professional in this field, I cannot imagine why a highly competent independent minded computer scientist would wish to serve on the TC under these circumstances.
3.2. The TC will be buried under a mountain of technical data. Even if well staffed, the committee will have an enormously difficult task from a technical standpoint. Inasmuch as deciphering computer source code can be difficult even for the code's author, much less a new reader, and inasmuch as Windows XP alone consists of some 45 million lines of code , this committee will have an enormously difficult task. Even with a large support staff, it is hard to imagine this committee effectively analyzing Microsoft's source code and fully investigating allegations of non-compliance.
3.3. The TC cannot ensure timely remedies. Further, because the committee is prohibited from public comment (PFJ, IV.B.10), it will be unable to confirm any ISV's suspicions about Microsoft's compliance, nor could it force a timely remedy. Its only recourse will instead be to notify Microsoft and the Plaintiffs and to suggest a possible remedy. Therefore, an ISV suspecting Microsoft of non-compliance will not receive an immediate remedy, but must instead rely on a bureaucracy whose natural tendency will be not to pursue minor infractions. While such infractions may indeed be minor in the scope of the overall judgement, they would assuredly be of great importance to the ISV.
3.4. The TC's findings may not be presented to the Court or the public. Under the PFJ, the TC may not testify in any matter relating to the Final Judgement, nor may its work product and recommendations be submitted to the Court (PFJ, IV.D.4.d). Similarly, the TC is prohibited from public comment (PFJ, IV.B.10). Thus, even if the TC's exclusive access to source code should produce evidence of deception and non-compliance by Microsoft, this evidence will not be presented to the Court.
- In theory, the TC will report to the Plaintiffs, who may in turn report such non-compliance to the Court, and produce evidence of it via other means. This may well happen in the case of massive or severe non-compliance. However, what happens to the small ISV who suspects Microsoft of non-compliance, e.g. by not disclosing some necessary API? Such an injured party may report its concerns to the TC, and then hope that the TC is able to verify its claims, and further is able to convince the Plaintiffs to go to court on their behalf. During this bureaucratic pursuit, the ISV's business may suffer irreparable harm, or even vanish altogether (as has very nearly happened to Netscape). Were such ISVs to have access to Microsoft's source code, perhaps in a secure facility, they could investigate such concerns themselves, directly and immediately. Indeed, API disclosure would not be an issue in the first place.
- The point here is that the nature of the TC is as the first step in a bureaucracy whose natural instinct will be to pursue only the most serious transgressions. In the context of a rapidly changing technology industry, this is a serious weakness in the PFJ.
3.5. PFJ places enormous weight on third TC member. The PFJ proposes that the Plaintiffs appoint one member of the TC, Microsoft appoint a second, and then these two members themselves choose a third (PFJ IV.B.3). This structure places enormous responsibility on the third member, who can be expected to decide any disagreement between Microsoft's representative and the Plaintiffs', especially in the context of the Voluntary Dispute Resolution process in IV.D. It is unclear whether the TC reports to the Plaintiffs only as a single unit, or whether a dissenter's view also gets submitted to the Plaintiffs. A better structure would at the very least make it crystal clear that any single member of the TC may report to the Plaintiffs.
Also, creating such a fulcrum position in the TC makes this third seat much less attractive and harder to fill, and injects an element of politics into the TC that will distract from its technical mission and smooth functioning. Because the TC is not a decisional body, but simply a means to keep a watchful eye on Microsoft's compliance, it is unclear why Microsoft should have representation here at all. All of the TC's members should be appointed by the Plaintiffs, perhaps with the DOJ appointing one member, the States appointing a second member, and the Plaintiffs collectively appointing the third.
3.6. Catch-22. Given the enormity of the TC's tasks, the limits on its powers and enforcement abilities, and the severe employment restrictions surrounding service in the TC (IV.B.2), it is clear that any candidate for the TC willing to accept the job is almost certainly too inexperienced to be legitimately qualified for it.
In Today's Market, More is Needed.
4. In perhaps its broadest weakness, the PFJ fails to recognize that the circumstances of the original case were unique, and that circumstances today are very different. The Internet's rapid public acceptance around 1994-1995 took many established computer-industry firms by surprise, and radically changed the personal computer market. The basic reasons users wanted to own personal computers changed dramatically within less than two years. Two companies in particular, Netscape and Sun Microsystems, were able to aggressively exploit the new technologies and to take advantage of Microsoft's slow response to the burgeoning consumer demand. As a result, they were able to present a serious threat to the applications barrier to entry that has long protected Microsoft's monopoly in Intel-compatible operating systems.
4.1. No longer any consumer demand for non-Microsoft Middleware. But that window of opportunity is long closed. The Internet is an established part of the personal computer market. Microsoft's Internet Explorer is the dominant browser. There no longer is any great consumer demand for alternative browsers. Netscape no longer exists as an independent company, and development of the Netscape browser occurs at a fraction of its former pace. Even the CIS acknowledges that Microsoft has "perhaps extinguished altogether the process by which these two middleware technologies [Java and the Netscape browser] could have facilitated the introduction of competition into the market for Intel-compatible personal computer operating systems" (CIS, III.B.3).
4.2. Cannot resuscitate existing middleware competitors. Nothing in the PFJ can or will restore these competitors to their former strength. There is no way to rekindle the massive consumer demand, then left unserviced by Microsoft, that gave these companies their initial momentum.
4.3. Hoping for another thousand-year flood. Still, the CIS claims the PFJ will "restore the competitive threat that middleware products posed prior to Microsoft's unlawful undertakings" (CIS, II). Given that Microsoft now dominates the browser market and retains its operating systems monopoly, and given that the PFJ allows Microsoft to support its browser market share by tying the browser to the operating system, this claim seems to rest on the optimistic hope that some new disruptive technology will appear, will be ignored by Microsoft, and will create massive consumer demand for some non-Microsoft Middleware. Without such an event, the PFJ merely establishes rules for a game that has no players.
5. Finally, in a bizarre and extreme limitation, the PFJ will expire in only five years-regardless of whether or not Microsoft retains its operating systems monopoly (PFJ, V.A). The DOJ must believe that not only is the PFJ an effective remedy, but that it will be so effective that Microsoft will be reduced to a shadow of its former self and must be unshackled in just five years (seven, if the Plaintiffs seek and receive the maximum extension permitted by the PFJ). Unfortunately, this clause is so careless that it will release Microsoft no matter the circumstances-that is, even if Microsoft retains or even strengthens its monopoly power. The message that the PFJ sends is "we'll try this for five years, and then we're giving up."
Any judgement should remain in effect until the Court finds that Microsoft no longer holds a monopoly in Intel-compatible operating systems. It makes little sense to release Microsoft until competition has re-entered the market and Microsoft may no longer commit the illegal acts described by the Court's Findings of Fact.
This PFJ illustrates the difficulty in devising effective conduct remedies for complex software cases such as this, especially where the defendant retains its monopoly power and the incentive to expand and maintain it by any method not prohibited by the PFJ. Vague technical definitions and even apparently narrow exemptions can be exploited by the monopolist to maintain its ill-gotten gains. It would be vastly preferable to create the proper structural conditions for competition by decoupling parts of the monopolist enterprise.
Without a structural remedy, it is imperative that the definitions and prohibitions in the Final Judgement be as clear and comprehensive as possible, so as to fully restrict the anti-competitive behavior that has been denying consumers choice, innovation and fair market pricing. There are a number of specific changes that ought to be made to the PFJ:
- Any judgement should remain in effect until Microsoft no longer holds a monopoly in Intel-compatible operating systems. Starting in 5 years, the Court should annually review Microsoft's position in the Intel-compatible operating systems market. Should it find that Microsoft no longer exercises monopoly power in that market, and therefore cannot commit the illegal acts described in the Court's Findings of Fact, it could release Microsoft from the terms of the judgement.
- The TC should be appointed entirely by the Plaintiffs, perhaps with the DOJ appointing one member, the States appointing a second member, and the Plaintiffs collectively appointing the third.
- Definitions such as that of "Microsoft Middleware" should be tightened considerably, and the PFJ reworked to minimize its reliance on such narrow categories.
- Microsoft should be required to make the full source-code for its Intel-compatible operating systems available for viewing by ISVs et al.. This will allow ISVs to better develop competitive products, and will allow the ISVs themselves to monitor Microsoft's compliance with the judgement's other technical requirements, instead of relying on an inefficient, overworked TC.
- If the Court decides against requiring source-code sharing, it should at a minimum require the disclosure of all operating system APIs used by any Microsoft products (i.e. not just those APIs used by Microsoft Middleware). A blanket disclosure requirement such as this will close those existing loopholes whereby Microsoft might withhold critical information from ISVs whose products threaten its operating system monopoly.
- Exemptions permitting various proscribed behaviors under certain circumstances should, as a whole, be stricken.
- Finally, the judgment should include real consequences for non-compliance, such as further conduct prohibitions, financial penalties, or further disclosure requirements. The PFJ currently provides only a possible Court-imposed two-year extension of its rather toothless provisions.
I hope that the PFJ is modified by the DOJ or the Court, and that what seems to be a great opportunity for antitrust law to make a difference for tomorrow's entrepreneurs and consumers is not lost in a fog of complexity. The technology may be complex and changing, but the underlying competitive issues are fundamental. I take both comfort and concern from the fact that I am clearly not alone in expressing these concerns. As the Financial Times editorialized:
It would be wrong for the states, or the judge, to reject this settlement merely because it is not sufficiently punitive. The test is whether the proposal provides enough protection for the public and for Microsoft's competitors. As it stands, it does not meet this test. Though a continued trial would be expensive and distracting, it would be better than an unsatisfactory settlement. This proposal should be rejected..
(Financial Times, "Micro-too-soft", November 5, 2001)
I believe that the PFJ, if accepted by the Court in its current form, will lead to clear and irreparable harm to consumers and to the United States' technology industry. So pervasive has technology become that the technology industry is an obviously critical component of the American economy. Even BusinessWeek, itself no anti-capitalist Microsoft critic, recognized the broad implications of the resolution of this case:
[T]he Justice Dept.'s weak censure of Microsoft for its serious monopolistic practices could cost the U.S. mightily in the years ahead. The great strengths of the American economy are its openness, its competitiveness, and its innovativeness. Monopoly is the enemy of all three.
(BusinessWeek, "Slapping Microsoft's Wrist", November 19, 2001)
Based on my experience, I do not find the PFJ to be in the "public interest", which is the standard that the DOJ and the Court are subject to under the Tunney Act.
January 28, 2002