fsfe-website/activities/ms-vs-eu/fsfe-statement.html
nicoulas fc5838b0f2 - we now use only one step of XSL transformation
svn path=/trunk/; revision=25171
2013-01-17 23:13:14 +00:00

1373 lines
67 KiB
HTML

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>FSF Europe - Comments to Case No. COMP/C-3/37.792 Microsoft</title>
</head>
<body>
<!-- Begin page content -->
<h1>Comments to Case No. COMP/C-3/37.792 of the European Commission against Microsoft Corporation</h1>
<p><a href="http://fsfeurope.org">Free Software Foundation Europe e.V.</a></p>
<p align="center">Essen, 21 January 2002</p>
<h2>Contents</h2>
<ul>
<li><a href="#Introduction">1. Introduction</a></li>
<li><a href="#Markets">2. The Relevant Markets</a></li>
<li><a href="#Interoperability">3. Interoperability</a></li>
<li><a href="#Licensing">4. Discriminatory Licensing</a></li>
<li><a href="#Bundling">5. Bundling of the Windows Media Player</a></li>
<li><a href="#Remedies">6. Remedies</a></li>
<li><a href="#Glossary">A. Glossary</a></li>
<li><a href="#Halloween">B. The Halloween Documents</a></li>
<li><a href="#Samba">C. Samba</a></li>
<li><a href="#Death">D. The Death of TCP/IP<br/>
Why the Age of Internet Innocence is Over</a></li>
<li><a href="#Settlement">E. Statement by the FSF about the Settlement
in the USA</a></li>
</ul>
<h2><a name="Introduction">1 Introduction</a></h2>
<h3>1.1 About the Free Software Foundation Europe</h3>
<p>1. The Free Software Foundation Europe e.V. (&quot;FSF
Europe&quot;) is a charitable association (e.V. in Germany) dedicated
to promoting computer users' right to use, study, copy, modify, and
redistribute computer programs in Europe. The FSF Europe promotes the
development and use of free (as in freedom) software - particularly
the GNU operating system - and free (as in freedom)
documentation. The FSF Europe also helps to spread awareness of the
ethical and political issues of freedom in the use of software.</p>
<p>2. The FSF Europe is an acknowledged sister organisation of the
Free Software Foundation (FSF) in Boston, USA, dedicated to the same
goals.</p>
<p>3. The FSF (including the FSF Europe) has always observed and
commented on attempts to lock up the software market and exclude new
entrants. This includes many actions by Microsoft Corporation
(&quot;Microsoft&quot;) that are against free competition, sometimes
directly against the Free Software Movement, but not limited to
that. The FSF Europe's expertise includes analysing the economic and
technological effects of such actions on the software market from an
insider's point of view.</p>
<p>4. When the FSF Europe became aware of Case No. COMP/C-3/37.792 of
the European Commission against Microsoft, it applied for status as
an interested third party. This status was granted on 12 December
2001. On 27 December 2001, the FSF Europe received the
non-confidential versions of the Commission's Statements of
Objections and Microsoft answers. In the present paper, we are
commenting on Microsoft's response (of 16 November 2001) of the
second Statement of Objections (of 29 August 2001).</p>
<h3>1.2 Microsoft and Free Software</h3>
<p>5. Free software, and in particular the GNU/Linux operating system
(the GNU system with the Linux kernel added), now holds a substantial
and increasing share of the operating system market. Microsoft cited
this system as its principal competitor and is using various methods
to attack the Free Software Movement. These attacks are usually
performed using monopolistic practices similar to those used in the
conventional software market. We believe that some of Microsoft's
methods of attack are abusive and should be brought to an end..</p>
<h2><a name="Markets">2 The Relevant Markets</a></h2>
<p>6. In &para;&para; 139-143 of its Response to the Second Statement
of Objections, Microsoft argues against the European Commission's
definition of the relevant markets..</p>
<p>7. In contrast, the FSF Europe agrees with the analysis of the
relevant product markets by the European Commission as stated in the
Second Statement of Objections, &para;&para; 94-119..</p>
<p>8. We think that Europe needs to insist that Microsoft allow
compatible competition for all aspects of their newly introduced
software products <em>world-wide</em>, not just in Europe, in order
to get permission to sell them in Europe..</p>
<p>9. The reason is that the software market is world-wide: If
Microsoft is the only alternative that people in the USA (say) are
allowed to use, that can make other alternatives commercially
unviable everywhere..</p>
<h2><a name="Interoperability">3 Interoperability</a></h2>
<p>10. One of the main objections of the EU Commission is Microsoft's
refusal to disclose information about the network protocols
(interfaces) necessary to achieve full inter-operability with (a)
Microsoft's Active Directory Services, (b) Microsoft's version of the
Kerberos protocol, (c) Microsoft's Encrypted File System, (d)
Microsoft's Group Policies, and (e) Microsoft's Common Internet File
System. (See the Second Statement of Objections, &para;&para;
37-61.).</p>
<h3>3.1 Microsoft's Strategy</h3>
<p>11. The Halloween Documents (see <a href="#Halloween">Appendix
B</a>) give evidence that Microsoft employees tend to suggest to
extend existing protocols and to develop new, complex protocols with
the intention to prevent competing free software from entering into
the market..</p>
<p>12. Analyses by the developers of the free software Samba and
Samba-TNG (see <a href="#Samba">Appendix C</a>) indicate that
Microsoft's protocols are designed in a highly interdependent way:
Each (proprietary) protocol depends on the correct implementation of
another (proprietary) protocol to work properly. Full functionality
and inter-operability can only be achieved when <em>all</em> protocols
are known..</p>
<p>13. There are exceptions where Microsoft did disclose some of its
protocols (see <a href="#SambaInterview">Appendix C.3</a>). Some of
these cases occurred where a lack of inter-operability would have
resulted in a loss for Microsoft. In some other cases, Microsoft
needed third-party help in order to fix a serious security hole in
one of its products..</p>
<p>14. If, in some rare cases, disclosure of information was offered
at all, it was offered under very restrictive licensing conditions
including non-disclosure agreements which made it impossible to use
that information in free software..</p>
<h3>3.2 Possible Results</h3>
<p>15. <a href="#Death">Appendix D</a> cites an article describing a
speculative, but possible scenario how Microsoft can extend its
current dominance from the desktop and workgroup server market to the
whole Internet - i.e. all server markets - using the same methods as
those described in the Second Statement of Objections, &para;&para;
37-61.</p>
<p>16. We believe the scenario in the article is a possible one.
Microsoft has already spoken of plans to attack GNU/Linux using
secret or patented protocols, and it has already implemented a secret
modified version of the Kerberos protocol.</p>
<p>17. Of course, the article is speculation. Microsoft may not use
this particular scheme. It may have been planning to do this but be
deterred by the publication of this article. In any case, there are
many other possible variations that could lead to similar
results.</p>
<p>18. The European Union is in position to prevent this scheme, and
other such schemes, through its regulatory mechanisms, if it requires
that any new Microsoft protocol be published in such a way that
everyone can implement it without restriction.</p>
<p>19. Microsoft will no doubt propose to license use of the new
protocol under some &quot;nondiscriminatory license terms&quot;.
Such a proposal would be a trap, since these
&quot;nondiscriminatory&quot; license terms can easily be set up to
prohibit free software. They would be &quot;nondiscriminatory&quot;
in the sense that they would offer the same license terms to
everyone, but these terms would not allow anyone to develop free
software.</p>
<h3>3.3 Interoperability between Existing Software Products</h3>
<p>20. In &para;&para; 10-18, 39, 51-53, 62-70, and 94-97 of its
Response to the Second Statement of Objections, Microsoft states that
third-parties did succeed in achieving inter-operability with
Microsoft's server products, that the work needed to achieve this
degree of inter-operability was inevitable.</p>
<p>21. As the developers of Samba can confirm (see <a
href="#Samba">Appendix Samba</a>), the documentation provided by
Microsoft was by no means sufficient to achieve this degree of
inter-operability. Most of the information was obtained by
reverse-engineering. As a rough estimate, about 100 man-years of work
could have been saved if the protocols had been sufficiently
documented.</p>
<p>22. Furthermore, as even Microsoft admits in &para;&para; 10-17 of
its Response to the Second Statement of Objections, existing products
of competitors (including Samba) do not inter-operate seamlessly with
Microsoft's server products.</p>
<h3>3.4 Degrees of Interoperability</h3>
<p>23. According to Microsoft, this reduced (&quot;loose&quot;)
degree of inter-operability is inevitable between the products of
different vendors due to differences in design.</p>
<p>24. There is a prominent example which demonstrates that full
(&quot;tight&quot;) inter-operability is possible even between totally
different systems of independent vendors: the Internet. The existence
of the open RfC standards allows, for instance, email clients and
servers of different vendors to inter-operate seamlessly. The same
holds for the World Wide Web and a large variety of IP-based
services.</p>
<h3>3.5 Third-Parties' Goals</h3>
<p>25. In &para;&para; 16-19 of its Response to the Second Statement
of Objections, Microsoft states that the complainants' true interest
was to profit from Microsoft's innovations.</p>
<p>26. As programmers who know both Microsoft and its alternatives
will confirm, Microsoft's software is not particularly technically
advanced. Other people can write software that is just as good, and
already do. The only benefit the complainants would get from knowing
Microsoft's interface specifications is inter-operability.</p>
<p>27. Once in a while, Microsoft innovates. But Microsoft benefits
from the innovations of its competitors, including the Free Software
Movement, all the time. It is only fair that we should be able to use
their occasional innovations too. That's called
&quot;progress&quot;.</p>
<h2><a name="Licensing">4 Discriminatory Licensing</a></h2>
<p>28. In &para;&para; 82-89 of the Second Statement of Objections,
the EU Commission describes Microsoft's licensing policy which builds
momentum for customers to move to Microsoft Windows servers.
Microsoft's bundling of its Client Access Licences with several
server products is an abuse, as it restricts the users' freedom to
run their software (Microsoft Windows 2000 Professional in this case)
as they deem fit (as a platform for third-party server software in
this case).</p>
<h2><a name="Bundling">5 Bundling of the Windows Media Player</a></h2>
<p>29. In &para;&para; 26 and 125-131, Microsoft claims that bundling
of the Windows Media Player with the operating system is justified
because multimedia software is a logical feature of an operating
system.</p>
<p>30. If this were the case, the software would have appeared as a
new part - an &quot;improvement&quot; - of the operating system from
the very beginning. However, Microsoft's bundling started
<em>after</em> Microsoft became aware of the fact that a competitor
was selling the software in question as a separate product.</p>
<p>31. We observe that Microsoft has redefined the &quot;logical
features&quot; of an operating system several times: In the 1980s,
most companies considered, for instance, development and remote
administration tools logical features of an operating system.
Microsoft decided to un-bundle these components and to distribute
them as separate products. This was only possible in a narrowed
market where no competing operating system already contained these
important components.</p>
<h2><a name="Remedies">6 Remedies</a></h2>
<h3>6.1 Microsoft's Settlement in the USA</h3>
<p>32. In &para; 150 of its Response to the Second Statement of
Objections, Microsoft states that according to their Settlement with
the Department of Justice in the USA, Microsoft is obligated to
license the client/server protocols to third parties, on reasonable
and non-discriminatory terms.</p>
<p>33. According to an analysis by the FSF, our sister organisation
in the USA, Microsoft's &quot;reasonable and non-discriminatory
terms&quot; are in fact discriminatory against free software, as they
require a licensing scheme which is incompatible with that of free
software (see <a href="#Settlement">Appendix E</a>). Thus,
Microsoft's settlement in the USA still excludes free software from
access to the interfaces needed to achieve inter-operability.</p>
<h3>6.2 Interoperability</h3>
<p>34. In order to bring the infringements to an end, Microsoft
should be required to publish their current and future interface
specifications, without any restrictions or royalty requirements that
would make it impossible for free software to support them.</p>
<h1>Appendix</h1>
<h2><a name="Glossary">Glossary</a></h2>
<dl>
<dt>Free software</dt>
<dd> is software which gives the users the freedom to run, copy,
distribute, study, change, and improve the software. More
precisely, it refers to four kinds of freedom, for the users
of the software:
<ul>
<li>The freedom to run the program, for any purpose (freedom 0).</li>
<li>The freedom to study how the program works, and adapt it to
your needs (freedom 1). Access to the source code is a
precondition for this.</li>
<li> The freedom to redistribute copies so you can help your
neighbour (freedom 2).</li>
<li>The freedom to improve the program, and release your
improvements to the public, so that the whole community benefits
(freedom 3). Access to the source code is a precondition for
this.</li>
</ul>
(See also:<a href="http://www.gnu.org/philosophy/free-sw.html">http://www.gnu.org/philosophy/free-sw.html</a>)</dd>
<dt>FUD</dt>
<dd>is the abbreviation for &quot;fear, uncertainty, and doubt&quot;
and describes a specific abusive marketing strategy used by
monopolists against smaller competitors.<br /> (See also: <a
href="http://www.geocities.com/SiliconValley/Hills/9267/fuddef.html">http://www.geocities.com/SiliconValley/Hills/9267/fuddef.html</a>,
<a
href="http://www.tuxedo.org/~esr/jargon/html/entry/FUD.html">http://www.tuxedo.org/~esr/jargon/html/entry/FUD.html</a>)</dd>
<dt>GNU</dt>
<dd> is a Unix-like operating system which consists
entirely of free software.<br />
(See also: <a href="http://www.gnu.org">http://www.gnu.org</a>)</dd>
<dt>GNU/Linux</dt>
<dd>is a variant of the GNU operating system which uses Linux as its
kernel.<br />
(The GNU/Linux operating system is often misleadingly referred
to as &quot;Linux&quot;.)</dd>
<dt>Linux</dt>
<dd>is a kernel, the innermost part of a Unix-like operating system.
Linux was started in 1991 by Linus Torvalds and is the first
operating system kernel which can be redistributed and/or
modified under the terms of the GNU General Public License (GNU
GPL).</dd>
<dt>RfC</dt>
<dd> -- &quot;Request For Comment&quot; -- one of a long-established
series of numbered Internet informational documents and standards
widely followed by commercial and non-commercial, free and
non-free software. For instance, RfC-800 is the specification of
the Internet mail-format standard. The RfC documents are released
by technical experts acting on their own initiative and reviewed
by the Internet at large, rather than formally promulgated
through an institution such as ANSI. It is widely believed among
experts that the acceptance of the RfC standards makes today's
Internet possible.<br />
(See also: <a href="http://www.tuxedo.org/~esr/jargon/html/entry/RFC.html">http://www.tuxedo.org/~esr/jargon/html/entry/RFC.html</a>)</dd>
</dl>
<h2><a name="Halloween">B The Halloween Documents</a></h2>
<h3>B.1 Halloween I</h3>
<p>By Vinod Valloppillil, 11 August 1998,<br /> annotated version by
Eric S. Raymond, 1 November 1998.</p>
<p>This is mirrored from:<br />
<a href="http://www.opensource.org/halloween/halloween1.html">http://www.opensource.org/halloween/halloween1.html</a></p>
<p>This document by a Microsoft employee gives an analysis how free
software (called &quot;open-source software&quot; or
&quot;OSS&quot; by the author) poses a threat to Microsoft. In
particular it contains the suggestion to compete with free software
by destroying inter-operability:</p>
<blockquote>
&quot;By extending [...] protocols and developing new protocols,
we can deny OSS projects entry into the market.&quot;
</blockquote>
<p>One instance of the method suggested here is Microsoft's refusal
to disclose the information necessary to achieve client/server and
server/server inter-operability as described in the Second Statement
of Objections, &para;&para; 37-61.</p>
<p><a href="halloween1.html">Click here for a local copy of the
Halloween I document.</a></p>
<h3>B.2 Halloween II</h3>
<p>By Vinod Valloppillil and Josh Cohen, 11 August 1998,<br />
annotated version by Eric S. Raymond, 4 November 1998.</p>
<p>This is mirrored from:<br />
<a href="http://www.opensource.org/halloween/halloween2.html">http://www.opensource.org/halloween/halloween2.html</a></p>
<p>This second document specialises from free software (called
&quot;open-source software&quot; by the author) to the GNU/Linux
operating system (called &quot;Linux&quot; by the author).</p>
<p>It adds software patents and copyright to the suggested weapons
to combat GNU/Linux.</p>
<p><a href="halloween2.html">Click here for a local copy of the
Halloween II document.</a></p>
<h3>B.3 Halloween III</h3>
<p>By Aurelia van den Berg, 5 November 1998,<br />
annotated version by Eric S. Raymond, 5 November 1998.</p>
<p>This is mirrored from:<br />
<a href="http://www.opensource.org/halloween/halloween3.html">http://www.opensource.org/halloween/halloween3.html</a></p>
<p>This third document is Microsoft's answer to the publication of
the Halloween documents I and II. It says that both documents do
not describe Microsoft's official position on GNU/Linux and free
software but are designed to encourage discussion inside Microsoft.</p>
<p>If this is really the case, it shows that it is common among
Microsoft's employees to discuss the possible application of
abusive methods of competition.</p>
<p><a href="halloween3.html">Click here for a local copy of the
Halloween III document.</a></p>
<h2><a name="Samba">C Samba</a></h2>
<p>The statements below have been contributed by the developers
of the server software products Samba (see
<a href="http://www.samba.org">http://www.samba.org</a>)
and Samba-TNG (see
<a href="http://www.samba-tng.org">http://www.samba-tng.org</a>).</p>
<h3>C.1 A Samba Perspective on Interoperating with Microsoft Windows</h3>
<p>By Jeremy Allison, Samba development team, 6 January 2002.</p>
<h4>Background</h4>
<p>Samba is an Open Source/Free Software (for details, see:
<a href="http://www.opensource.org">http://www.opensource.org</a>
and <a href="http://www.fsf.org">http://www.fsf.org</a>) project
that provides basic file and print services from non-Microsoft
based server computers to Microsoft Windows based desktop
computers. It is created by a worldwide group of engineers known
collectively as the Samba Team. Recently we have expanded Samba
into providing authentication services to Windows desktops. The
Samba project Web home page is at
<a href="http://www.samba.org">http://www.samba.org</a>.</p>
<p>Samba is a successful Open Source/Free Software project, shipped
in products by companies such as IBM, HP, Sun, SGI, Veritas and
many other smaller vendors. Samba is probably the most widely used
non-Microsoft file and print server for Windows clients.</p>
<p>Samba code has been communicating with Microsoft Windows operating
system based computers over computer networks for nearly ten years
now. During this time we have had some interactions with Microsoft
management and engineers to attempt to obtain the information we
need to successfully create an inter-operable product with Microsoft
Windows operating systems.</p>
<h4>Interoperating with Windows</h4>
<p>Writing software code to inter-operate successfully with Windows
computers is a very difficult task. Note this is very different from
writing software code that runs on Windows computers. In public
relations exercises Microsoft likes to claim that all the API's
(Application Programming Interfaces, the way third party software
code running on a platform talks to the platform, such as Windows)
are documented and available to the public. This may or may not be
true. However, it is irrelevant to code like Samba that does not run
on Microsoft Windows based systems, but needs to communicate with
them over a computer network.</p>
<p>In order for Samba to be successful in working with Microsoft
Windows computers over a network, we do not need documented API's, we
need documented protocols. Protocols are the key to successful
computer networking. Just as a common Internet was not possible
before an open and fully documented communication system (the TCP/IP
protocol) was adopted by all computers, communication with Microsoft
Windows computers is only possible if open and documented protocols
are used. Microsoft understands this, and proudly claims that
Windows supports many open and published protocol communication
standards, such as TCP/IP and HTTP (the protocol used on the Web). In
recent Microsoft Windows releases such as Windows 2000 and Windows XP
they have claimed they are replacing older proprietary protocols such
as their authentication system with more open versions of the same
thing such as the MIT Kerberos (<a
href="http://web.mit.edu/kerberos/www/">http://web.mit.edu/kerberos/www/</a>)
protocol, implementations of which are also developed in Europe as
the Heimdal project (<a
href="http://www.pdc.kth.se/heimdal/">http://www.pdc.kth.se/heimdal/</a>).</p>
<p>These claims do not tell the full story however.</p>
<h4>Microsoft's Web of Interconnected Protocols</h4>
<p>In order to communicate on a network with Microsoft Windows
computers, Microsoft Windows mix open and proprietary protocols
together in an interdependent web which makes it impossible to use
purely the open and documented protocols to create products that have
the same features and functionality as the Microsoft ones, giving a
competitive advantage to Microsoft products and allowing them to
attempt to leverage their desktop monopoly into a server
monopoly.</p>
<p>A good analogy would be with the old USA telephone system, a
monopoly run by the Bell company. Imagine the Bell company had
documented the method of sending voice signals over their telephone
lines, but not the dialing and switching protocols used to initiate
and route telephone calls. Groups attempting to make inter-operable
telephones would then either be forced to spend significant time and
effort reverse engineering these Bell proprietary protocols, or to
license them from the Bell company. Like Microsoft, Bell would claim
that &quot;their networking protocols are open&quot;, which on the
surface appears true.</p>
<p>The Samba Team have worked out many of these protocols in order to
create Samba, but there are still many more protocols needed in order
to enable Samba and other products to seamlessly work with Microsoft
Windows computers. Until these protocols are published, it will
always be easier to use Microsoft Windows desktops solely with
Microsoft Windows servers, thus enabling Microsoft to leverage its
monopoly from the desktop client space into the server space.</p>
<p>In addition, Microsoft does not stand still in extending and
adding to these proprietary protocols in order to make the
inter-operability task more difficult as time goes on.</p>
<h4>File and Print services background</h4>
<p>Microsoft file and print services were created for a product
called Microsoft LanManager, which competed with the then-dominant
Novell Netware networking product. Microsoft's initial efforts in
this space were not well received, and Microsoft published a
specification for their basic file and print protocols as an X/Open
specification, <a
href="http://www.opengroup.org/products/publications/catalog/c209.htm">http://www.opengroup.org/products/publications/catalog/c209.htm</a>.</p>
<p>This was the initial specification that Samba was based upon.
However, even this documentation was incomplete (no coverage of
authentication) and did not cover the &quot;browsing&quot;
protocols needed to create the Microsoft &quot;Network
Neighborhood&quot; concept. Also, there was no coverage of the (at
that time) Microsoft OS/2 extensions to provide support for
filenames longer than the 12 character limitation in MS-DOS (the
familiar 8.3 names), or coverage of the printing mechanisms used
(an obsolete variant was documented instead).</p>
<p>This protocol, called SMB (for Server Message Block) is the
basis for all Microsoft file and print services. However, this
original document was enough to get programmers started on writing
a Microsoft file and print server although it did not cover many of
the necessary details. The protocol has since been renamed as CIFS
(Common Internet File System) by Microsoft, the rest of this
document will refer to it by this name.</p>
<p>Since then, this document has been taken over by the CIFS working
group of the Storage Networking Industry Association (SNIA, <a
href="http://www.snia.org">http://www.snia.org</a>) and has been
extended to include many of the needed details to create a working
Microsoft compatible basic file and print server. Microsoft's
participation in this (although a SNIA member) has not been one as an
equal, but rather as the &quot;owner&quot; of the specification. Most
importantly, they reserve the right to make changes at any time and
without notice, as indeed they have done in the past. This makes the
CIFS protocol specification very different and far less useful than
the protocols standardised by the Internet Engineering Task Force
(IETF, <a href="http://www.ietf.org">http://www.ietf.org</a> which
are true industry collaborations.</p>
<p>The big change in proprietary protocols came with the release of
Microsoft Windows NT. Windows NT added much new functionality on
top of the basic file and print mechanisms, such as:</p>
<ul>
<li>A new encrypted authentication mechanism.</li>
<li>A new print mechanism.</li>
<li>A new naming mechanism (WINS).</li>
<li>A new Access control mechanism for files and printers.</li>
</ul>
<p> Many new remote administration protocols for controlling services,
logins, current file and print activity - anything remotely
controllable on a Windows NT machine was made available via these
proprietary protocols.</p>
<p>Leveraging the work of open protocols, the underlying basis of
all these new proprietary protocols was an open and documented
protocol known as DCE/RPC (Distributed Computing Architecture /
Remote Procedure Call). Microsoft added proprietary extensions to
this for their Lanman authentication mechanism, and to provide
encrypted transport mechanisms. Note that the DCE/RPC protocols
already had methods to provide authentication and encryption, based
on public standards (the DES encryption algorithm). Microsoft chose
to ignore this work and use a proprietary method instead, thus
making inter-operability much more difficult without large amounts
of protocol examination and on-the-wire determination.</p>
<p>With the release of Windows NT, the bar was raised to create a
product that has the same functionality as an equivalent
all-Microsoft solution. New requirements were to discover these new
protocols to provide such things as single sign-on, probably the
most compelling feature - the ability to enter a password once to
authenticate yourself anywhere on the network. Microsoft clients
require servers supporting these new protocols in order to offer
the features they are advertised as providing.</p>
<p>For many years, until the engineering work was done to discover
these protocols, the only servers capable of providing these
protocols were Microsoft ones. Samba has now improved (by much
work) to the point where we can support some of these features (the
new print mechanism, the encrypted authentication mechanism, the
naming mechanism, the access control mechanism) but not all of them
(many of the critical remote administration features are still
missing).</p>
<p>Of course, over these years Microsoft has not stood still in
adding new features to Windows NT/2000/XP, and we now have to deal
with extensions to provide encrypted file system access, quota
support (limits on users disk space) and the authentication
mechanism has been replaced with the more open Kerberos system, but
with Microsoft proprietary extensions.</p>
<h4>Connected Protocols and the importance of Interface Definitions</h4>
<p>Knowing that all these new protocols are based on a standard,
DCE/RPC doesn't help at all unless you know how the new feature
requests (the &quot;calls&quot; in RPC parlance) are sent over the
standard. DCE/RPC is merely a transport mechanism for sending
requests to a remote machine and receiving replies from the target.
In order to specify what these requests mean, DCE/RPC uses a method
called &quot;Interface Definition Language&quot; (known as IDL) to
specify the requests (themselves a new protocol) that are sent
between clients and servers.</p>
<p>Each service provided by Microsoft servers has an associated
description, in the IDL language, that completely describes how to
send and receive these requests over the network, on top of the
DCE/RPC protocol.</p>
<p>These IDL descriptions are <em>key</em> for providing
inter-operability with Microsoft clients. If these IDL descriptions
were published, open and equal inter-operability with Microsoft
products would be greatly enhanced (although still not perfect).</p>
<p>Knowing this, the Samba Team requested these IDL definitions from
Microsoft at the CIFS industry conference in Santa Cruz in October of
1998. The Microsoft representative present, Paul Leech, responded
that this was considered a Microsoft proprietary advantage, and the
IDL definitions would not be released.</p>
<p>Undeterred, we have requested the IDL definitions from the
Microsoft representative at every CIFS industry conference (held
annually) since 1998, most recently from the Microsoft VP of Windows
Base OS, Rob Short at the 2001 CIFS conference in Redmond,
Washington. The response we received was the same we have always
received, that is &quot;we'll get back to you on this&quot;. No
follow-ups have ever been received to these requests.</p>
<p>Other than these refusals, Microsoft has been ambivalent towards
the creation of Samba. Contact with Microsoft engineering staff is
generally cordial and helpful, although they are not allowed by
management to tell us the protocol details we really need to know in
order to fully inter-operate. The reports we receive from companies
using Samba who are exposed to Microsoft marketing is that of extreme
hostility, to the extent of threatening retaliation if use of Samba
is discussed publicly in press releases. These reports are similar to
those already exposed publicly in the DoJ investigation of
Microsoft's business practices.</p>
<h4>Extending authentication - the Kerberos story</h4>
<p>The original proprietary Lanman and Windows NT authentication
system has had several security problems. Microsoft solved this with
Windows 2000 as previously discussed by moving to the standard
Kerberos authentication system, developed at MIT.</p>
<p>However, the implementation of Kerberos delivered with Windows
2000 was extended to tie it to Windows 2000 clients, and to make
public implementations of the Kerberos protocols, such as the sample
server published as Open Source/Free Software by MIT, not able to
serve Microsoft Windows 2000 or Windows XP clients in the same way a
Microsoft Windows Kerberos server can.</p>
<p>What they did was to embed extra, Microsoft specific proprietary
information into the protocol packet used by Kerberos (known as a
&quot;ticket&quot;). Windows 2000 clients were made dependent upon
the existence of this extra data within the ticket in order to
implement &quot;single sign-on&quot;, that is the ability to have one
network user identification across multiple machines.</p>
<p>MIT Kerberos servers, which do not provide this information, can
provide authentication to Windows 2000 and XP client machines, but
the user authenticated by the non-Microsoft Kerberos server must also
exist within an account database held on a Microsoft machine. This
causes the user account information to be held in more than one
place, the very problem that single sign-on is designed to avoid.</p>
<p>Groups wishing to deploy the more secure authentication service
are forced to implement their account databases on Microsoft servers,
of face the consequences of not having single sign on available.</p>
<p>As Samba does not generate Kerberos tickets, but is a consumer of
them, this extension of the standard protocol doesn't cause us
problems integrating into a Microsoft network (we just ignore the
extra data), but it is aimed directly at the MIT and Heimdal
developers.</p>
<p>I (Jeremy Allison) publicly requested Microsoft to publish these
changes to the Kerberos protocol by speaking to Microsoft's Kerberos
project manager, Peter Brundrett at a Microsoft Professional
Developers Conference in 1997. Once again, the answer was &quot;we'll
get back to you on this&quot;. The changes were published in a
Microsoft Word document that had been modified to include a
click-through license which required the reader acknowledge that
these changes were a proprietary Microsoft trade secret and to agree
not to implement the changes in any code form. Clearly this is a
direct attempt to prevent the public MIT Kerberos/Heimdal developers
from creating a server fully compatible with Microsoft kerberos
single sign-on clients.</p>
<h4>Network Attached Storage - Microsoft's next market</h4>
<p>In order to create a successful Network Attached Storage server
product with Microsoft clients, many more protocols than Microsoft
documents or will discuss publicly are needed to create a competitive
offering. The only way to get this needed information is to license
it from Microsoft (Network Appliance <a
href="http://www.netapp.com">http://www.netapp.com</a> has taken this
route), ship only Microsoft software on your hardware, the decision
taken by Compaq and other vendors who ship Microsoft's &quot;Server
Appliance Kit&quot; (<a
href="http://www.microsoft.com/windows/powered/nas/default.asp">http://www.microsoft.com/windows/powered/nas/default.asp</a>)
or to attempt to determine the protocols needed yourself (the route
the Samba Team have taken). The vendors that ship Samba depend on us
discovering these protocols and shipping timely implementations of
Microsoft technology within Samba.</p>
<p>It remains to be seen if Microsoft's entry into this space with
their server appliance kit will give them the same dominance they
have achieved in the desktop and groupware server (Microsoft
Exchange) space. If they are allowed to continue to tie client and
server products together with proprietary undocumented protocols
then customers requiring the advertised functionality from
Microsoft clients will be forced to purchase Microsoft server
products, and monopoly will have been successfully extended into
another product space.</p>
<h3>C.2 Open Letter to Bill Gates</h3>
<p>By Luke Kenneth Casson Leighton, Samba-TNG development team, 20 October 2001.</p>
<p>This letter - also available online at <a
href="http://advogato.org/article/354.html">http://advogato.org/article/354.html</a>
- was written, in combination with other requests at other times, to
cover the &quot;all means available&quot; clause of EC directive
250/90. The author received no reply.</p>
<pre>
we're looking at your technology in Windows NT and, as you probably
know, i am so impressed by it that i would like to interoperate with
it. i was wondering, therefore, if you could send me all IDL
files and other technical information sufficient to implement
programs such as exchange server and the MAPI API, SQL, NT domains
version 4 and 5, Active Directory.
everything, really.
i have asked this question before, and i did get a response back
of &quot;no&quot;. however, that _was_ over a year ago, and i was wondering
if you'd changed your mind at all.
also, i do have to apologise in advance because, i have to make
this message publicly. the reason for that is that if you still
say no, then under European Law, Council Directive 91/250/EEC,
i would be allowed to do a considerable amount of work - far
more than is sensible - to perform &quot;interoperability&quot; analysis.
what would _you_ get out of this? well, ask the team at
secure&#64;microsoft.com. whilst i was working on samba, from
1996 to 1999, you received numerous really rather important
and obscure security reports. one of these resulted in the
deployment of the Netlogon &quot;Schannel&quot; (don't know its real name)
in NT Service Pack 4. this was a critical first step to ensuring
that the entire SAM database would not be decoded by a hostile
party who had access to BDC - PDC SAM Sync, for example!
so you would get a full, comprehensive analysis and independent
testing of all your core-level products. and that's utterly
priceless. and price-tag-free, too.
now, _why_ should you give us access to technical specifications?
well, reasons i can think of off the top of my head are:
- it would generate an incredibly large amount of good-will
- some of this technology is old enough (DCE/RPC) such that
it's been in use in Microsoft for so long that the people
who implemented it originally are retiring, and the &quot;new crowd&quot;
don't understand it, don't get it, and are implementing &quot;.net&quot;
instead.
therefore, it really shouldn't matter: it's nearing the
end of its life-cycle. SOAP is All The Rage. dot net is
All The Rage. passport dot com is All The Rage.
- you've _had_ ten years head-start on this, surely that's
more than enough to ensure market leadership, can we join in,
now? pleeease?
- releasing some of this info may help reduce market share to
below a level where the U.S. Dept of Justice will not bother you
again.
anyway, i hope to hear from you soon, but if i don't,
that's okay too.
many thanks,
luke
</pre>
<h2><a name="SambaInterview">C.3 An Interview with the Developers of Samba and Samba-TNG</a></h2>
<p>By Dr. Peter Gerwinski, FSF Europe.</p>
<p>In January 2002, I asked the developers of Samba and Samba-TNG
about their co-operation with Microsoft concerning inter-operability
of their respective products. This article is a summary of their
answers.</p>
<p><b>Dr. Andrew Tridgell</b> and <b>Andrew Bartlett</b> have been
working in the Samba development team on adding Active Directory
support to Samba 3.0.</p>
<ul>
<li>Interoperability between Samba and Windows is currently far from
being seamless.</li>
<li>Microsoft has published some information on how a Unix-like
system can add itself to an Active Directory domain.</li>
<li>The small amount of documentation from Microsoft on the CIFS/SMB
protocol is completely inadequate for an inter-operable
implementation. Without this documentation other vendors,
including the Samba Team, are forced to spend an enormous amount
of time on network reverse-engineering of basic elements of the
protocol.</li>
<li>Microsoft provides some online documentation for its Kerberos
PAC extensions, but in order to get access to it, one must
accept a license whose restrictions render the documentation
useless for most software projects, including Samba.</li>
<li>There is no protocol-level documentation for NT4 domains.
Microsoft sometimes claims that NT4 domains are documented, but
what they are referring to is the API documentation, which is
almost completely useless for non-Windows implementations.</li>
<li>Most of the information needed to achieve inter-operability was
obtained by network reverse-engineering.</li>
<li>In many cases, Microsoft creates complex protocols that make
network reverse-engineering difficult. It considers the
protocols its own private property and refuses to co-operate with
other vendors on standardisation, especially when non-Windows
platforms are involved.</li>
</ul>
<p><b>Luke Kenneth Casson Leighton</b> was the person in the Samba
team who has been responsible for the NamedPipes, DCE/RPC support,
DCE/RPC services, NTLMSSP etc. that are essential to providing
Windows NT 4.0 Domains and furthermore are still essential as
support to Windows 2000 Domains. He is the author of the book
&quot;DCE/RPC over SMB: Samba and Windows NT Domain
Internals&quot;, ISBN 1578701503 by MTP (New Riders Group) which
documents about 6-7 years of his work on Samba. Today he works on a
new project, &quot;Samba-TNG&quot;, which aims to be a successor of
Samba.</p>
<ul>
<li>In July 1997, Luke Kenneth Casson Leighton followed the
guidelines as outlined in 90/EC/250 &quot;to obtain information by
means other than reverse-engineering&quot;. He has been asking
Microsoft for the necessary information to obtain
inter-operability for two months. He got no reply. </li>
<li>In early 2000 he asked Microsoft for the information necessary
to obtain inter-operability with Windows 2000 Domains. The reply
was that this information will definitely not be made available.</li>
<li>Consequently, most of the information published in the book was
obtained by network reverse-engineering.</li>
<li>This network reverse-engineering brought some security holes in
Windows NT to light which were reported to Microsoft. As a
result of the security fixes, the information obtained by
network reverse-engineering was no longer true. In order to find
out the new specifications needed to gain back inter-operability,
Luke Kenneth Casson Leighton had <em>again</em> to follow the
90/EC/250 guidelines, and finally had <em>again</em> to obtain
the information by network reverse-engineering.</li>
<li>In one exceptional case, Microsoft itself was in need of an
upgrade to Samba and gave the developers some information which
saved them about two months of time.</li>
<li>The protocols designed by Microsoft are highly dependent on each
other. They form five levels of - all undocumented - protocols
which are <em>all</em> needed to get seamless inter-operation. In
other words: Microsoft's protocols are designed to make
inter-operation difficult.</li>
</ul>
<h2><a name="Death">D The Death of TCP/IP<br />
Why the Age of Internet Innocence is Over</a></h2>
<p>By Robert X. Cringely.</p>
<p>2 August 2001,
<a href="http://www.pbs.org/cringely/pulpit/pulpit20010802.html">http://www.pbs.org/cringely/pulpit/pulpit20010802.html</a></p>
<p>As events of the last several weeks have shown, Microsoft Windows,
e-mail and the Internet create the perfect breeding ground for virus
attacks. They don't even have to exploit Windows flaws to be
effective. Any Visual BASIC programmer with a good understanding of
how Windows works can write a virus. All that is needed is a cleverly
titled file attachment payload, and almost anyone can be induced to
open it, spreading the contagion. It is too darned easy to create
these programs that can do billions in damage. The only sure way to
fix the problem is to re-stripe the playing field, to change the game
to one with all new rules. Some might argue that such a rule change
calls for the elimination of Microsoft software, but that simply
isn't likely to happen. It's true that [GNU/]Linux and Apache are
generally safer than Windows 2000 and IIS, but Microsoft products
aren't going to go away. I promised you an answer to how to secure
the Internet, and I mean to come through. First, we'll start with
the way I would do it, then follow with a rumor I have heard about
one way Microsoft might want to do it.</p>
<p>The wonder of all these Internet security problems is that they
are continually labeled as &quot;e-mail viruses&quot; or
&quot;Internet worms,&quot; rather than the more correct designation
of &quot;Windows viruses&quot; or &quot;Microsoft Outlook
viruses.&quot; It is to the credit of the Microsoft public relations
team that Redmond has somehow escaped blame, because nearly all the
data security problems of recent years have been Windows-specific,
taking advantage of the glaring security loopholes that exist in
these Microsoft products. If it were not for Microsoft's carefully
worded user license agreement, which holds the company blameless for
absolutely anything, they would probably have been awash in class
action lawsuits by now.</p>
<p>Of course, it is not as though Microsoft intended things to be
this way. No company deliberately designs bad products. But you must
understand that Microsoft limits its investments to things that will
enhance a product's market share. Every feature in Windows had to
pass the litmus test, &quot;Does it increase market share?&quot;
Putting security safeguards in their products evidently failed the
litmus test, and therefore weren't added. While it is true that
virus authors will target platforms that give them the most bang for
their programming buck, the Windows platform has virtually no
security to even slow them down. I believe the lack of security in
Microsoft software was a deliberate business decision.</p>
<p>Alas, things are only likely to get worse in the near term. So
far, we've been lucky in that most virus authors have been impatient
and want to see the immediate effects of their work. It is far more
effective to be patient and let the virus spread quietly for
months. If the virus does nothing, the defense against it will be
slow and/or too late. If the virus does very little on one's PC (for
awhile), it won't be discovered easily. It is also possible to make a
stealth virus. I won't go into specifics for obvious reasons, but if
you think about how virus detection software works, it isn't hard to
trip it up.</p>
<p>Even if 98 percent of the world's computers had current anti-virus
software (which they don't), the remaining two percent would still be
millions of devices capable of bringing down the entire Internet if
infected.</p>
<p>And now, we have the impending release of Windows XP, and its
problem of raw TCP/IP socket exposure. As I detailed two weeks ago,
XP is the first home version of Windows to allow complete access to
TCP/IP sockets, which can be exploited by viruses to do all sorts of
damage. Windows XP uses essentially the same TCP/IP software as
Windows 2000, except that XP lacks 2000's higher-level security
features. In order to be backward compatible with applications
written for Windows 95, 98, and ME, Windows XP allows any application
full access to raw sockets.</p>
<p>This is dangerous.</p>
<p>Not only is it dangerous, it is unnecessary. What is wrong with
telling application developers, &quot;Your application can't have
access to raw sockets,&quot; or, &quot;When XP ships you need to have
a non-raw socket version ready for your customers,&quot; or, &quot;If
your application needs to access raw sockets, these are the security
rules and interfaces you will have to use&quot;? The bottom line is
that Microsoft's choice to provide access to raw sockets was based on
the market share litmus test, period.</p>
<p>Unless this feature is changed before XP is released, it will mean
that millions of new computers will be manufactured as perfect little
virus machines. Virus authors who are anticipating these new PCs will
be able to pre-position their digital vermin to take advantage of the
socket flaw as the new machines appear. The result is that, in all
likelihood, there will be massive data security problems, as well as
massive damage to files and property, all as a result of Windows
XP. But as consumers, guess what - we won't even get a
choice. Microsoft will require the PC makers to install XP in the
factory. It will come on your PC, and you won't have the choice or
option to pick something different. When Microsoft issues a new OS,
it is forced into the market.</p>
<p>Here is my preferred solution for Internet security. We could
implement a secure user identity system precisely like telephone
Caller ID. It would be essentially an Internet ID. All Internet
transactions could be based on it. Anyone who sends me e-mail can be
identified. Anything I send can be traced to me. People wouldn't be
forced to participate, but if they remain anonymous, I might choose
to block them. I certainly wouldn't accept file attachments from
them. I know you hate this idea, but I think the Internet needs a
fingerprint. It does not have to have personal information, but if
you break the law it can be traced to you. You can choose not to have
a fingerprint, but then your ability to communicate with others may
be limited - a price many people may choose to pay.</p>
<p>I am not opposed to people being anonymous - just to anonymous
people receiving public assistance. Send all the anonymous love or
hate mail you like, but don't expect to attach a file.</p>
<p>And what's with those file attachments, anyway? Replace mail
clients and APIs with secure models. The new model will not run
attachments as they do today. E-mail attachments should not have
access to the e-mail client, APIs, etc. Attachments should not have
access to the operating system by default. The user should approve
the use of some APIs, like having to give permission before device
drivers are updated.</p>
<p>Any application that wants to send bits onto the Internet must
first be permitted to do so. Applications would be registered to send
outgoing traffic. The applications would be limited by function and
port. You would register your e-mail program as the only application
that could talk SMTP, POP3, etc. If Microsoft Word wanted to send an
e-mail, your e-mail program would pop up, ask you to authenticate
yourself and explicitly send the message. At that point, you would be
in complete control of what was happening on your PC. For
mail-enabled applications, there would be an application user account
registered on the post office. The account would be unique, and
registered to a unique application.</p>
<p>If kids want to install an Internet game, the game's IP port would
be registered and permitted to operate, hopefully by the parent. If
kids wanted to install an Internet chat program, too bad - it
wouldn't work if Dad didn't want it to work.</p>
<p>By default, under this scenario, your PC becomes a TCP/IP
read-only device. By running applications like Gibson's Zone Alarm
you can - right now - severely limit the use of TCP/IP by
applications on your PC. And what happens when you do so? Everything
works just fine. So rather than ripping the protocol stack wide open,
let's do the exact opposite. Restrict access to it.</p>
<p>The only e-mail activity on my PC should be initiated by me,
personally. Nothing else should access my address book or send out
messages without my express permission. Microsoft will of course
reject the idea, mostly because it will fail the &quot;increase
market share litmus test.&quot; My answer is, &quot;Microsoft, if you
do not take responsibility for locking down your APIs, it will become
obvious to the public and become a detriment to your market
share.&quot;</p>
<p>Now to the other approach, the one some people attribute to
Microsoft. I am not making this up. The story came to me from people
I have come to trust, and I have looked into it closely enough to
think it might have some validity. But for the sake of keeping
lawyers off my back, let's just call it a rumor, and only use it as a
basis for discussion. To be perfectly clear, I am not claiming that
the following is true - just that I have heard it from more than one
source, and think it accurately characterises some past behaviors of
Microsoft. Perhaps by bringing it into the light, we can ensure that
Redmond takes a more thoughtful course. I certainly hope it is
wrong.</p>
<p>Programmers who ought to be familiar with Microsoft's plans have
suggested that the real motive for raw socket support is for
Microsoft to use Windows XP to exploit a bad situation, to
deliberately make things worse.</p>
<p>According to these programmers, Microsoft wants to replace TCP/IP
with a proprietary protocol - a protocol owned by Microsoft - that it
will tout as being more secure. Actually, the new protocol would
likely be TCP/IP with some of the reserved fields used as pointers to
proprietary extensions, quite similar to Vines IP, if you remember
that product from Banyan Systems. I'll call it TCP/MS.</p>
<p>How do you push for the acceptance of a new protocol? First, make
the old one unworkable by placing millions of exploitable TCP/IP
stacks out on the Net, ready-to-use by any teenage sociopath. When
the Net slows or crashes, the blame would not be assigned to
Microsoft. Then ship the new protocol with every new copy of Windows,
and install it with every Windows Update over the Internet. Zero to
100 million copies could happen in less than a year, and that year
could be prior to the new protocol even being announced. It could be
shipping right now.</p>
<p>Suppose you are a typical firm that also has some non-Microsoft
servers. You will want to use this new protocol between your
Microsoft and non-Microsoft servers. Microsoft could charge Sun
millions to put TCP/MS on their systems. Microsoft can promise open
support, but make it financially impractical. Then use it in a
marketing attack against competitors. Zero-Footprint network drivers,
ODBC, and MAPI are examples of Microsoft &quot;open&quot; standards
that took years for non-Microsoft firms to use. Almost anyone who
would have wanted to use these open standards has been driven out of
business. Second part of the push for the new protocol will be from
AOL/Time-Warner, normally Microsoft's top competitor - but not on
this issue. AOL isn't really part of the grand vision of the new
protocol. It's just that if they get more of what they want (paid
accounts, music and video royalties), they won't object to Microsoft
pushing for secure authenticated connections.</p>
<p>Third and most powerful part of the push for Microsoft's new
protocol will be action by Congress. They'll cite concerns of
business, and hold up the standard scare tactics of terrorists and
child pornographers. They want all connections, all packets to be
traceable. Say goodbye to TCP/IP and to anonymous connections of any
kind. Hello to Hailstorm, tracking everything down to the last mile,
and a more business-friendly Internet with prioritised
packet-handling. If this seems like too much infrastructure to
change, it isn't. Not if the old protocol has been rendered useless
and the new one can be implemented by an upgrade to your router.
Vines IP - in many ways the basis for TCP/MS - was sufficiently close
to regular TCP/IP that most routers only had to have a flash upgrade
(to IOS, in the case of Cisco) in order to route Vines IP. This will
be an inconvenience, sure, but marketing types will see it more like
another Y2K bug - an opportunity to sell, sell, sell.</p>
<p>But won't the Internet Engineering Task Force (IETF) stop it from
happening? No. The entire basis for setting standards on the Internet
is to first put the new code in service, and then seek
standardisation. There are no IETF rules that say 100 million plus
computers can't run TCP/MS, and there is no deadline for
standardisation. Once the right 100 million plus computers are
running the new protocol, Microsoft won't have any reason to seek
standardisation. Why not? It is Possible, for awhile, to run more
than one protocol at a time. Take as examples of the coexistence of
IPX and IP in Netware systems, or AppleTalk and IP in MacOS systems.
Business will push for the new protocol, and the result will be that
TCP/MS will become a de facto standard, and Microsoft will own the
Net.</p>
<p>And all you have to do to kick it off is implement raw socket
support in the next shipping version of Windows, with the possible
bonus of blaming any problems on UNIX code later.</p>
<p>If business feels a need for the ability to have prioritised
packet Delivery, and government (plus the Recording Industry
Association of America) is uncomfortable with the notion of
untraceable packets and connections, of course Microsoft is going to
try to fill that niche. Haven't you noticed how their ads have been
trying to convince people that Microsoft software is amazingly stable
and secure, and doesn't need minding? That's the image they're trying
to build - solid as a bank.</p>
<p>MS/TCP will ostensibly be a solution to the problems businesses
are having with the Internet. It will assign priorities to packets.
It will insure that all connections and packets can be traced,
authenticated, and monitored. And since all these connections to the
Internet have to be authenticated to someone, it will likely be
hooked into a credit card or some sort of account, from which
Microsoft can extract its price as the gatekeeper for the
authentication via Hailstorm, Passport and .NET.</p>
<p>But how will this stop the &quot;I just e-mailed you a virus&quot;
problem? How does this stop my personal information being sucked out
of my PC via cookies? It won't. Solving those particular problems is
not the protocol's real purpose, which is to increase Microsoft's
market share. It is a marketing concept that will be sold as the
solution to a problem. It won't really work.</p>
<h2><a name="Settlement">Statement by the FSF about the Settlement in the USA</a></h2>
<p>The Microsoft Proposed Judgment has been designed by Microsoft to
make its provisions useless or worse for free software. The following
are the specific provisions of the Judgment to which the Foundation
will be formally objecting in its filing under the Tunney Act, which
will be made on or before January 28, 2002, and will be available at
<a href="http://www.fsf.org">http://www.fsf.org</a> and <a
href="http://moglen.law.columbia.edu">http://moglen.law.columbia.edu</a>.</p>
<p>Section III(D) of the Judgment provides that:</p>
<blockquote>
Starting at the earlier of the release of Service Pack 1 for Windows
XP or 12 months after the submission of this Final Judgment to the
Court, Microsoft shall disclose to ISVs, IHVs, IAPs, ICPs, and OEMs,
for the sole purpose of inter-operating with a Windows Operating
System Product, via the Microsoft Developer Network
(&quot;MSDN&quot;) or similar mechanisms, the APIs and related
Documentation that are used by Microsoft Middleware to inter-operate
with a Windows Operating System Product.
</blockquote>
<p>The &quot;sole purpose&quot; requirement means that Microsoft does
not have to make any such API information available to developers of
software like WINE whose purpose it is to make a non-Microsoft OS
inter-operable with applications written for Windows. This therefore
excludes all measures to assist GNU/Linux to inter-operate with
applications written for Windows, which would provide maximum
competition in the OS market, which should be the objective of a
competition-law remedy.</p>
<p>Section III(E) of the Judgment provides that:</p>
<blockquote>
Starting nine months after the submission of this proposed Final
Judgment to the Court, Microsoft shall make available for use by
third parties, for the sole purpose of inter-operating with a Windows
Operating System Product, on reasonable and non-discriminatory terms
(consistent with Section III.I), any Communications Protocol that
is, on or after the date this Final Judgment is submitted to the
Court, (i) implemented in a Windows Operating System Product
installed on a client computer, and (ii) used to inter-operate
natively (i.e., without the addition of software code to the client
or server operating system products) with Windows 2000 Server or
products marketed as its successors installed on a server computer.
</blockquote>
<p>This provision too means that GNU/Linux software developers are
not going to have access to information about protocols implemented
in Windows.</p>
<p>Under III(I), the Judgment requires that</p>
<blockquote>
Microsoft shall offer to license to ISVs, IHVs, IAPs, ICPs, and
OEMs any intellectual property rights owned or licensable by
Microsoft that are required to exercise any of the options or
alternatives expressly provided to them under this Final
Judgment
</blockquote>
<p>GNU/Linux developers have no rights under III(D) or (E) and thus
are not entitled to license any rights from Microsoft. Even if
they were, however, III(I) only gives those rights provided that:</p>
<blockquote>
<p>1. all terms, including royalties or other payment of monetary
consideration, are reasonable and non-discriminatory;</p>
<p>
2. the scope of any such license (and the intellectual property
rights licensed thereunder) need be no broader than is necessary to
ensure that an ISV, IHV, IAP, ICP or OEM is able to exercise the
options or alternatives expressly provided under this Final
Judgment (e.g., an ISV's, IHV's, IAP's, ICP's and OEM's option to
promote Non-Microsoft Middleware Products shall not confer any
rights to any Microsoft intellectual property rights infringed by
that Non-Microsoft Middleware Product);</p>
<p>
3. an ISV's, IHV's, IAP's, ICP's, or OEM's rights may be
conditioned on its not assigning, transferring or sub-licensing its
rights under any license granted under this provision;</p>
<p>
4. the terms of any license granted under this section are in all
respects consistent with the express terms of this Final Judgment;
and</p>
<p>
5. an ISV, IHV, IAP, ICP, or OEM may be required to grant to
Microsoft on reasonable and nondiscriminatory terms a license to
any intellectual property rights it may have relating to the
exercise of their options or alternatives provided by this Final
Judgment; the scope of such license shall be no broader than is
necessary to insure that Microsoft can provide such options or
alternatives.</p>
<p>
Beyond the express terms of any license granted by Microsoft
pursuant to this section, this Final Judgment does not, directly
or by implication, estoppel or otherwise, confer any rights,
licenses, covenants or immunities with regard to any Microsoft
intellectual property to anyone.</p>
</blockquote>
<p>Here subsection (1), which establishes so-called
&quot;reasonable and nondiscriminatory&quot; licensing, means only
certain wealthy developers would be entitled to Microsoft API
information. Sub (2) repeats that no license will be given to any
information for purposes except inter-operability with Microsoft
OSs. Sub (3) means that Microsoft can use licenses which prohibit
implementing any of their APIs in GPL'd software, because they can
refuse to permit any relicensing to downstream users, which GPL
requires. The final paragraph is intended to prevent us from ever
arguing in future that the &quot;nondiscriminatory&quot; clause or
any other part of this Judgment establishes an equitable right in
free software developers to have access to Microsoft API
information.</p>
<p>Section III(J) of the Judgment says:</p>
<blockquote>
<p>J. No provision of this Final Judgment shall:</p>
<p>
1. Require Microsoft to document, disclose or license to third
parties: (a) portions of APIs or Documentation or portions or
layers of Communications Protocols the disclosure of which would
compromise the security of anti-piracy, anti-virus, software
licensing, digital rights management, encryption or authentication
systems, including without limitation, keys, authorisation tokens
or enforcement criteria; or (b) any API, interface or other
information related to any Microsoft product if lawfully directed
not to do so by a governmental agency of competent
jurisdiction.</p>
<p>
2. Prevent Microsoft from conditioning any license of any API,
Documentation or Communications Protocol related to anti-piracy
systems, anti-virus technologies, license enforcement mechanisms,
authentication/authorisation security, or third party intellectual
property protection mechanisms of any Microsoft product to any
person or entity on the requirement that the licensee: (a) has no
history of software counterfeiting or piracy or willful violation
of intellectual property rights, (b) has a reasonable business need
for the API, Documentation or Communications Protocol for a planned
or shipping product, (c) meets reasonable, objective standards
established by Microsoft for certifying the authenticity and
viability of its business, (d) agrees to submit, at its own
expense, any computer program using such APIs, Documentation or
Communication Protocols to third-party verification, approved by
Microsoft, to test for and ensure verification and compliance with
Microsoft specifications for use of the API or interface, which
specifications shall be related to proper operation and integrity
of the systems and mechanisms identified in this paragraph.</p>
</blockquote>
<p>Because the phrase &quot;authentication/authorisation
security&quot; is so broad, Microsoft can refuse to give any
developer of &quot;Middleware&quot; meant to secure inter-operation
of free software with .NET any information whatever, or condition
the grant on its own decision about the &quot;commercial
viability&quot; of the firm. The GNOME Foundation, FSF, dotGNU,
and all other non-profits would of course be entirely excluded.
And Microsoft can claim a government-blessed monopoly over all DRM
technology it dreams up with the content oligarchs, thus excluding
all free software OSs from the world of multimedia altogether,
which would make both Microsoft and Hollywood very happy.</p>
<p>In short, the Proposed Judgment is a strategic attack on all the
most crucial points, a critical part of Microsoft's campaign
against free software. It doesn't just fail the Government's own
objective of increasing competition in the line of commerce where
the Government proved Microsoft was an illegal monopoly, it
increases the monopolist's hold by giving blessing to all of
Microsoft's measures to eliminate its one remaining, unique
competitor.</p>
<!-- End page content -->
</body>
<timestamp>
Last update:
<!-- timestamp start -->
$Date: 2004-07-29 08:20:40 $ $Author: now3d $
<!-- timestamp end -->
</timestamp>
</html>
<!--
Local Variables: ***
mode: xml ***
End: ***
-->