Comments on the Revised Proposed Final Judgment
http://www.meer.net/jg/doj_comments.html
John Giannandrea, Independent Software Developer,
Formerly ('94-'99) Chief Technologist in the Internet Browser group at
Netscape/AOL
Summary
After reviewing the Revised Proposed Final Judgment, the Competitive Impact
Statement, the May 18th 1998 Antitrust complaint together with the findings
of the District Court and the Court of Appeals I submit that the Proposed
Final Judgment fails to describe effective remedies for Microsoft's illegal
activities.
An effective Final Judgment would prevent recurrence of the illegal
behavior and provide relief and protection for independent software
developers to develop innovative new middle-ware products and compete with
Microsoft in the market for Windows software. The terms of this Final
Judgment will not achieve this result because it is seriously flawed.
These comments briefly describe the following problems with the Proposed
Final Judgment:
- Problems with the scope of the remedy
- Shortcomings in the OEM configuration provisions
- Loopholes and technical shortcomings with the wording of the judgment
- Restrictive language related to Intellectual Property.
- Problems with the term and proposed implementation
- Flaws in several of the definitions
Taken together I believe these flaws in Proposed Final Judgment make it an
inappropriate remedy for the illegal behaviors found by the Court of
Appeals. While changing some of the specific wording of the Final Judgment
and removing some of the loopholes will make it stronger, on balance it is
a wholly inappropriate remedy for the ongoing harm done by Microsoft in
protecting and extending its Windows monopoly.
jg@meer.net
January 27th, 2002.
---------------------------------------------------------------------------
1. Problems with the scope of the remedy
There are several problems with the scope of the proposed remedies which
are likely to make it ineffective in practice. The Final Judgment does not
correct the harm done to the marketplace today by Microsoft's existing
software products, nor address the issue of backwards compatibility and
harm done to the market by ongoing changes ("upgrades"). Nor does the Final
Judgment address the crucial issue of APIs in Microsoft middle-ware
products themselves, as opposed to APIs in the Windows Operating System
Product.
1.1 What products fall under the proposed remedy?
Sections III.D, III.E and III.H limit the practical effects of the Final
Judgment to some future versions of Microsoft's latest operating system
product (WindowsXP, SP1) or 12 months from submission of the Final
Judgment. This will not provide effective remedy for the actual installed
base of Windows users, of which WindowsXP remains a small minority.
Microsoft's monopoly position is, and will be for the length of the initial
proposed term, made up of Windows2000, WindowsME, Windows98 and Windows95
products and their associated middle-ware product lines. It is in these
products that harm is and was being caused by the illegal activities. For
the Final Judgment to be effective in providing relief, the communications
protocol and Windows API disclosures need to apply to the actual installed
base of Windows. It is no more technically difficult for Microsoft to
document current APIs than it is to do so in future products.
The final paragraph of III.H limits the proposed remedies to middle-ware as
defined by a timeline relative to the release of new Windows operating
system products. The reality is that the illegal conduct relates to all
existing and past Microsoft middle-ware products, and the release of future
versions of Windows will not significantly affect the harm being done in
the marketplace. There is no technical reason why existing Microsoft and
non-Microsoft middle-ware will not be compatible with future versions of
Windows. In fact Microsoft makes considerable effort to ensure that Windows
is "backwards compatible" with its own applications. Remedies need to apply
to all future versions of Windows, and all middle-ware now and in the
future, and the obligations of the monopoly holder should not change
unilaterally with a product release cycle under their express control. Much
of the harm found by the Court is related not just to the disclosure of
interfaces and APIs, but to the fact that Microsoft can stop supporting a
documented feature or API without consulting the affected parties.
One possible way to improve the Final Judgment would be to add a new
condition to III. C. that allows OEMs the option of shipping any prior
Microsoft middle-ware with any subsequent version of Windows.
1.2 Middle-ware APIs are as important as Windows APIs
Section III.D. proposes that Microsoft shall disclose APIs used by its
middle-ware to interoperate with a Windows operating system. Since
middle-ware such as Internet Explorer or Windows Media Player has added,
subtracted or altered significant APIs with each subsequent version,
including minor, so called "maintenance" versions, and since these APIs are
depended on by the the majority of ISVs. III.D. should be extended to
require disclosure of all APIs used by, or provided by any Microsoft
middle-ware product, including APIs in other middle-ware software.
1.3 Changes to current and past middle-ware needs to be covered
The definition in VI.J excludes software in minor version changes from the
definition of Microsoft middle-ware. Yet it was exactly such a minor change
that disabled Java for millions of Internet Explorer users, or forced
thousands of ISVs to abandon the Web Plug-in API and redevelop or abandon
their middle-ware. (See http://www.meer.net/jg/broken-plugins.html)
At a minimum all software middle-ware released by Microsoft and in use by a
majority of Windows users should be covered by the Final Judgment for it to
be effective.
2. Shortcomings in the OEM configuration provisions
It is clear from the findings of the Court that there needs to exist
remedies that enable OEMs and End Users to be able to add, remove and
replace middle-ware without limitation by Microsoft through its Windows
product. It has been shown to the Court that its technically easy to allow
middle-ware either from Microsoft or its competitors to be added and
removed from the Windows operating system. The current language in the
Final Judgment does not protect distribution of new and innovative forms of
middle-ware and therefore fails to remedy the current situation where
investment and competition in Windows middle-ware is "chilled" by
Microsoft's prior and current practices.
III.H.3 allows Microsoft to undo an OEM configuration in any subsequent
version of a Windows product and to change the way an OEM's configuration
interacts with Windows in each subsequent version. This lack of "backwards
compatibility" is in Microsoft's interest at the expense of the OEM's
investment.
III.H.3. Allows Windows OS to undo an OEM's configuration automatically
after 14 days. But it does not give the same capability to an ISV, or the
OEM themselves. If a third party provides competitive differentiation by
adding features and services on top of Windows they should be able to do so
with no hindrance from Microsoft at all. If it is determined that Windows
should have a "revert" feature that disables or undoes an OEM's
enhancements, then that feature should have an "undo" capability so that
the enhanced product purchased from the third party is not irreparably
harmed by the behavior of the Windows software at some later time.
III.H attempts to give end users and OEMs the right to add and replace non
Microsoft middle-ware with competitive middle-ware, an essential component
of the proposed remedies. Rather than just stating this as a simple
requirement, additional restrictions are imposed in III.H.2:
- that competing middle-ware be replacing a Microsoft middle-ware
- that the middle-ware be a specific subset of possible middle-ware that
has a particular and limited type of user interface
- that Microsoft can require (and itself present?) a confirmation dialog
for the end user if the change is made by software that the user
presumably installed themselves
III.H.3 imposes conditions on Microsoft operating system products altering
OEM configurations, but Microsoft middle-ware also has a documented history
of making such alterations. The Final Judgment does not protect OEM
investments or end user choices unless it enjoins all Microsoft software
products from altering, without express permission, the end user
experience. It is exactly Microsoft's ability to make unilateral changes
that expresses its monopoly power and distorts the market for improvements
to Windows.
The mechanism proposed in III.H.1 allows Microsoft to provide a interface
choice to enable "all Microsoft Middle-ware Products as a group". This
should be specifically disallowed since it reinforces the distinction
between Microsoft and non Microsoft software, and suggests that an end user
would be given the default choice of "taking everything" (i.e. all
available Microsoft middle-ware, turning off competitors middle-ware) in
order to allow ease of use and configuration.
III.C.3 The requirement that a non-Microsoft middle-ware product should
display a user interface "of similar size and shape" to a Microsoft
middle-ware product is technically onerous. The additional inferred
requirement that a middle-ware product can only launch automatically if a
Microsoft middle-ware product were otherwise to do so, is also technically
unreasonable. If the purpose of this remedy is to allow competition in such
middle-ware; to allow, for example, an OEM to configure a PC so that it
connected automatically to an IAP or ICP on boot up, then these
restrictions would preclude this.
3. Loopholes and technical shortcomings with the wording of the judgment
There are significant exceptions and conditions attached to the definitions
used by the Final Judgment. These exceptions appear to make the remedies
themselves weaker and in several cases are technically inaccurate or
groundless.
3.1 Excluding existing middle-ware
Section III.H after III.H.3 describes two exceptions where Microsoft
middle-ware would be allowed to execute in preference to competing
Middle-ware. These exceptions effectively negate the value of III.H and are
seriously flawed.
3.1.1 The first exception is for middle-ware "invoked solely for use in
inter-operating with a server maintained by Microsoft". Given the current
and past scope of MSN and the services provided by various servers in the
"microsoft.com" domain, this exception is unreasonable. For example, a
component of Windows that contacted a server to upgrade or maintain the
device driver software on a Personal Computer would be exempt from III.H.
This would presumably preclude an OEM from providing their own value-add
service using the same component APIs of Windows. As the value and
prevalence of network services grows, Microsoft would be able to continue
to exclude competing middle-ware as long as they could define the service
as being hosted at Microsoft. This would also include most .NET services,
which Microsoft has publicly stated will be at the core of most end user
functions in all future versions of Windows. The proposed remedy for past
behavior is ineffective.
3.1.2 The second exception is if "non-Microsoft middle-ware fails to
implement reasonable technical requirements...". This is an unreasonable
and overly broad restriction on the proposed remedy. The specific example
given, failure of support ActiveX, is a most egregious example. ActiveX is
not a feature of Windows, it is an API created for Internet Explorer
middle-ware expressly to tie that middle-ware to the Windows platform. In a
healthy competitive environment it should be end users that conclude if
middle-ware is providing "functionality consistent with the Windows
product", not Microsoft. The idea that Microsoft themselves are qualified
to say what is and what is not a valid non-Microsoft middle-ware product
puts the fox in charge of the henhouse. In fact by the definitions of this
section of the Final Judgment, most existing successful non-Microsoft
middle-ware (Java, Netscape Navigator, Web Plug-ins) would be exempt from
the remedy. It was precisely the success of these products, demanded by end
users, that precipitated the threat to Microsoft and led to the illegal
behavior.
3.2 Limitations on disclosure of communications protocols
Section III.E. Requires disclosure of any communications protocol
implemented in a Windows OS installed on a "client" computer. This would
appear to exclude protocols implemented as Microsoft middle-ware, such as
Web Browsers, or communications middle-ware such as e-mail programs
(Outlook Express) or streaming media players (Windows Media Player). It
would also appear to exclude protocols implemented in the same copy of
Windows, running as a "server". Given the advent of "peer-to-peer"
computing this distinction excludes more significant protocols than it
includes. To meet the intent described in the impact statement, the
requirement should be the disclosure of any communications protocol
implemented by the Windows Operating System Product and any Microsoft
middle-ware product.
3.3 Preventing disclosure on "security" grounds.
Section III.J.1.a attempts to limit the APIs and protocol descriptions to
be published as part of the proposed remedy. The exceptions include those
that would "compromise the security..." of the Microsoft products. It is
well known and supported by the majority of reputable computer security
experts, including many who work for Microsoft Corporation, that disclosure
of the mechanisms of software makes it more secure, not less secure. In
fact requiring Microsoft to document and disclose APIs will make the
products more secure as flaws are discovered by peer review and then
repaired. Computer security should not be considered valid technical
grounds to limit disclosure.
3.4 Limitations on who can access the disclosures
Section III.J.2 places all kinds of limitations on the disclosure of the
information central to the proposed remedy. In III.D the Final Judgment
requires Microsoft to disclose APIs to all listed parties via "MSDN or
similar" i.e. publicly and for a small fee. This conflicts with III.J.2
which allows Microsoft to withhold such information unless Microsoft itself
determines "a reasonable business need", or that the requester meets
"standards established by Microsoft for ... viability". These restrictions
are unnecessary and are not vital to the remedy. The required information
should be disclosed simply, via MSDN or Microsoft.com, to anyone who has a
valid Windows license.
Section III.J.2 additionally requires that non-Microsoft middle-ware
innovators be in "compliance with Microsoft specifications" and, at their
own expense, pass a Microsoft defined third party verification test. These
new tests and requirements are onerous, and do not exist in the market
today except as optional marketing programs. In particular the
non-Microsoft middle-ware at issue in the anti-trust action would not have
met these standards. These additional requirements and limitations will
serve to place further hurdles in front of middle-ware ISVs. They only
serve the interests of the monopolist in limiting access to the required
APIs as has happened in the past as documented in the Findings of Fact.
4. Restrictive language related to Intellectual Property.
The licensing terms implied by the Final Judgment are both more onerous
than the prevailing market today, and unfairly biased in favor of
Microsoft.
The terms of III.G are not in force if Microsoft licenses intellectual
property from the third party. This would appear to allow, for example,
Microsoft to enter into an exclusive distribution arrangement with an ICP
if the ICP had a reciprocal license to Microsoft for some middle-ware
enhancement related to their Internet content. This kind of transaction is
common in the industry today and would seem to weaken the intent of III.G
Section III.I.5 grants Microsoft the right to require a competitor to
license to it IP rights to "relating to the exercise of their options or
alternatives provided by this Final Judgment". This is an onerous and
unreasonable requirement because Microsoft does not need such non
reciprocal IP rights to comply with the Final Judgment. (Could such rights
be licensed father by Microsoft to other ISVs?)
III.I requires Microsoft to reasonable and non discriminatory licensing of
any intellectual property required for the market to take advantage of the
provisions of the Final Judgment. However there is a restriction (H.III.3)
on sub-licensing. This would in practice curtail most ISV business models
if a technology innovator was unable to resell its technology to an "end
user" OEM or ISV without that entity then being required to obtain a
license from Microsoft.
The last paragraph of III.I explicitly states that the terms of the Final
Judgment will not confer any rights with regard to Microsoft IP on anyone.
But as the Final Judgment requires disclosure by Microsoft of APIs,
protocols and detailed documentation of mechanisms inherent in middle-ware
interfaces, then certain legal rights are in fact surrendered in most
jurisdictions.
III.I does not address the significant and influential market in royalty
free software (such as Linux) and the open standard nature of the Web
protocols and standards. Industry standards groups which Microsoft itself
is an active member of such as W3C (The World Wide Web Consortium)
customarily require all APIs and protocols to be royalty free. Yet III.I
potentially places further restrictions or costs on ISVs developing
products and innovations under that model if they wish to integrate them
with Windows.
5. Problems with the term and proposed implementation
5.1 Term is not long enough
The Final Judgment has a term of five years (V.A), or seven years with
additional violations. Given the pattern of illegal behavior by Microsoft
since 1995 and the fact that Windows Operating system product cycles are
frequently many years apart, the scope of this agreement appears unusually
short. A 10 or 15 year agreement would be more appropriate.
5.2 Issues with creating a competent technical body
The Final Judgment requires a three person technical committee. While this
committee is intended to be knowledgeable about software design and
programming, it also needs to be knowledgeable about Internet standards and
protocols, online transactions and web e-commerce architectures and
business models. It is unlikely that a committee as small as three people
will have the requisite skill set to oversee the broad range of initiatives
and innovations that center on the Windows platform and are the subject of
the monopoly concern. The committee would be more in keeping with industry
standards and accepted practice if it were larger and comprised of experts
in several fields.
5.3 Public disclosure of information relating to enforcement
Section IV.B.10 and other language in IV (e.g IV.D.4.d) suggests that the
Final Judgment requires the work of compliance and technical overview to be
conducted in secret. For example if an ISV submitted a complaint to the TC
or the Microsoft Compliance Officer it is not required that the complaint
and its response be published (IV.D.3) It would be more in keeping with
industry standards and accepted practice for technical discussion around
the enforcement of a Final Judgment be open to wider technical review. This
would improve the quality and accuracy of such review as well as reassuring
the community of OEMs, ISVs etc. that the enforcement process was actually
working. At a minimum there should be a requirement that the TC host an
independent web-site to communicate with the industry about the status of
enforcement issues.
6. Flaws in several of the definitions
There are many problems with the definitions of key terms that affect the
meaning and substance of the Final Judgment.
VI.A. A suitable definition for Application Programming Interface needs to
include interfaces provided by middle-ware itself, since middle-ware can
include tiers of software, not just a simple arrangement where middle-ware
calls the Windows software layers. A more accurate and common definition of
APIs would be independent of both the terms Windows and middle-ware.
VI.B. The scope of Communications Protocol should not be limited to
communications with a "server operating system". This excludes the concept
of one Windows XP PC talking to another PC, which is a common occurrence
and should be within the scope of the remedy. "Peer-to-peer" is an example
of a middle-ware category that is not covered by this definition.
VI.J.2 and VI.K.b.iii both require that the covered software be
"Trademarked" to be under the terms of this agreement. This requirement
seems to exclude certain middle-ware. For example "My Photos" and "Remote
Desktop" are new middle-ware in WindowsXP and are apparently not
trademarked. VI.T defines Trademarked to exclude certain named products
regardless of their impact in the market.
VI.J.4 excludes software that has no user interface, such as a streaming
video codec or a web commerce protocol handler.
VI.K.1 lists certain products explicitly as middle-ware. Given that the
Final Judgment as written only covers Windows XP and subsequent versions
(it should be modified to cover prior versions), the list of covered
products and categories should also include MSN Explorer, Microsoft Outlook
and other Microsoft Office components, Windows Movie Maker and others.
VI.N limits the definition of a "non-Microsoft middle-ware product" to one
that has shipped 1,000,000 copies in a previous year. Under this
definition, Netscape Communicator would not be covered by this Final
Judgment, nor would Sun's Java JVM, both examples cited by the Court of
middle-ware that require relief. The idea that a competing product has to
already be successful to receive the protection of the Final Judgment is
flawed. This condition should be removed.
VI.N defines non-Microsoft middle-ware in terms of code exposing APIs,
which are defined in VI.A as being uses by Microsoft middle-ware (this is a
circular definition). More importantly, non Microsoft middle-ware should
not be defined more narrowly than Microsoft middle-ware. Not all
middle-ware "exposes a range of functionality to ISVs though published
APIs" although some (like Java) does. The original Netscape 1.0 web browser
would have failed the definition in VI.N
VI.Q defines Personal Computer as using an Intel x86 processor. Microsoft
has in the past and will most likely in the future ship Windows Operating
systems for processors other than x86. The Court found that Microsoft's
illegal practices in respect of distribution of Internet Explorer also
extended to the Macintosh Power-PC platform so this definition is overly
narrow.
VI.R. 150,000 beta testers is an unusually large number, even for Windows
and suggests that "timely manner" would be defined as the last test release
of a Microsoft product rather than the first public test release. The
interests of the enforcement are better served if Timely Manner was defined
as the first public test release of a Windows OS product.
[end]
|