OPINION: Open Source Takes a Look at Loopholes in the Microsoft Deal

This is G o o g l e's cache of http://www.osopinion.com/perl/story/14620.html.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
To link to or bookmark this page, use the following url: http://www.google.com/search?q=cache:www.osopinion.com/perl/story/14620.html

Google is not affiliated with the authors of this page nor responsible for its content.

OPINION:
Open Source Takes a Look at Loopholes in the Microsoft Deal

Send this Article
Print this Article Related Stories
Contributed by Adam Barr
osOpinion.com
November 7, 2001

Will contributors to open source code be allowed access to Microsoft data under the proposed antitrust settlement - or even play a role in enforcing the deal?

In This Story:

Imagine a System

To Code or Not To Code

A Vendor by Any Other Name

A License You Can't Refuse

Sign-Up Sheet

Related Stories

The proposed antitrust agreement between Microsoft and the U.S. Department of Justice calls for the formation of a three-person Technical Committee to assist in enforcement of and compliance with the agreement (section IV.B.1). But a close look at the agreement reveals more than one loophole and back-door provision that could either limit -- or enhance -- the role of open-source contributors in enforcing the deal.

The members of the Technical Committee must be "experts in software design and programming" (IV.B.2) who have not worked for Microsoft or a competitor within the past year (IV.B.2.a).

The Technical Committee appears designed to handle detailed programming issues. Many stipulations in the agreement, such as the rules against Microsoft retaliating against Windows OEMs (original equipment manufacturers) who distribute competing products (III.A) or change the Windows desktop (III.C), and requirements for uniform licenses for the top 20 Windows OEMs (III.B), do not require a committee of software design experts to adjudicate.

Furthermore, provisions giving the user control of adding, removing and replacing middleware (III.H) are likewise not heavily technical.

Imagine a System

More interesting are the rules stipulating that Microsoft must disclose its proprietary application programming interfaces (APIs) -- which are used by Microsoft middleware to interoperate with Windows -- to Independent Software Vendors (ISVs) (III.D). The software giant also must allow any third party to license details of the network communications protocols that are used to communicate between Windows client machines and Windows servers (III.E).

Imagine a block diagram of software running on a computer, with the operating system at the bottom, and applications at the top. Add in middleware above the operating system, and you have applications that rest above the middleware alongside those that rest above the native operating system.

Microsoft has always documented interfaces between the applications and the operating system, and between the applications and the middleware, to better establish the operating system and the middleware as platforms.

To Code or Not To Code

Despite that fact, there have been gaps in the documentation. Some would claim this was intentional to favor Microsoft applications, while others would say it was accidental, but the key is that for API documentation, the proof is in the pudding. Until someone tries to use the API, it is hard to tell if it is completely documented.

Now Microsoft is being forced to document a new interface, between the middleware and the operating system. As hard as the Technical Committee reviews the API (and the underlying source code if needed), until someone tries to write their own middleware, it will be hard to certify that the documentation is adequate. The open-source community could help here, by using the information as the basis for real code.

The same applies to the protocols for talking to a Windows server . The Technical Committee can review the documentation and fire up a packet sniffer to ensure that every bit on the network is accounted for, but the real validation will come when a non-Windows client can talk natively to a server.

Guess what? Another opportunity for the open-source community to help enforce the Microsoft settlement.

A Vendor by Any Other Name

What is unclear is exactly how much the open-source community will be allowed to help. First of all, the definition of an "ISV" is limited to those software vendors that make products that run on Windows (VI.I), thus excluding pure Linux companies.

However, the restriction for ISVs is only for middleware-to-Windows API details. The communication protocol information can be licensed by anybody, but some interesting language surrounds this provision.

First of all, Microsoft is required to license any intellectual property (IP) as needed, but not to everyone; only to ISVs and some others (III.I). Thus, although Microsoft is required to license protocol information to anyone, it could theoretically use the IP restriction to avoid licensing some information to a Linux company that was not an ISV by the definition in the agreement.

It can be argued that on-the-wire protocols do not constitute IP, since they are visible to anyone, but why was the IP restriction worded as it was, rather than stating that any third party could license what it needs?

A License You Can't Refuse

Second, Microsoft is allowed to withhold information that would "compromise the security" of anti-piracy, antivirus, software licensing, digital rights management, encryption or authentication systems (III.J.1). But properly designed versions of all of those systems should not be able to be compromised by licensing deals, so Linux companies should be able to get the information they need. Right?

Well, maybe not. Under the next paragraph of the proposed deal, Microsoft is allowed to refuse to license any information about anti-piracy, antivirus, etc. unless the licensing company "has no history of ... willful violation of intellectual property rights," and "meets reasonable, objective standards established by Microsoft for certifying the authenticity and viability of its business." (III.J.2).

Given that Microsoft has complained that the GPL (general public license) hurts intellectual property rights -- and may claim that open-source companies have no reasonable viability -- is paragraph II.J.2 a back-door way of preventing any information about those areas from being released to the open-source community?

Sign-Up Sheet

Even if this were Microsoft's intentions, the Technical Committee might find a way around it.

In addition to billing their salaries and expenses to Microsoft (IV.B.6.A), and having access to all the people, documents and source code they wish (IV.B.8), the Technical Committee can hire (at Microsoft's expense), any staff or consultants it needs (IV.B.8.h). Furthermore, they must also be experts in software design who have not worked for Microsoft or a competitor.

So outside of academia, the world of open-source contributors (who do not happen to work for a Microsoft competitor) is fertile ground for the Technical Committee to look for consultants.

Author's background:

Adam Barr is an expert in software design and programming, who has not worked for Microsoft or any competitor for the past year. His book about his 10 years at Microsoft, "Proudly Serving My Corporate Masters," was published in December 2000. He lives in Redmond, Washington. Adam can be reached at: adamba@gte.net.

Don't get spun by the media. Spin your own...
Have YOUR Tech/OS Opinion featured on OSO!