Cringely On Microsoft Settlement

sandalwood writes: "Robert X Cringley has a new article about the proposed settlement in the Microsoft antitrust case. He includes information on where to write to make your views known (the 'proposed Final Judgement' accepts comments from the public for a period of 60 days after it's been published)."

Comments

Re:Not a troll, but useless

[BitterOak]

How can we get THROUGH to these guys?

I thought the slashcode used to run this site is publically available. If you don't like the way the editors run the site, start your own. If you can do it better than the Slashdot folks, maybe people will switch to using your site instead.

What I wrote:

[Ian Bicking]

Please, write in with your own thoughts and concerns on the settlement: microsoft.atr@usdoj.gov -- this settlement is supposed to be in support of the American People, not business interests. Microsoft was found guilty of harming American consumers, don't let the government forget that it's consumers that need redress, not businesses. I don't really know how the process works, but simply writing in a very short, well-reasoned comment is probably quite beneficial if you don't want to write something longer. Here's what I wrote:

------------
To: microsoft.atr@usdoj.gov
Subject: Micosoft Settlement

The manner in which APIs would be revealed are limiting to Microsoft's main competitor: Free and Open Source Software ("Free" defined as "without restriction" not "free of cost").

This software is created largely by individuals in informal and generally noncommercial cooperation. This is a very significant movement, and provides great potential benefits for American consumers. I think that makes such Free and Open Source Software *the* essential beneficiary of the ruling against Microsoft. This case was not a question of whether businesses were harmed by the monopoly, but rather consumers. It is essential that this pro-consumer movement be helped by the settlement. Instead they speficially discriminated against by the settlement.

Under provisions to release the API of Microsoft products, Microsoft is given discretion as to who they will release information: namely, "viable businesses", with Microsoft being able to interpret that as they wish.

I am personally involved in many projects that have the potential to benefit consumers, but are not businesses of any sort, rather a conglomeration of individual developers. I would expect that these groups will be excluded under this settlement.

Instead of this model, APIs should be made fully public. Individuals, in some manner, should be able to ask questions of Microsoft regarding these APIs, and have them answered publically. If it seems too difficult to allow any individual to ask such a question, an electronic petition process could be used instead, as long as a group of individuals can have the same weight as a commercial organization.

It is essential that the API information be made public. If it is hindered by any sort of NDA it will be *absolutely useless* to Free/Open Source software projects. We have formed a legal and social structure where we do not have the ability to keep pieces of our code private. This process must be respected by the settlement, as it forms the most serious competition for Microsoft, and is of large benefit to consumers.

It is also essential that non-commercial groups of individuals be able to access API documentation, and have questions resolved by Microsoft. In general, it is dangerous to allow Microsoft to have discretion on any aspect of this manner, as they can use that to further punish their most stringent competitors as they have done so many times in the past.

It is also dangerous to allow them discretion on security issues. While it is acceptable that they be allowed a short, private period to resolve security issues before making them public, all aspects of their systems must be made public. It is all too easy to add security aspects to nearly any portion of a system. It is even potentially a good thing that they add security at many parts of their system. However, they should not need to be private about their security measures to ensure the effectiveness of that security. The Free/Open Source communities have created large amounts of software that is secure while being open. Microsoft should do the same. This process is completely possible, and has been demonstrated over and over for as long as computer security has existed.

III(J)(2), Maybe. III(D), No Way

[hbo]

Section III(J)(2) reads:

(No provision of this Final Judgement shall ...) 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/authorization 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.

So, that does indeed seem to give MS the right to stonewall Free Software projects like Samba, but only on security APIs. However, section III (D) reads:

D. 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 interoperating with a Windows Operating System Product, via the Microsoft Developer Network ("MSDN") or similar mechanisms, the APIs and related Documentation that are used by Microsoft Middleware to interoperate with a Windows Operating System Product. In the case of a new major version of Microsoft Middleware, the disclosures required by this Section III.D shall occur no later than the last major beta test release of that Microsoft Middleware. In the case of a new version of a Windows Operating System Product, the obligations imposed by this Section III.D shall occur in a Timely Manner.

And "ISV" is defined in VI (I) as:

"ISV" means an entity other than Microsoft that is engaged in the development or marketing of software products.

The 'or' doesn't seem to leave much room for MS to define who the section applies to.

Re:Microsoft should be treated like IBM was.

[Suppafly]

I totally agree with you're saying except

What CODEC did the pirates, who could choose any one they want to swap pirate video, choose to use? Quicktime Sorenson? RealMedia? No, Media Player.

media player isnt a codec, divx is, although media player is one of the few players that doesnt have a problem with using 3rd party codecs to play stuff.

My Letter

[hbo]

I am a Computer Systems Administrator with 16 years professional
experience. I write with concern over the revised proposed Final
Judgment of United States v. Microsoft. In particular, I am concerned
with the language of section III(J)(2) of the revised proposed final
Judgment which reads:

"(No provision of this Final Judgment shall:...) 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/authorization 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."

Some background regarding my experience with Microsoft software will help
to clarify my concerns with this language.

For the first five years of my career, I used first the VMS, then the
Unix operating systems exclusively. Microsoft's DOS and Windows
operating systems were not considered by most of my customers
(Scientists and graduate students at the Physics Department of UCSB)
to be suitable for their purposes. In 1991, I got a new job at a
commercial company, Octel Communications in Milpitas California,
supporting their engineers. At Octel, Microsoft's dominance of the
market for PC operating systems was well under way. The engineers
mostly used Unix (Sun's version) but the rest of the company used DOS
and Windows 3.11. For me, as a Unix Systems Administrator, this posed
an immediate problem. The Windows systems were networked together
using a Microsoft protocol called SMB. The details of this protocol
were partly available, and partly kept secret (or at least not
published) by Microsoft. This meant that resources on the Windows
network, such as disks and printers, were unavailable to users on the
Unix network, and vice-versa. This was sub-optimal in a number of
ways. It led to situations in which workgroups would have two
printers, on each for Windows and Unix. Files would be shared using
floppy disks. Searching for a solution, I found a wonderful software
package on the Internet called Samba. This software, written by clever
programmer in Australia, named Andrew Tridgell, implemented
communications between the incompatible Unix and Windows worlds. Using
Samba, I could make my Unix computers and disks available to Windows
users. I could also make Windows printers available to Unix
users. Getting at Windows files from Unix was less well supported, but
it was possible. This was OK because at that time the Windows boxes
tended to be desktop machines, whereas the Unix computers were
generally larger server boxes. This meant most of the disk space we
wanted to share was on Unix, and Samba let us do that very well.

Two points about Samba are relevant in my concern over the language cited
in my first paragraph. First, since the SMB protocol in use on Windows 3.11
differed in important details from the various published specifications,
Andrew Tridgell had to "reverse engineer" the protocol. (When he started
he didn't even know there were any published specs. By the time he got
his hands on them, he had implemented enough on his own to know that certain
details were wrong or missing.) This may have been due to a desire by
Microsoft to keep the details of their implementation secret or commercial
advantage. Most Finance departments in industry look askance at duplicating
resources like printers across an entire organization. At Octel, there
was pressure from Finance to consolidate the computing platforms in use
due to the added expense. Since Finance used Windows, that was the platform
they wanted to standardize on. The second point about Samba is it was developed
by volunteers, and given away for free on the Internet. This model of software
distribution is now more familiar, (It goes by various labels, depending on
who is describing it and on what software license is in use. "Free Software"
and "Open Source Software" are two popular labels. Based on its license, the
former is the proper label for Samba.) but it was novel in the commercial
world in 1991.

Which brings me finally back to the language of Section III(J)(2) of
the revised proposed final Judgment reproduced above. One of the
several criteria for which "No provision of this Final judgment
shall ... Prevent Microsoft from conditioning any license ..." for its
security related APIs to a "person or entity" is that the entity " meets
reasonable, objective standards established by Microsoft for
certifying the authenticity and viability of its business..." (d).
The problem with this clause as it relates to the current discussion is that
Samba, as related above, does not have a "viable business." Samba is
given away for free by volunteers. It is nonetheless a critical piece of
software in ensuring that computers running Microsoft's OS "play nice" with
rival Operating Systems. If Microsoft is allowed, at its sole discretion,
to withhold APIs from entities it deems to not have a "viable business,"
there is a real danger Microsoft will do so for projects, like Samba,
that tend to soften the power of Microsoft's monopoly in the market for
PC operating systems. The quoted section limits this clause to APIs
".. related to anti-piracy systems, anti-virus technologies, license
enforcement mechanisms, authentication/authorization security, or third party
intellectual property protection mechanisms." However this limitation doesn't
rescue Samba, which must use "authentication/authorization security" mechanisms
to access resources on networks running Microsoft's software.

Based on this concern, I strongly urge you to amend the language in the
Final Judgment to place the decision in the hands of the Technical Committee
set up under section IV (B) of the Final Judgment, rather than Microsoft's

Thank you for your attention,