On the Proposed Final Judgment in United States v. Microsoft

Contents

Introduction

As a software engineer with 20 years' experience developing software for Unix, Windows, Macintosh, and Linux, I'd like to comment on the Proposed Final Judgment in United States v. Microsoft.

According to the Court of Appeals ruling, "a remedies decree in an antitrust case must seek to 'unfetter a market from anticompetitive conduct', to 'terminate the illegal monopoly, deny to the defendant the fruits of its statutory violation, and ensure that there remain no practices likely to result in monopolization in the future" (section V.D., p. 99).

Attorney General John Ashcroft seems to agree; he called the proposed settlement "strong and historic", said that it would end "Microsoft's unlawful conduct," and said "With the proposed settlement being announced today, the Department of Justice has fully and completely addressed the anti-competitive conduct outlined by the Court of Appeals against Microsoft."

Yet the Proposed Final Judgment allows many exclusionary practices to continue, and does not take any direct measures to reduce the Applications Barrier to Entry faced by new entrants to the market.

The Court of Appeals affirmed that Microsoft has a monopoly on Intel-compatible PC operating systems, and that the company's market position is protected by a substantial barrier to entry (p. 15). Furthermore, the Court of Appeals affirmed that Microsoft is liable under Sherman Act § 2 for illegally maintaining its monopoly by imposing licensing restrictions on OEMs, IAPs (Internet Access Providers), ISVs (Independent Software Vendors), and Apple Computer, by requiring ISVs to switch to Microsoft's JVM (Java Virtual Machine), by deceiving Java developers, and by forcing Intel to drop support for cross-platform Java tools.

The fruits of Microsoft's statutory violation include a strengthened Applications Barrier to Entry and weakened competition in the Intel-compatible operating system market; thus the Final Judgment must find a direct way of reducing the Applications Barrier to Entry, and of increasing such competition.

In the following sections I outline the basic intent of the proposed final judgment, point out areas where the intent and the implementation appear to fall short, and propose amendments to the Proposed Final Judgment (or PFJ) to address these concerns.

Please note that this document is still evolving. Feedback is welcome; to comment on this document, please join the mailing list at groups.yahoo.com/group/ms-remedy, or email me directly at dank-ms@kegel.com.

Understanding the Proposed Final Judgment

In crafting the Final Judgment, the judge will face the following questions: Here is a very rough summary which paraphrases provisions III.A through III.J and VI. of the Proposed Final Judgment to give some idea of how the PFJ proposes to answer those questions:

PFJ Section III: Prohibited Conduct

  1. Microsoft will not retaliate against OEMs who support competitors to Windows, Internet Explorer (IE), Microsoft Java (MJ), Windows Media Player (WMP), Windows Messenger (WM), or Outlook Express (OE).
  2. Microsoft will publish the wholesale prices it charges the top 20 OEMs (Original Equipment Manufacturers) for Windows.
  3. Microsoft will allow OEMs to customize the Windows menus, desktop, and boot sequence, and will allow the use of non-Microsoft bootloaders.
  4. Microsoft will publish on MSDN (the Microsoft Developer Network) the APIs used by IE, MJ, WMP, WM, and OE, so that competing web browsers, media players, and email clients can plug in properly to Windows.
  5. Microsoft will license on reasonable terms the network protocols needed for non-Microsoft applications or operating systems to connect to Windows servers.
  6. Microsoft will not force business partners to refrain from supporting competitors to Windows, IE, MJ, WMP, WM, or OE.
  7. (Roughly same as F above.)
  8. Microsoft will let users and OEMs remove icons for IE, MJ, WMP, WM, and OE, and let them designate competing products to be used instead.
  9. Microsoft will license on reasonable terms any intellectual property rights needed for other companies to take advantage of the terms of this settlement.
  10. This agreement lets Microsoft keep secret anything having to do with security or copy protection.

PFJ Section VI: Definitions

  1. "API" (Application Programming Interface) is defined as only the interfaces between Microsoft Middleware and Microsoft Windows, excluding Windows APIs used by other application programs.
  2. "Microsoft Middleware Product" is defined as Internet Explorer (IE), Microsoft Java (MJ), Windows Media Player (WMP), Windows Messenger (WM), and Outlook Express (OE).
  3. "Windows Operating System Product" is defined as Windows 2000 Professional, Windows XP Home, and Windows XP Professional.
The agreement can be summed up in one breath as follows: Microsoft agrees to compete somewhat less vigorously, and to let competitors interoperate with Windows in exchange for royalty payments.

Considering all of the above, one should read the detailed terms of the Proposed Final Judgment, and ask one final question:

In the sections below, I'll look in more detail at how the PFJ deals with the above questions.

How should terms like "API", "Middleware, and "Windows OS" be defined?

The definitions of various terms in Part VI of the PFJ differ from the definitions in the Findings of Fact and in common usage, apparently to Microsoft's benefit. Here are some examples:

Definition A: "API"

The Findings of Fact (¶ 2) define "API" to mean the interfaces between application programs and the operating system. However, the PFJ's Definition A defines it to mean only the interfaces between Microsoft Middleware and Microsoft Windows, excluding Windows APIs used by other application programs. For instance, the PFJ's definition of API might omit important APIs such as the Microsoft Installer APIs which are used by installer programs to install software on Windows.

Definition J: "Microsoft Middleware"

The Findings of Fact (¶ 28) define "middleware" to mean application software that itself presents a set of APIs which allow users to write new applications without reference to the underlying operating system. Definition J defines it in a much more restrictive way, and allows Microsoft to exclude any software from being covered by the definition in two ways:
  1. By changing product version numbers. For example, if the next version of Internet Explorer were named "7.0.0" instead of "7" or "7.0", it would not be deemed Microsoft Middleware by the PFJ.
  2. By changing how Microsoft distributes Windows or its middleware. For example, if Microsoft introduced a version of Windows which was only available via the Windows Update service, then nothing in that version of Windows would be considered Microsoft Middleware, regardless of whether Microsoft added it initially or in a later update. This is analogous to the loophole in the 1995 consent decree that allowed Microsoft to bundle its browser by integrating it into the operating system.

Definition K: "Microsoft Middleware Product"

Definition K defines "Microsoft Middleware Product" to mean essentially Internet Explorer (IE), Microsoft Java (MJ), Windows Media Player (WMP), Windows Messenger (WM), and Outlook Express (OE).

The inclusion of Microsoft Java and not Microsoft.NET is questionable; Microsoft has essentially designated Microsoft.NET and C# as the successors to Java, so on that basis one would expect Microsoft.NET to be included in the definition.

The inclusion of Outlook Express and not Outlook is questionable, as Outlook (different and more powerful than Outlook Express) is a more important product in business, and fits the definition of middleware better than Outlook Express.

The exclusion of Microsoft Office is questionable, as many components of Microsoft Office fit the Finding of Fact's definition of middleware. For instance, there is an active market in software written to run on top of Microsoft Outlook and Microsoft Word, and many applications are developed for Microsoft Access by people who have no knowledge of Windows APIs.

Definition U: "Windows Operating System Product"

Microsoft's monopoly is on Intel-compatible operating systems. Yet the PFJ in definition U defines a "Windows Operating System Product" to mean only Windows 2000 Professional, Windows XP Home, Windows XP Professional, and their successors. This purposely excludes the Intel-compatible operating systems Windows XP Tablet PC Edition and Windows CE; many applications written to the Win32 APIs can run unchanged on Windows 2000, Windows XP Tablet PC Edition, and Windows CE, and with minor recompilation, can also be run on Pocket PC. Microsoft even proclaims at www.microsoft.com/windowsxp/tabletpc/tabletpcqanda.asp:
"The Tablet PC is the next-generation mobile business PC, and it will be available from leading computer makers in the second half of 2002. The Tablet PC runs the Microsoft Windows XP Tablet PC Edition and features the capabilities of current business laptops, including attached or detachable keyboards and the ability to run Windows-based applications."
and
Pocket PC: Powered by Windows
Microsoft is clearly pushing Windows XP Tablet PC Edition and Pocket PC in places (e.g. portable computers used by businessmen) currently served by Windows XP Home Edition, and thus appears to be trying to evade the Final Judgment's provisions. This is but one example of how Microsoft can evade the provisions of the Final Judgment by shifting its efforts away from the Operating Systems listed in Definition U and towards Windows XP Tablet Edition, Windows CE, Pocket PC, X-Box, or some other Microsoft Operating System that can run Windows applications.

How should the Final Judgment erode the Applications Barrier to Entry?

The PFJ tries to erode the Applications Barrier to Entry in two ways:
  1. By forbidding retaliation against OEMs, ISVs, and IHVs who support or develop alternatives to Windows.
  2. By taking various measures to ensure that Windows allows the use of non-Microsoft middleware.
A third option not provided by the PFJ would be to make sure that Microsoft raises no artificial barriers against non-Microsoft operating systems which implement the APIs needed to run application programs written for Windows. The Findings of Fact (¶52) considered the possibility that competing operating systems could implement the Windows APIs and thereby directly run software written for Windows as a way of circumventing the Applications Barrier to Entry. This is in fact the route being taken by the Linux operating system, which includes middleware (named WINE) that can run many Windows programs.

By not providing some aid for ISVs engaged in making Windows-compatible operating systems, the PFJ is missing a key opportunity to encourage competition in the Intel-compatible operating system market. Worse yet, the PFJ itself, in sections III.D. and III.E., restricts information released by those sections to be used "for the sole purpose of interoperating with a Windows Operating System Product". This prohibits ISVs from using the information for the purpose of writing operating systems that interoperate with Windows programs.

How should the Final Judgment be enforced?

The PFJ as currently written appears to lack an effective enforcement mechanism. It does provide for the creation of a Technical Committee with investigative powers, but appears to leave all actual enforcement to the legal system.

What information needs to be released to ISVs to encourage competition, and under what terms?

The PFJ provides for increased disclosure of technical information to ISVs, but these provisions are flawed in several ways:

1. The PFJ fails to require advance notice of technical requirements

Section III.H.3. of the PFJ requires vendors of competing middleware to meet "reasonable technical requirements" seven months before new releases of Windows, yet it does not require Microsoft to disclose those requirements in advance. This allows Microsoft to bypass all competing middleware simply by changing the requirements shortly before the deadline, and not informing ISVs.

2. API documentation is released too late to help ISVs

Section III.D. of the PFJ requires Microsoft to release via MSDN or similar means the documentation for the APIs used by Microsoft Middleware Products to interoperate with Windows; release would be required at the time of the final beta test of the covered middleware, and whenever a new version of Windows is sent to 150,000 beta testers. But this information would almost certainly not be released in time for competing middleware vendors to adapt their products to meet the requirements of section III.H.3, which states that competing middleware can be locked out if it fails to meet unspecified technical requirements seven months before the final beta test of a new version of Windows.

3. Many important APIs would remain undocumented

The PFJ's overly narrow definitions of "Microsoft Middleware Product" and "API" means that Section III.D.'s requirement to release information about Windows interfaces would not cover many important interfaces.

4. Unreasonable Restrictions are Placed on the Use of the Released Documentation

ISVs writing competing operating systems as outlined in Findings of Fact (¶52) sometimes have difficulty understanding various undocumented Windows APIs. The information released under section III.D. of the PFJ would aid those ISVs -- except that the PFJ disallows this use of the information. Worse yet, to avoid running afoul of the PFJ, ISVs might need to divide up their engineers into two groups: those who refer to MSDN and work on Windows-only applications; and those who cannot refer to MSDN because they work on applications which also run on non-Microsoft operating systems. This would constitute retaliation against ISVs who support competing operating systems.

5. File Formats Remain Undocumented

No part of the PFJ obligates Microsoft to release any information about file formats, even though undocumented Microsoft file formats form part of the Applications Barrier to Entry (see "Findings of Fact" ¶20 and ¶ 39).

6. Patents covering the Windows APIs remain undisclosed

Section III.I of the PFJ requires Microsoft to offer to license certain intellectual property rights, but it does nothing to require Microsoft to clearly announce which of its many software patents protect the Windows APIs (cf. current practice at the World Wide Web Consortium, http://www.w3.org/TR/patent-practice). This leaves Windows-compatible operating systems in an uncertain state: are they, or are they not infringing on Microsoft software patents? This can scare away potential users, as illustrated by this report from Codeweavers, Inc.:
When selecting a method of porting a major application to Linux, one prospect of mine was comparing Wine [a competing implementation of some of the Windows APIs] and a toolkit called 'MainWin'. MainWin is made by Mainsoft, and Mainsoft licenses its software from Microsoft. However, this customer elected to go with the Mainsoft option instead. I was told that one of the key decision making factors was that Mainsoft representatives had stated that Microsoft had certain critical patents that Wine was violating. My customer could not risk crossing Microsoft, and declined to use Wine. I didn't even have a chance to determine which patents were supposedly violated; nor to disprove the validity of this claim.
The PFJ, by allowing this unclear legal situation to continue, is inhibiting the market acceptance of competing operating systems.

Which practices towards OEMs should be prohibited?

The PFJ prohibits certain behaviors by Microsoft towards OEMs, but curiously allows the following exclusionary practices:

Section III.A.2. allows Microsoft to retaliate against any OEM that ships Personal Computers containing a competing Operating System but no Microsoft operating system.

Section III.B. requires Microsoft to license Windows on uniform terms and at published prices to the top 20 OEMs, but says nothing about smaller OEMs. This leaves Microsoft free to retaliate against smaller OEMs, including important regional 'white box' OEMs, if they offer competing products.

Section III.B. also allows Microsoft to offer unspecified Market Development Allowances -- in effect, discounts -- to OEMs. For instance, Microsoft could offer discounts on Windows to OEMs based on the number of copies of Microsoft Office or Pocket PC systems sold by that OEM. In effect, this allows Microsoft to leverage its monopoly on Intel-compatible operating systems to increase its market share in other areas, such as office software or ARM-compatible operating systems.

By allowing these practices, the PFJ is encouraging Microsoft to extend its monopoly in Intel-compatible operating systems, and to leverage it into new areas.

Which practices towards ISVs should be prohibited?

Sections III.F. and III.G. of the PFJ prohibit certain exclusionary licensing practices by Microsoft towards ISVs.

However, Microsoft uses other exclusionary licensing practices, none of which are mentioned in the PFJ. Several of Microsoft's products' licenses prohibit the products' use with popular non-Microsoft middleware and operating systems. Two examples are given below.

1. Microsoft discriminates against ISVs who ship Open Source or Free Software applications

The Microsoft Windows Media Encoder 7.1 SDK EULA states
... you shall not distribute the REDISTRIBUTABLE COMPONENT in conjunction with any Publicly Available Software. "Publicly Available Software" means each of (i) any software that contains, or is derived in any manner (in whole or in part) from, any software that is distributed as free software, open source software (e.g. Linux) or similar licensing or distribution models ... Publicly Available Software includes, without limitation, software licensed or distributed under any of the following licenses or distribution models, or licenses or distribution models similar to any of the following: GNU's General Public License (GPL) or Lesser/Library GPL (LGPL); The Artistic License (e.g., PERL); the Mozilla Public License; the Netscape Public License; the Sun Community Source License (SCSL); ...
Many Windows APIs, including Media Encoder, are shipped by Microsoft as add-on SDKs with associated redistributable components. Applications that wish to use them must include the add-ons, even though they might later become a standard part of Windows. Microsoft often provides those SDKs under End User License Agreements (EULAs) prohibiting their use with Open Source or Free Software applications. This harms ISVs who choose to distribute their applications under Open Source or Free Software licenses; they must hope that the enduser has a sufficiently up-to-date version of the addon API installed, which is often not the case.

Applications potentially harmed by this kind of EULA include the competing middleware product Netscape 6 and the competing office suite StarOffice; these EULAs thus can cause support problems for, and discourage the use of, competing middleware and office suites. Additionally, since Open Source or Free Software applications tend to also run on non-Microsoft operating systems, any resulting loss of market share by Open Source or Free Software applications indirectly harms competing operating systems.

2. Microsoft discriminates against ISVs who target Windows-compatible competing Operating Systems

The Microsoft Platform SDK, together with Microsoft Visual C++, is the primary toolkit used by ISVs to create Windows-compatible applications. The Microsoft Platform SDK EULA says:
"Distribution Terms. You may reproduce and distribute ... the Redistributable Components... provided that (a) you distribute the Redistributable Components only in conjunction with and as a part of your Application solely for use with a Microsoft Operating System Product..."
This makes it illegal to run many programs built with Visual C++ on Windows-compatible competing operating systems.

By allowing these exclusionary behaviors, the PFJ is contributing to the Applications Barrier to Entry faced by competing operating systems.

Which practices towards large users should be prohibited?

The PFJ places restrictions on how Microsoft licenses its products to OEMs, but not on how it licenses products to large users such as corporations, universities, or state and local governments, collectively referred to as 'enterprises'. Yet enterprise license agreements often resemble the per-processor licenses which were prohibited by the 1994 consent decree in the earlier US v. Microsoft antitrust case, in that a fee is charged for each desktop or portable computer which could run a Microsoft operating system, regardless of whether any Microsoft software is actually installed on the affected computer. These agreements are anticompetitive because they remove any financial incentive for individuals or departments to run non-Microsoft software.

Which practices towards end users should be prohibited?

Microsoft has used both restrictive licenses and intentional incompatibilities to discourage users from running Windows applications on Windows-compatible competing operating systems. Two examples are given below.

1. Microsoft uses license terms which prohibit the use of Windows-compatible competing operating systems

MSNBC (a subsidiary of Microsoft) offers software called NewsAlert. Its EULA states
"MSNBC Interactive grants you the right to install and use copies of the SOFTWARE PRODUCT on your computers running validly licensed copies of the operating system for which the SOFTWARE PRODUCT was designed [e.g., Microsoft Windows(r) 95; Microsoft Windows NT(r), Microsoft Windows 3.x, Macintosh, etc.]. ..."
Only the Windows version appears to be available for download. Users who run competing operating systems (such as Linux) which can run some Windows programs might wish to run the Windows version of NewsAlert, but the EULA prohibits this.

MSNBC has a valid interest in prohibiting use of pirated copies of operating systems, but much narrower language could achieve the same protective effect with less anticompetitive impact. For instance,

"MSNBC Interactive grants you the right to install and use copies of the SOFTWARE PRODUCT on your computers running validly licensed copies of Microsoft Windows or compatible operating system."

2. Microsoft created intentional incompatibilities in Windows 3.1 to discourage the use of non-Microsoft operating systems

An episode from the 1996 Caldera v. Microsoft antitrust lawsuit illustrates how Microsoft has used technical means anticompetitively.

Microsoft's original operating system was called MS-DOS. Programs used the DOS API to call up the services of the operating system. Digital Research offered a competing operating system, DR-DOS, that also implemented the DOS API, and could run programs written for MS-DOS. Windows 3.1 and earlier were not operating systems per se, but rather middleware that used the DOS API to interoperate with the operating system. Microsoft was concerned with the competitive threat posed by DR-DOS, and added code to beta copies of Windows 3.1 so it would display spurious and misleading error messages when run on DR-DOS. Digital Research's successor company, Caldera, brought a private antitrust suit against Microsoft in 1996. (See the original complaint, and Caldera's consolidated response to Microsoft's motions for partial summary judgment.) The judge in the case ruled that

"Caldera has presented sufficient evidence that the incompatibilities alleged were part of an anticompetitive scheme by Microsoft."
That case was settled out of court in 1999, and no court has fully explored the alleged conduct.

The concern here is that, as competing operating systems emerge which are able to run Windows applications, Microsoft might try to sabotage Windows applications, middleware, and development tools so that they cannot run on non-Microsoft operating systems, just as they did earlier with Windows 3.1.

The PFJ as currently written does nothing to prohibit these kinds of restrictive licenses and intentional incompatibilities, and thus encourages Microsoft to use these techniques to enhance the Applications Barrier to Entry, and harming those consumers who use non-Microsoft operating systems and wish to use Microsoft applications software.

Is the Proposed Final Judgment in the public interest?

The problems identified above with the Proposed Final Judgment can be summarized as follows: Considering these problems, one must conclude that the Proposed Final Judgment as written allows and encourages significant anticompetitive practices to continue, and would delay the emergence of competing Windows-compatible operating systems. Therefore, the Proposed Final Judgment is not in the public interest, and should not be adopted without addressing these issues.

Strengthening the PFJ

The above discussion shows that the PFJ does not satisfy the Court of Appeals' mandate. Some of the plaintiff States have proposed an alternate settlement which fixes many of the problems identified above. The States' proposal is quite different from the PFJ as a whole, but it contains many elements which are similar to elements of the PFJ, with small yet crucial changes.

In the sections below, I suggest amendments to the PFJ that attempt to resolve some of the demonstrated problems (time pressure has prevented anything like a complete list of amendments). When discussing amendments, PFJ text is shown indented; removed text in shown in [bracketed strikeout], and new text in bold italics.

Correcting the PFJ's definitions

Time constraints do not permit a complete list of needed changes. As an example, Definition U should be amended to read
U. "Windows Operating System Product" means [the software code (as opposed to source code) distributed commercially by Microsoft for use with Personal Computers as Windows 2000 Professional, Windows XP Home, Windows XP Professional, and successors to the foregoing, including the Personal Computer versions of the products currently code named "Longhorn" and "Blackcomb" and their successors, including upgrades, bug fixes, service packs, etc. The software code that comprises a Windows Operating System Product shall be determined by Microsoft in its sole discretion. ] any software or firmware code distributed commercially by Microsoft that is capable of executing any nontrivial subset of the Win32 APIs, including without exclusion Windows 2000 Professional, Windows XP Home, Windows XP Professional, Windows XP Tablet PC Edition, Windows CE, PocketPC 2002, and successors to the foregoing, including the products currently code named "Longhorn" and "Blackcomb" and their successors, including upgrades, bug fixes, service packs, etc.

Release of Information

Because any new competitor in the Intel-compatible operating system market must be able to run Windows applications to have a chance in the market, and because Microsoft has traditionally used undocumented Windows APIs as part of the Applications Barrier to Entry, the Final Judgment should provide explicitly for a clear definition of what APIs a competing operating system must provide to run Windows applications. The best way to do this is by submitting the API definitions to a standards body. This was done in 1994 for the Windows 3.1 APIs (see Sun's 1994 press release about WABI 2.0 and the Public Windows Initiative). The result is Standard ECMA-234: Application Programming Interface for Windows (APIW), which provides standard definitions for an essential subset (four hundred and fourty-four out of the roughly one thousand) of the Windows 3.1 APIs; it was rendered mostly obsolete by the switch to Windows 95. The Final Judgment should provide for the creation of something like ECMA-234 for the various modern versions of Windows.

Because Microsoft currently claims that it has intellectual property rights that protect the Windows APIs, but has never spelled out exactly which patents cover which APIs, the Final Judgment should force this to be spelled out.

To achieve the above goals, the PFJ should be modified as follows:

First, Sections III.D and III.E should be amended to remove the restriction on the use of the disclosed information:

... Microsoft shall disclose ... [for the sole purpose of interoperating with a Windows Operating System Product,] for the purpose of interoperating with a Windows Operating System Product or interoperating with application software written for Windows,
Second, a new section IV.E should be created as follows:
E. Establishment of a Windows API Standards Expert Group
  1. Within 60 days of entry of this Final Judgment, the parties shall create and recommend to the Court for its appointment a six person Windows API Standards Expert Group (``WASEG'') to manage the creation, publication, and maintenance of a Windows APIs Standards Definition (``WASD'') and associated Windows APIs Standard Compliance Test Suite (``WASCTS''), and to guide the WASD through the process of being adopted by a standards body such as ECMA or the IEEE.

    The WASD shall be a document, suitable for approval by a standards body such as ECMA or IEEE, which accurately defines the inputs, outputs, and behavior of each Windows API, and enumerates any Essential Claims.

    The WASCTS shall be software source code which, when compiled and run, automatically tests an operating system for compliance with the WASD, and produces a list of APIs which fail to comply with the WASD. The test suite should run unattended; that is, it should be capable of running without human interaction or supervision.

  2. Three of the WASEG members shall be experts in software design and programming, and three of the WASEG members shall be experts in intellectual property law. No WASEG member shall have a conflict of interest that could prevent him or her from performing his or her duties under this Final Judgment in a fair and unbiased manner. No WASEG member shall have entered into any non-disclosure agreement that is still in force with Microsoft or any competitor to Microsoft, nor shall she or he enter into such an agreement during her or his term on the WASEG. Without limitation to the foregoing, no WASEG member shall have been employed in any capacity by Microsoft or any competitor to Microsoft within the past year, nor shall he or she be so employed during his or her term on the WASEG.
  3. Within seven days of entry of this Final Judgment, the Plaintiffs as a group shall select two software experts and two intellectual property law experts to be members of the WASEG, and Microsoft shall select one software expert and one intellectual property law expert to be members of the WASEG; the Plaintiffs shall then apply to the Court for appointment of the persons selected by the Plaintiffs and Microsoft pursuant to this section.
  4. Each WASEG member shall serve for an initial term of 30 months. At the end of a WASEG member's initial 30-month term, the party that originally selected him or her may, in its sole discretion, either request re-appointment by the Court to a second 30-month term or replace the WASEG member in the same manner as provided for above.
  5. If the United States or a majority of the Plaintiffs determine that a member of the WASEG has failed to act diligently and consistently with the purposes of this Final Judgment, or if a member of the WASEG resigns, or for any other reason ceases to serve in his or her capacity as a member of the WASEG, the person or persons that originally selected the WASEG member shall select a replacement member in the same manner as provided for above.
  6. Promptly after appointment of the WASEG by the Court, the United States shall enter into a Windows API Expert Group services agreement (``WASEG Services Agreement'') with each WASEG member that grants the rights, powers and authorities necessary to permit the WASEG to perform its duties under this Final Judgment. Microsoft shall indemnify each WASEG member and hold him or her harmless against any losses, claims, damages, liabilities or expenses arising out of, or in connection with, the performance of the WASEG's duties, except to the extent that such liabilities, losses, damages, claims, or expenses result from misfeasance, gross negligence, willful or wanton acts, or bad faith by the WASEG member. The WASEG Services Agreements shall include the following:
    1. The WASEG members shall serve, without bond or other security, at the cost and expense of Microsoft on such terms and conditions as the Plaintiffs approve, including the payment of reasonable fees and expenses.
    2. The WASEG Services Agreement shall provide that each member of the WASEG shall comply with the limitations provided for in section IV.E.2. above.
  7. Microsoft shall provide the WASEG with funds needed to procure office space, telephone, other office support facilities, consultants, or contractors required by the WASEG.
  8. The WASEG shall not have direct access to any part of Microsoft's computer software source code that is not normally available to all ISVs. The WASEG shall not enter into any non-disclosure agreements with Microsoft or third parties. No implementations of any Windows APIs shall be written or published by the WASEG.
  9. The WASEG shall have the following powers and duties:
    1. The WASEG may require Microsoft to provide comprehensive answers to questions about Microsoft intellectual property claims.
    2. The WASEG may require Microsoft to provide comprehensive answers to questions about the inputs, outputs, and functionality of any Windows API; in particular, the WASEG may compel Microsoft to provide complete documentation for Windows APIs, including hitherto undocumented or poorly-documented Windows APIs.
    3. The WASEG may engage, at the cost and expense of Microsoft, the services of outside consultants and contractors as required to fulfill the duties of the WASEG.
    4. The WASEG shall establish a publicly available web site not owned or otherwise controlled by Microsoft, and will publish status reports and other information there at least as often as once per month. Documentation on the web site shall be made available subject to the terms of the GNU Free Documentation License; test suite source code made available on the web site shall be made available subject to the terms of the GNU General Public License.
    5. The WASEG shall compile to the best of their ability a complete list of Windows APIs, including for each API the DLL name, entry point name, entry point ordinal number, return value type, and parameter types, as well as which versions of Windows it is supported by and an estimate of what percentage of Popular Windows Applications use it. The WASEG shall publish this list on the WASEG web site subject to the GNU Free Documentation License, according to the following schedule: Within 90 days after the WASEG is convened, the WASEG shall publish this information for at least five hundred Windows APIs. On the 1st of each month thereafter, the WASEG shall publish this information for another five hundred Windows APIs. This shall continue until a complete list of Windows APIs is available on the web site. The WASEG shall update the list periodically to add previously unlisted Windows APIs. The WASEG shall periodically check the list for completeness by installing and running a representative sample of Popular Windows Applications and Microsoft Middleware while using tools such as Apius from Sarion Systems Research to watch the Windows APIs actually invoked by the product or its installer. The WASEG shall also set up a way for third parties to report Windows APIs which should be listed, and shall update its list of Windows APIs accordingly as appropriate.
    6. The WASEG shall compile a complete list of Essential Claims, and an evaluation of which Windows APIs each Essential Claim covers. The WASEG shall publish this information on the WASEG web site subject to the GNU Free Documentation License, according to the following schedule: Within 90 days after the WASEG publishes a portion of the list of Windows APIs on its web site, Microsoft shall deliver to the WASEG a list of the Essential Claims that cover the published Windows APIs. Within 90 days after the WASEG receives the list of Essential Claims, the WASEG shall publish its evaluation of which APIs those Essential Claims cover. This shall continue until such evaluations for all Essential Claims have been published on the WASEG web site.
    7. The WASEG shall compile documentation for the list of Windows APIs defined above in section IV.E.9.e, including a complete description of the meanings of the return values and parameters, and the effects of the API. The documentation should be composed in a style similar to that used for the Single Unix Specification documentation ( http://www.UNIX-systems.org/go/unix). Within 180 days after the WASEG is convened, and on the 1st of every month thereafter until complete, the WASEG will make available the currently completed portion of this documentation via its web site.
    8. When the three documents described above - the list of Windows APIs, the list of Essential Claims and which Windows APIs they cover, and the documentation for the listed Windows APIs - is complete, the WASEG shall undertake to submit them to a standards body such as ECMA or the IEEE as a Draft WASD Document, and to make such enhancements and revisions as needed to gain the acceptance of that document as a standard.
    9. The WASEG shall create a WASCTS, and publish it on the WASEG web site subject to the GNU General Public License, according to the following schedule: Within 180 days after the WASEG is convened, the WASEG shall publish test cases for at least one hundred Windows APIs. On the 1st of each month thereafter, the WASEG shall publish test cases for at least another one hundred Windows APIs. This shall continue until a complete WASCTS is available on the web site.
    10. In the event that a planned update to Windows or any other Microsoft product is expected to result in the creation of new Windows APIs or Essential Claims, or WASEG's list of Windows APIs is updated, the WASEG shall create addenda to the WASD and WASCTS covering the new Windows APIs or Essential Claims, make them available via its web site, and undertake to submit them to the same standards body as above as an addendum to the standard.
Third, in section VI, Definition A should be amended to read
A. ``Application Programming Interfaces (APIs)'' means the interfaces, including any associated callback interfaces, that [ Microsoft Middleware running on a Windows Operating System Product uses to call upon that Windows Operating System Product in order to obtain any services from that Windows Operating System Product. ] Microsoft Middleware or Popular Windows Applications running or being installed on a Windows Operating System Product use to call upon that Windows Operating System Product or Microsoft Middleware in order to obtain any services from that Windows Operating System Product or Microsoft Middleware.
and two new definitions should be added:
V. "Popular Windows Applications" means the top 10 selling applications as reported by NPD Intelect Market Tracking in each of the categories Business, Education, Finance, Games, Personal Productivity, and Reference, plus all Microsoft Middleware Products.

W. "Essential Claims" shall mean all claims in any patent or patent application, in any jurisdiction in the world, that Microsoft owns, or under which Microsoft has the right to grant licenses without obligation of payment or other consideration to an unrelated third party, that would necessarily be infringed by implementation of the Windows APIs Standard Definition by a competing Operating System. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the required portion of the Windows APIs Standard Definition.

The following are expressly excluded from and shall not be deemed to constitute Essential Claims:

  1. any claims other than as set forth above even if contained in the same patent as Essential Claims; and
  2. claims which would be infringed only by portions of an implementation that are not required by the Windows APIs Standard Definition, or enabling technologies that may be necessary to make or use any product or portion thereof that complies with the Windows APIs Standard Definition but are not themselves expressly set forth in the Windows APIs Standard Definition (e.g., compiler technology, object-oriented technology, etc.) or the implementation of technology developed elsewhere and merely incorporated by reference in the body of the Windows APIs Standard Definition.

Prohibition of More Practices Toward OEMs

§ III. A. 2. of the Proposed Final Judgment should be amended to read
2. shipping a Personal Computer that (a) includes both a Windows Operating System Product and a non-Microsoft Operating System, or (b) will boot with more than one Operating System, or (c) includes a non-Microsoft Operating System but no Windows Operating System Product; or ...

Summary

This document demonstrates that there are so many problems with the PFJ that it is not in the public interest. It also illustrates how one might try to fix some of these problems.

Dan Kegel
28 January 2002
Return to "On the Remedy Phase of the Microsoft Antitrust Trial"