Open Source Takes a Look at Loopholes in the Microsoft Deal
November 7, 2001
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.
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.
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.
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?
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?
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.
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: firstname.lastname@example.org.