Without a doubt, you'll have a clearer picture of Microsoft's position if you do. I'm not saying you'll admire them more than you already do, but at least one can grasp what the diplomatic letter asking for fair play was purportedly about.

And we get a look at Microsoft's guy who handles Ecma and OASIS interactions and now newly sits on the ODF subcommittee, Jim Thatcher. One of the Annexes is written by him, so you can get a measure of the man. It turns out he used to be a Novell guy, and he's one of the small crowd Microsoft has telling the Commission why Microsoft's documentation, deemed unfit for its intended purpose by the independent Trustee, was perfectly adequate, in their opinion. I think there may be two different purposes in this picture. Of course, that was before Microsoft's purported epiphany, announced after the recent hearing, that they had experienced a breakthrough and now understand what is required from them in the way of compliance.

Reading the Microsoft reply to the criticisms of its documentation makes it obvious what the Trustee, Neil Barrett, was talking about. It seems that there was no way to follow the documentation without reading other books and white papers, not written by Microsoft, and looking up standards protocols elsewhere, etc. and trying to figure it out yourself. On page 2 of Annex 5, for example, you find out that the documentation refers to "existing engineering art" meaning books like "Active Directory Cookbook" and "Building LDAP-Enabled Applications". Using those books and white papers, the engineer, they say, can "scope his solution." From the "art" the engineer then makes a list of protocols his design will need to implement. Then he compares that list to the list of protocols Microsoft is offering to license, to find out if he needs documentation from Microsoft or can just implement from existing art entirely, etc. This is all perfectly normal, to hear Microsoft's apologists tell it, in documentation of this type. Honestly, it's a sketch. I'm not an expert, of course, but it left me rolling my eyes. That could just be because there's a little water under that bridge. But I came away with the distinct impression that Microsoft would prefer not to reveal anything it doesn't have to. Their view is that competent engineers are assumed to have a foundation of knowledge of Microsoft ways or the ability to bone up on the subject.

You will also find the exhibits, emails and letters back and forth between Microsoft and the EU Commission fascinating. After reading it all, it's hard to believe Microsoft needed a flash of lightning to strike them on the road to Brussels to figure out what was required. Anyway, that's my reaction, but here it all is, so you can reach your own conclusions.

**************************

• Microsoft’s Response to the Commission’s Statement of Objections:

  RESPONSE OF MICROSOFT CORPORATION TO THE STATEMENT OF OBJECTIONS BY THE EUROPEAN COMMISSION DATED 21 DECEMBER 2005 ...

  1. In this proceeding, the Commission has challenged Microsoft Corporation’s (“Microsoft”) compliance with Article 5 of the Commission’s Decision of 24 March 2004 ( the “2004 Decision”). As Microsoft has repeatedly informed the Commission, Microsoft is fully committed to compliance with the Decision and has taken extraordinary measures to insure that it is in compliance. Hundreds of Microsoft employees and contractors have worked for more than 30,000 hours to create over 12,000 pages of detailed technical documents that are available for license today. In addition, Microsoft has offered to provide licensees with 500 hours of technical support and has made its source code related to all the relevant technologies available under a reference license. These and other steps Microsoft has taken to ensure compliance are detailed below in this Response. While the sufficiency and adequacy of Microsoft’s technical documentation standing alone has been challenged in the Statement of Objections dated 21 December 2005 (the “Statement of Objections”), this Response demonstrates in detail why those objections are not well-founded. But the Statement of Objections does not properly consider the entirety of Microsoft’s compliance efforts, which are considerable, and Microsoft’s commitment to continue working with the Trustee, the Commission, and any licensees to ensure that the information Microsoft has prepared for license in compliance with the Decision is useful and complete. 2. This is the first proceeding in which the Commission is applying its greatly enhanced powers to impose penalties on companies for alleged non-compliance with Commission decisions, so far as Microsoft is aware. 1 With a threatened fine, in the form of a periodic penalty payment of up to EUR 2,000,000 a day, this case will define for the future both the standards the Commission will follow, and the procedural safeguards and transparency, if any, which will apply in such proceedings. ...

  252. In summary, Microsoft respectfully submits that the Commission has not met the standard of proof required of it for the imposition of a fine under Article 24. First, it has submitted no evidence subsequent to Microsoft’s submission on the December 15 deadline that even purports to take this submission into account. Second, the evidence relied upon by the Statement of Objections falls well short of establishing that the information provided by Microsoft in accordance with the 15 December deadline fell short of the obligations set forth in the Article 24(1) Decision.

• Microsoft's Supplemental Response to the Commission's Statement of Objections – March 2, 2006:

  2. The correspondence disclosed on 13 February has disturbing implications for the manner in which the Commission has conducted this case. In disregard of its own public commitments to increased transparency in conducting its investigations, the Commission waited until two days before the deadline for Microsoft’s response to provide these relevant documents. The documents reveal that the Commission has been conducting its investigation of Microsoft’s compliance in secret collaboration with Microsoft adversaries and in violation of its own rules for communication with the Trustee.

  3. Contacts between the Commission and competitors of the company under investigation, and between the Commission and its outside experts are frequently the practice in competition cases. But the contacts disclosed by the documents in this case are entirely inappropriate for two basic reasons. First, these contacts are inappropriate given the ostensibly impartial roles of the Trustee and the OTR Group (“OTR”) in this case. The Statement of Objections relies heavily on the reports of the Trustee and OTR as evidence of Microsoft’s alleged failure to comply with its obligations under the 2004 Decision. In relying on these reports, the Commission casts the Trustee and OTR in the role of independent, impartial experts. However, the Commission’s encouragement of secret contacts between Microsoft’s adversaries and the Trustee and OTR, and the undocumented communications that resulted, is entirely inconsistent with any attempt to portray the Trustee and OTR as independent and impartial experts. By encouraging and facilitating these communications to occur in the dark, and without any record of the content of the communications apparently being kept, the Commission has prevented Microsoft from knowing whether the content of the communications was distorted or accurate....

  5. The 13 February correspondence also calls into question whether the reports of the Trustee and OTR upon which the Statement of Objection is based are really independent, impartial assessments of Microsoft’s Interoperability Information, or instead are argumentative tracts developed for the Commission with the assistance of Microsoft’s competitors.

• Cover letter -- It details all the redactions made to protect "confidential business secrets" - none made in the Response itself.

• Annex 1: Compliance Effort Report:

  1. My name is Gene Chellis. I am a Senior Director, and manager of the Competitive & Regulatory Affairs team in the Microsoft Platforms Business Management group. I have been involved in the production of the technical documentation that Microsoft was ordered to submit pursuant to Article 5 of the 2004 Decision (the “WSPP Documentation”) and the technical documentation Microsoft was ordered to submit in the U.S. (the “MCPP Documentation”) since the very beginning of the project in 2001. Since 2003, I have managed the team responsible for coordinating the work required to meet these obligations. The following summary of Microsoft’s compliance efforts is based on my own knowledge as a result of my involvement in the production of the WSPP and the MCPP Documentation and on information I received from members of my team and others who were also involved in this effort. ...

  4. Over 200 Microsoft employees, including senior executives have been involved in the production of the WSPP and MCPP Documentation. In addition, Microsoft engaged over 20 outside contractors to work on specific tasks of the production of the Documentation as well as a team of computer scientists from Microsoft’s research facility in China and a team of consultants in India. Microsoft estimates that its employees and contractors collectively have spent between 35,000 and 40,000 working hours on the production of the WSPP Documentation.

• Annex 2: MCCP Report:

  1. My name is Gene Chellis. I am a Senior Director and manager of the Competitive & Regulatory Affairs team in the Microsoft Platforms Business Management group. I have been involved in the production and licensing of the technical documentation that Microsoft was ordered to submit pursuant to Article 5 of the 2004 Decision (the “WSPP Documentation”) and the technical documentation Microsoft was ordered to make available in the U.S. (the “MCPP Documentation”) since the very beginning of the project in 2001. Since 2003, I have managed the team responsible for coordinating the work required to meet these obligations, including the licensing programs. The following summary of the MCPP program and private licensing programs is based on my own knowledge as a result of my involvement in the production of the WSPP and the MCPP Documentation and on information I received from members of my team and others who were also involved in the MCPP program or private licensing programs.

  2. The Microsoft Communications Protocol Program (MCPP) demonstrates that much of the documentation that the Commission and Trustee characterize as unusable is in fact being licensed by companies to produce products that incorporate the documented protocols. This is because many of the protocols covered by WSPP are also covered by MCPP, a protocol licensing program established pursuant to a final judgment entered as part of the settlement of antitrust proceedings against Microsoft in the United States. MCPP has been in place for more than three and a half years, and has been successful in attracting 28 licensees to date, 12 of which are already shipping products incorporating MCPP protocols.

  3. Moreover, the three and a half year experience of the MCPP program demonstrates that an iterative process of refining technical documentation in collaboration with licensees and government agencies is ultimately very productive. As with any technical documentation of this scope and complexity, the MCPP documentation is subject to refinement and correction over time. Microsoft has worked closely with the Technical Committee established under the U.S. Final Judgment to monitor compliance with MCPP to both establish appropriate processes for uncovering issues with the documentation and to address those issues, with revisions to the documentation as necessary. The MCPP program serves as a useful model for a protocol licensing program in which government agencies have worked cooperatively with Microsoft toward a common goal of refinement of the protocol documentation. ...

  7. The MCPP and WSPP Technical Documentation are related in two ways. First, there is a substantial overlap of the documentation itself, because many protocols are common to both programs. Second, the underlying process of developing the initial release of the documentation has been the same in both cases. 8. Because they originated from different legal decisions, the MCPP and WSPP programs are somewhat different in scope; however, there is a substantial overlap between the two programs. The MCPP program is limited to client-server protocols, but covers protocols used to support a broad range of services. On the other hand, the WSPP program covers both clientserver and server-server protocols, but is limited to those protocols needed to implement file and print service, and user and group administration. The overlap between the two programs can thus be described as client-server protocols needed to implement file and print service, and user and group administration. There are 42 such protocols out of the 52 WSPP protocols. ...

  13. To date, 28 companies have signed licenses for MCPP protocols, 4 with the first license signed by Network Appliance in December 2002, four months after the start of the program.

  14. The MCPP protocols are grouped into categories corresponding to a specific “server task.” Companies obtain licenses for a particular server task, covering the protocols needed for that server task. Of the 28 licensees, five companies, Unisys, Sun Microsystems, The SCO Group, Realm Systems, and ONStor, have signed licenses for the “General Server Task,” which covers all of the protocols offered under MCPP. In addition, another three companies, EMC Corporation, Network Appliance, and Hitachi, have signed licenses for the “File Server Task”: nearly all of the protocols for this server task are common to both MCPP and WSPP.

  15. Twelve companies currently ship products that incorporate MCPP protocol technology. Among these are Network Appliance and EMC Corporation.

  I'll pause here for a minute to point out that while Microsoft refers to praise from the DOJ in the US antitrust February joint status report, if you actually read it instead of just relying on Microsoft's characterization of it, the DOJ, while they were happy with Microsoft's offer of source code, still mention real usability issues with Microsoft's documentation. The DOJ suggests the following in the report:

  Plaintiffs, in consultation with the TC and Mr. Hunt, have considered the extent to which the availability of source code to licensees will allow the TC to modify its ongoing technical documentation improvement projects and have decided upon a general framework for streamlining the TC's implementation and validation work. With the knowledge that the source code will be available to licensees immediately to supplement the current technical documentation, Plaintiffs are prepared to revise the procedures prescribed under the current Service Level Guidelines ("SLGs"). Specifically, the TC will allow its engineers to access the Microsoft server source code -- as an MCPP licensee will now be able to do -- and any other public sources of information available to licensees, in an effort to resolve quickly as many technical documentation issues as possible without consulting Microsoft. Currently, TC engineers only refer to the documentation or external sources of information specifically referenced in the documentation. The revised approach will more closely mirror the real world situation of licensees and enable the TC to resolve issues more quickly with less consultation with Microsoft.

  The TC will differentiate between two types of issues: (1) those that cannot be readily solved by reference to the source code or public information, thereby making Microsoft's input necessary to resolve the matter; and (2) those issues that can be readily resolved by reference to the source code or public information. Where the TC is able to discover the answer by accessing the source code (or public sources of information), the TC will report the issue to Microsoft, setting forth the question and the apparent answer. Microsoft will then be responsible for reviewing the TC's answer and, once Microsoft confirms the solution, including it in a revision of the technical documentation. This will enable Microsoft to make improvements to the documentation with less work. In performing this review, Microsoft agrees to use its best efforts to resolve the issues and make changes, where appropriate, to the technical documentation.

  If the TC, after reviewing the source code and public information sources, is not able to resolve the issue, it will submit the issue to Microsoft much as it does today. New timing guidelines will apply in those cases where the TC's work requires a prompt response from Microsoft -- presumably, a subset of the current "high priority" technical documentation issues, where source code review does not provide a solution after a reasonable amount of time and investigation. In those cases, Microsoft will have 60 days to completely resolve the issue to the TC's satisfaction. This structure will minimize the cases where the TC's work is impeded by outstanding requests for information while allowing Microsoft sufficient time to engage in any necessary dialogue with the TC and to consult with the required technical resources to find the answer and to make the required improvements to the technical documentation.

  If, as we anticipate, there are a limited number of high priority issues that the TC cannot resolve independently, then the bulk of the technical documentation issues submitted by the TC will be subject to Microsoft's "best efforts" obligation, rather than to the 60-day time requirement or the SLGs currently in effect. However, Microsoft will report to the Court each month on the number of outstanding technical documentation issues and the number of issues that have been resolved. In this way, the Court will continue to have the information it needs to assess the progress of Microsoft's and the TC's work. Microsoft will also continue to respond to technical support requests from MCPP licensees and update the technical documentation as appropriate so that other licensees do not have to struggle with the same questions.

  Doesn't that sound to you like the Technical Committee is offering to write most of the documentation for Microsoft to approve? I guess they hope it will work better than the previous system, which has worked out so far like this:

  As described in Microsoft's January 17, 2006 report and Plaintiffs' January 23, 2006 response, the TC's prototype implementation project has continued to generate technical documentation issues that the TC reports to Microsoft. To date, the TC has submitted over 1000 issues to Microsoft. As of February 1, there were more than 700 issues that have not yet been closed. Approximately two-thirds of these issues are classified as medium priority, with the remaining issues fairly evenly divided between high priority and low priority issues. In roughly 110 of these cases, Microsoft and the TC have agreed on the required change to the technical documentation, and those changes need only to be published in the documentation released to licensees on a monthly basis. The remaining issues are at various stages -- being researched by Microsoft, awaiting further consideration by either the TC or Microsoft, or being discussed between the two for resolution. After an issue is closed in a manner that requires change to the technical documentation, the TC tracks the issue to make sure that the change appears in a monthly revision of the technical documentation. To date, over 200 issues have been resolved by Microsoft publishing changes to the technical documentation. These improvements in the documentation are already in the hands of licensees.

  In their January 23, 2006 filing, Plaintiffs expressed their concerns regarding Microsoft's performance under the SLGs and emphasized the need for Microsoft to significantly expand the resources devoted to responding to issues generated by the TC as quickly as possible. As described above, Microsoft's plan -- to make Windows server source code available to licensees to assist their development efforts, and to offer licensees both training and technical support -- is responsive to Plaintiffs' concerns. Accordingly, Plaintiffs are willing to modify the SLG approach, as outlined above.

  Here's how things stood in January, as set forth in the previous joint status report:

  First, while Microsoft's January 17 report describes various efforts that Microsoft is making to improve the speed with which it replies to technical documentation issues submitted by the TC, Microsoft has not detailed the seriousness of the current situation. In the substantial majority of cases Microsoft is no longer meeting the Service Level Guidelines ("SLGs") established to measure the timeliness of its initial response to technical documentation issues submitted by the TC. This reflects a substantial change from before the last Joint Status Report, when Microsoft was meeting the SLGs 100% of the time.(3) Since approximately mid-November, Microsoft has fallen significantly behind in responding to technical documentation issues submitted by the TC.

  Currently, Microsoft's inability to meet the SLGs interferes with the TC's ability to pursue its prototype implementation project and impairs the TC's ability to complete the project in a timely manner. It also means that MCPP licensees are receiving corrections or other edits to the technical documentation later than they would if Microsoft were complying with the SLGs. Microsoft has acknowledged the problem and described in its report the efforts it is taking to address the situation.(4) Microsoft needs to dramatically increase the resources devoted to responding to technical documentation issues in order to get its performance under the SLGs back on track. Until it does, the backlog grows day by day, as the number of technical documentation issues identified by the TC staff is not declining. Moreover, the TC anticipates that, beginning in the next quarter, its validation work will identify still more issues in the technical documentation that Microsoft will need to address. Although Microsoft and the TC agreed to suspend the SLGs during the holiday season, that brief moratorium is not the source of the problem.

  Microsoft's Annex 2, on the other hand, tells it like this:

  26. Throughout the remainder of 2004, Microsoft engaged in “a substantial effort to improve the technical documentation.” The TC played a constructive role in this process, meeting weekly with Microsoft staff, continually reviewing the revised documentation, and offering “suggestions for further improving the documentation.” This process culminated in the release of a new version of the documentation in early December 2004 that the U.S. agencies characterized as “a significant improvement over the original documentation.” ...

  30. From November 2005 through January 2006, as the TC increased its staff and expanded its validation work, Microsoft was unable to expand its staff rapidly enough to keep pace and provide timely responses. As a result, Plaintiffs noted that “Microsoft has fallen significantly behind in responding to technical documentation issues submitted by the TC.” Microsoft has responded to this concern by committing substantial resources to finding and hiring as many additional qualified documentation writers as necessary, as rapidly as Microsoft can find them. At a hearing on 14 February 2006 the District Court supervising Microsoft’s compliance with the Final Judgment directed Microsoft to continue to add the resources needed to keep pace with the issues submitted by the TC and Microsoft is committed to doing so.

  Let's get back to Microsoft's filings in February in the EU case.

• Annex 3: Finkelstein Report -- Prof. Anthony Finkelstein, Imperial College Consultants, London, UK, along with Prof. Jeff Magee Prof. Jeff Kramer Prof. Wolfgang Emmerich Dr. Holger Schwichtenberg, Lehrstuhl für Software & Systems Engineering Institut für Informatik Technische Universität München:

  0.3 We conclude that the interoperability information as provided by Microsoft meets current industry standards, particularly in such a complex domain. We believe that it has provided complete and accurate information, to the extent that this can be reasonably achieved, covering protocols, dependencies and implicit knowledge. We observe that the WSPP documentation goes significantly beyond what is 'on-the-wire' so as to assist skilled and knowledgeable software developers to develop a Work Group Server operating system that can work on an equal basis with Microsoft’s own products within the Windows domain architecture. There are of course further improvements and clarifications that can be made; it is standard practice that these are performed in response to user queries....

  0.8 The Trustee bases his criticisms of the WSPP documentation in significant part on the suggestion that the WSPP documentation should be “free-standing”. We argue that this makes no sense and, indeed, violates basic software engineering good practice [Sect 5]. We analyse how the documentation might be used and the support available both within and outside the WSPP. We then consider the quality of the WSPP documentation conclude that it is unreasonable to expect that the specification should be error free [Sect 6]. We consider the evidence presented in respect of the residual errors in the WSPP documentation. A further assumption made by the Trustee is that the WSPP documentation should be usable without prior knowledge of the Microsoft environment. We explain why this is wholly unreasonable [Sect 8].

• Annex 4: Broy Report -- Prof. Dr. Dr. h.c. Manfred Broy:

  To make interoperability information for Microsoft work group servers available in any practical manner, the only realistic approach is the pragmatic one Microsoft has taken:

  • provide technical documentation (Microsoft has provided more than 12,000 pages of such documentation) that addresses expert users who are experienced developers of client/server system software and familiar with the Microsoft network and programming environment,

  • anticipate that users of the documentation will take advantage of the large amount of information about Microsoft work group servers that is already in the public domain, and

  • provide live technical support from developers of the documentation to the users of the documentation as the documentation is used and issues with it arise. ...

  Looking at the size, the heterogeneity, the long standing history and all the side conditions, the Technical Documentation provided by Microsoft is certainly what is considered normal industry practice and what was in fact the best Microsoft reasonably could have been expected to do facing the complexity of the task. One has to understand that such a specification has to be iteratively improved over time and through use by developers.

• Annex 5: Hirst Report:

  My name is Roy Hirst. I am a Documentation Architect at Microsoft. I lead the team of over 25 documentation production experts that wrote the WSPP documentation....This Report shows an example of how a licensee engineer could use the WSPP documentation in conjunction with the available engineering art, including public standard protocols, in developing an implementation of work group server functionality equivalent to the relevant functionality of Windows servers....

  The example shows how to use the engineering art, how to relate the art to the WSPP documentation, and how to use the WSPP documentation. It shows the discovery of all the necessary information needed to understand the use of a field within the DRSBind packet in the Microsoft DRS RPC interface. There are 13 steps in this discovery....

  In summary, in this example, a licensee engineer:

  1. Uses the existing engineering art to evaluate his proposed implementation, and to determine a list of the protocols his implementation requires. A protocol is either a public protocol, a public protocol with Microsoft extensions, or a Microsoft proprietary protocol. See Section 1.

  2. Relates the art to the WSPP documentation by comparing his list of required protocols against the contents list of protocols licensed in WSPP. A protocol included in this contents list requires the use of the WSPP documentation and knowledge of the existing art to implement it; a protocol not in this contents list is implemented entirely from the existing art. See Section 2.

  3. Uses the WSPP documentation to implement those Microsoft extensions to public protocols, or those Microsoft proprietary protocols, required for his implementation. See Section 3....

  3 Using the WSPP documentation A licensee engineer uses the WSPP documentation to implement those Microsoft extensions to public protocols, or those Microsoft proprietary protocols, required for his implementation....

  8. The licensee engineer understands that the DRS protocol is an RPC interface. The WSPP documentation states that DRS is an RPC interface on the opening page of the WSPP DRS reference documentation. The page contains a link to a WSPP topic “Microsoft RPC” that explains the implementation of an RPC interface, including the use of an RPC binding request (RPC BIND)....

  The WSPP topic “RPC_BIND” contains a link to the contents page of the public standards documentation that defines in the art the use and meaning of an RPC BIND:

• Annex 6: Thatcher Report -- Jim Thatcher:

  1. This report describes industry norms for the development of software that interacts with distributed directory services systems. I have examined the structure and approach of the WSPP documentation to compare it to the documentation of complex network software products at Novell, with which I have substantial experience. Based on my experiences as an engineer at Novell, I conclude that the WSPP Documentation assumes a level of background experience and understanding that is consistent with what is required of software developers creating software based on Novell’s technical disclosures published in Software Development Kits (“SDKs”) and Application Programming Interfaces (“APIs”). ...

  6. I joined Microsoft in 2000 to work on interoperability between Microsoft and Novell products. Specifically, I managed the NetWare interoperability tools for Windows XP and Windows Server 2003, including the “Client Service for NetWare” (CSNW), which allows Windows PCs and servers to connect as clients to NetWare networks, and the “File and Print Services for NetWare” (FPNW) which allows NetWare client systems to connect to Windows Servers.

  7. I also acted as the primary technical contact with Novell to ensure that Novell software developers had the necessary information to enable their client software to work well on the new versions of Windows. I am currently a Senior Program Manager in Microsoft’s Standards Team advising and assisting Microsoft product groups in their engagements with industry standards setting organizations such as ITU-T, Ecma International, the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Systems (OASIS). ...

  11. It is consistent with my experience at Novell to expect developers interested in developing software to replace or interoperate with Windows servers to have experience using Windows, to understand Microsoft’s implementation of Active Directory and the SAM (including understanding the role of Domain Controllers), to be familiar with basic Windows security concepts such as Security Identifiers (SIDs), Discretionary Access Control Lists (DACLs), and System Access Control Lists (SACLs), and to understand Windows Remote Procedure Call (RPC) communications. It is essential that those lacking such fundamental understanding familiarize themselves with these concepts by reading the Microsoft Developer Network materials or other Active Directory programming papers and books in order to obtain the foundation necessary to understand the WSPP documentation. For companies whose business depends on interoperation with Windows systems it is very helpful and perhaps even indispensable that they invest in the low-cost MSDN subscriptions and attendance at Microsoft’s annual Professional Developers Conferences as Novell did.

• Annex 7: Criticisms Report:

  Microsoft Responses to Documentation Criticisms

  1. My name is Thomas Pfenning. I am a Software Architect in the Windows Division, and I have had this position since August 2004. I am assigned to provide architectural support for the technical documentation that Microsoft was ordered to submit pursuant to Article 5 of the 2004 Decision (the “Technical Documentation”). I received my Ph.D. in computer science in 1995 from the University of Cologne. Since that time, I have been a program manager for numerous server and networking products at Microsoft. The following set of responses to documentation criticisms is based on my background experience, my experience with the documentation, and information I received in the course of my involvement in the documentation program. ...

  5. The Trustee’s reports on which the Statement of Objections relies are based entirely on the documentation as of 23 November 2005. The Commission issued the Statement of Objections dated 21 December 2005 without obtaining any report from the Trustee on the adequacy of the 15 December 2005 documentation. ...

  C. Recurring Misunderstandings 9. Many of the specific criticisms are based on a few central misunderstandings. First, the Trustee and others fail to recognize that the documentation is intended for use by developers with skill in the art of developing interoperable work group server operating system products and familiarity with the products with which such products would be designed to interoperate. One of the Trustee’s primary criticisms of the Technical Documentation, as set forth in the Trustee’s Preliminary Report, is that “it assume[s] prior knowledge of the Microsoft environment.” 2 This criticism entails the proposition that it should be possible to design a successful software implementation of complex server operating system functionalities without any experience developing software in the relevant network and programming environment. No competitor would attempt such an effort, and if it did, no amount or quality of documentation could make the effort a success. ...

  11. The Trustee and others also fail to recognize that the Technical Documentation does not and should not provide complete documentation for an entire operating system product. Rather, it is designed to document those protocols needed to implement an interoperable work group server operating system product. Thus, some details, such as the format of particular data structures, are not described in the documentation because the operation of the protocol does not depend on those details. In such cases, to specify the details would be to impose unnecessary constraints on licensees, who would otherwise be free to make different choices in these regards without affecting the successful execution of the protocols. ...

  25. In claiming that the documentation “quite explicitly obfuscates some important details” 6 by using void pointers, the Trustee misunderstands the role of void pointers in the Technical Documentation. The Trustee asserts that a void pointer is “used where the programmer wishes to hide detail of implementation of particular data structures,” 7 but he is wrong to conclude from this that the documentation uses void pointers to withhold necessary information from licensees. On the contrary, the void pointer indicates that licensees are free to implement the relevant data structure entirely as they see fit and that the protocol imposes no restrictions on the format of the data structure. ...

  38. The Trustee’s claim that the documentation does not contain a “complete index” appears to be based on the Trustee’s inability to locate particular terms and concepts, such as “context handle,” in the index. The index, however, is designed to be useful to a developer skilled in the relevant art, in order to allow such a developer to quickly locate proprietary disclosures relevant to the developer’s task. The index is not designed to allow someone without the relevant knowledge to learn the necessary concepts from the documentation itself. Indexing such background concepts would be unlikely to help licensees, and might well be distracting to them. Any remaining instances of concepts not indexed can be easily addressed through a process of ongoing correction and support....

  40. The Trustee’s claim that the documentation contains insufficient explanatory memorandums is unsubstantiated. The Trustee claims that “the simplest concepts have been explained at great length, whilst the more complex topics have been treated -- in the best cases -- more cursorily.” 19 It is difficult to understand how the Trustee could have arrived at this conclusion....

• Exhibits to SO Response -- this collection of exhibits consists of emails from EU's Philip Lowe, who is Director General, Competition, Commission of the European Communities, in Belgium, to MS' Brad Smith, and back, such as this snip from October 1, 2005 email from Lowe to Smith (there are also also emails back and forth between Smith and Commissioner Neelie Kroes and a letter from Steve Ballmer to Lowe offering free technical support to licensees blah blah in the collection):

  "1. Completeness of the Documentation (note: still to be confirmed) * As mentioned during our conversation, we have very negative feedback on the completeness and accuracy of the documentation provided by Microsoft.

  If this feedback proves correct, we will have to take at least a preparatory step to formal action....

  3. Remuneration structure

  Problem: The current running royalty scheme acts as a strong disincentive to potential licensees ("tax" on their commercial success)....

  4. "Defensive termination clause"
  Problem: The "Defensive termination clause" (Section 4.2(b) of the "Patent Only" agreement) means that "Licensees" are forced to grant Microsoft a royalty-free license to all the patents coverying their implementation of the Microsoft protocols....

  5. No protection from third party IP challenges
  Problem: in case Microsoft protocols infringe third party IP, the "Licensee" has no protection against IP challenges by such third parties....

  6. Timing of the disclosure
  Problem: the documentation is made available within 30 days after service pack or first beta, whereas the Decision states that the documentation must be made avialable "as soon as the service pack or the new version are made available outside Microsoft Corporation for beta testing purposes"....

  7. Prohibition on reverse-engineering
  Problem: Section C of Exhibit C of the All IP Agreement provides that, in order to be deemed a "Compliant Channel Agreement", an agreement with a Channel Entity of the Licensee must prohibit reverse-engineering. This prohibition on reverse-engineering thus prevents Channel Entities to take advantage of a right that is expressly granted in the Software Directive....

  8. Presumption that any software from the Licensee that implements the WSPP Protocols is a "Licensed Server Implementation"
  Problem: The Licensee is presumed guilty until proven innocent....

  9. No predictability with regard to Vista (or Longhorn) Server
  Problem: The agreement covers only the protocols used in Windows 2003 Server (and previous versions). There is no guarantee that new protocols in Longhorn Server will be available under the same terms.

So there you have it. In connection with the concerns expressed in the exhibits, you might wish to read this article from 2002, where similar patent license concerns were raised:

According to the filing, Microsoft--by referring to the proposed settlement--was able to impose "uniform" licensing terms on PC vendors that, for among other things, gives Microsoft free access to their patents. These customers were precluded from enforcing their patents against Microsoft because of a "nonassertion of patents" provision in the licensing terms, the states claimed.

"Microsoft took advantage of the opportunities presented by the language (of the proposed settlement) to adopt significantly more onerous licensing terms and to impose those on the (PC makers)," the states said in the filing. Microsoft told PC makers that the patent provision was required by the settlement, the states said....

PC makers might reasonably have expected a net benefit in their relationship with Microsoft following a consent decree with the government, but every one of the world's top 20 PC makers believes that Microsoft has benefited from the proposed settlement at their expense, the states said....

Having free access to these patents would allow Microsoft to expand its hardware business and compete directly with the PC makers. Previously, Microsoft was limited in its ability to produce its own hardware based on the patents owned by the PC makers, the states said.