|From: || email@example.com@inetgw|
|To:|| Microsoft ATR|
|Date:|| 1/28/02 4:39pm|
|Subject:|| Microsoft Settlement|
[Text body exceeds maximum size of message body (8192 bytes). It has
been converted to attachment.]
Subject: Microsoft Settlement
To: Renata B. Hesse
U.S. Department of Justice
601 D Street NW
Washington, DC 20530-0001
28 January 2002
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. Please find my comments below. A copy of my comments
is also posted on the Web at http://kegel.com/remedy/remedy2.html.
(available at end of this web page)
901 S. Sycamore
Los Angeles, CA 90036
On the Proposed
Final Judgment in United States v. Microsoft
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
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 firstname.lastname@example.org.
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
PFJ Section III: Prohibited Conduct
- 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).
- Microsoft will publish the wholesale prices it charges the top 20
OEMs (Original Equipment Manufacturers) for Windows.
- Microsoft will allow OEMs to customize the Windows menus, desktop,
and boot sequence, and will allow the use of non-Microsoft bootloaders.
- 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.
- Microsoft will license on reasonable terms the network protocols
needed for non-Microsoft applications or operating systems to connect
to Windows servers.
- Microsoft will not force business partners to refrain from supporting
competitors to Windows, IE, MJ, WMP, WM, or OE.
- (Roughly same as F above.)
- 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.
- Microsoft will license on reasonable terms any intellectual property
rights needed for other companies to take advantage of the terms of
- This agreement lets Microsoft keep secret anything having to do
with security or copy protection.
PFJ Section VI: Definitions
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.
- "API" (Application Programming Interface) is defined as
only the interfaces between Microsoft Middleware and Microsoft Windows,
excluding Windows APIs used by other application programs.
- "Microsoft Middleware Product" is defined as Internet
Explorer (IE), Microsoft Java (MJ), Windows Media Player (WMP), Windows
Messenger (WM), and Outlook Express (OE).
- "Windows Operating System Product" is defined as Windows
2000 Professional, Windows XP Home, and Windows XP Professional.
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.
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:
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.
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:
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).
- 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.
- 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
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
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
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
"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
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.
The PFJ tries to erode the Applications Barrier to Entry in two ways:
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
- By forbidding retaliation against OEMs, ISVs, and IHVs who support
or develop alternatives to Windows.
- By taking various measures to ensure that Windows allows the use
of non-Microsoft middleware.
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.
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
The PFJ provides for increased disclosure of technical information to
ISVs, but these provisions are flawed in several ways:
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
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.
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.
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.
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).
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,
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
The PFJ, by allowing this unclear legal situation to continue, is inhibiting
the market acceptance of competing operating systems.
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
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.
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.
The Microsoft Windows Media Encoder 7.1 SDK EULA
... 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.
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
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.
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.
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
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."
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,
consolidated response to Microsoft's motions for partial summary judgment.)
The judge in the case ruledthat
"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.
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.
- The PFJ doesn't take into account Windows-compatible competing operating
- The PFJ Contains Misleading and Overly Narrow Definitions and Provisions
- The PFJ Fails to Prohibit Anticompetitive License Terms currently
used by Microsoft
- The PFJ Fails to Prohibit Intentional Incompatibilities Historically
Used by Microsoft
- The PFJ Fails to Prohibit Anticompetitive Practices Towards OEMs
- The PFJ as currently written appears to
lack an effective enforcement mechanism.
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 <http://www.naag.org/features/microsoft/ms-remedy_filing.pdf> 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 [
Time constraints do not permit a complete list of needed changes. As an
example, Definition U should be amended to read
and new text in bold italics.
U. "Windows Operating System Product" means [
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.
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.
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 ... [
Second, a new section IV.E should be created as follows:
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,
E. Establishment of a Windows API Standards Expert
Third, in section VI, Definition A should be amended to read
- 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.
- 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.
- 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.
- 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
- 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.
- 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:
- 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.
- 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.
- Microsoft shall provide the WASEG with funds needed to
procure office space, telephone, other office support facilities,
consultants, or contractors required by the WASEG.
- 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.
- The WASEG shall have the following powers and duties:
- The WASEG may require Microsoft to provide comprehensive
answers to questions about Microsoft intellectual property claims.
- 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.
- 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.
- 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
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
A. ``Application Programming Interfaces (APIs)'' means the
interfaces, including any associated callback interfaces, that [
and two new definitions should be added:
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
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
§ III. A. 2. of the Proposed Final Judgment should be amended to
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:
- any claims other than as set forth above even if contained
in the same patent as Essential Claims; and
- 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.
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 ...
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.