September 18, 2007
Send in the Clones
Posted by Bill Page
The CFI decision requiring Microsoft to disclose interoperability information for workgroup servers requires what amounts to a transfer of Microsoft’s intellectual property to its rivals in ways that the American Microsoft decisions have generally rejected. This post focuses on three features of the CFI decision that make this implication clear: its definition of interoperability, its treatment of Microsoft’s Active Directory, and its treatment of so-called “pure” server/server protocols. In each instance, the CFI claims not to require Microsoft to allow cloning of its software, but in practical terms, it does. In this post, I have relied heavily on analysis by my student and co-author, Seldon Childers, who was a software developer and management consultant for many years. (I apologize for the length of the post, but then it’s a very long opinion.)
In interpreting the CFI decision’s requirements, it is helpful to keep in mind what is meant by “disclosure” of communications protocols. One might think that a protocol is simply some lines of code that can be revealed along with a few pages of technical information. But the obligation of disclosure extends to assuring that rivals can achieve full interoperability. No disclosure is adequate until others (regulators and rivals) can use the disclosure to achieve interoperability. In practice, even in the implementation of the relatively limited U.S. communications protocol licensing requirement, this obligation entails extensive technical support, individual account managers, and one-on-one tutorials for licensees in how to implement the technology. Far more protocols are covered by the EC order. In implementing that order, a great deal of Microsoft’s expertise will be transferred to the licensees, including rivals. The net effect will be to facilitate cloning, in the sense of replicating (at much reduced expense) the proprietary functionality that Microsoft achieved through its R&D expenditures.
1. The Definition of Interoperability
This is the CFI’s description of the “range” of interoperability required (emphasis ours):
139. The Commission also recognises that there is a whole range of possible degrees of interoperability between PCs running Windows and work group server operating systems and that ‘some interoperability’ with the Windows domain architecture is already possible. It did not fix a priori a given level of interoperability which is indispensable to the maintenance of effective competition on the market but, following its investigation, it established that the degree of interoperability that competitors could achieve using the available methods was too low to enable them to remain viably on the market. . . .
140. In the rejoinder, the Commission contends that, in the contested decision, it does not conclude that it is indispensable that Microsoft's competitors be allowed to reproduce its 'interoperability solutions'. What matters is that they are able to achieve an equivalent degree of interoperability by their own innovative efforts.
In practice, however, the test is whether the rival can achieve the requisite degree of interoperability regardless of how much it has to innovate. The test is “functional equivalence”:
140. [T]he Commission stated at the hearing that it was necessary to distinguish the concept of 'functional equivalent' from that of 'functional clone'. A 'functional equivalent' is not a system operating identically to the Windows work group server operating system which it replaces but rather a system that can provide the appropriate response to a specific request under the same conditions as that Windows operating system and can make a Windows client PC or server react to its messages in the same way as if they came from that Windows operating system.
This is apparently also what the commission and the CFI mean by “two-way” interoperability (¶ 226)—the disclosure must be sufficient to allow the licensee’s product not only to do what it was designed to do within a network, but everything that Microsoft’s products do. In later passages, the CFI describes and endorses the commission’s distinction between “specifications” and “implementations.” (¶¶ 199-200). Thus, Microsoft need only disclose the specifications of the functionality that the protocol permits, not its own implementation of that functionality. The licensee, then, must use the specifications to “innovate” and create its own implementation.
But, given the definition of interoperability that the commission and the CFI adopt, this requirement amounts to a requirement that Microsoft facilitate cloning. As a practical matter, Microsoft will be required to assure that the user achieves “interoperability” in the sense of duplicate functionality, and this will only be possible by reverse engineering based on the disclosures. The rival may also innovate, but with the advantage of Microsoft’s investment and tutorials. If the rival fails to innovate, the implication will be that the level of disclosure is too low.
2. Active Directory
Under the CFI decision, Microsoft must disclose the interoperability information required to make full use of Microsoft’s “Kerberos” Active Directory services. Active Directory is the security protocol used to verify user access to files and network resources. This function is critical because of the importance of security in general and because of the technical problems posed by larger networks that include multiple servers which have to negotiate with each other while only requiring the user to login a single time. Novell Netware had one solution, and Microsoft (presumably with enormous investment) came up with Active Directory, which is an arguably superior technology. The Active Directory technology represents Microsoft’s main innovation in server technology and what distinguishes its server software from, including the open-source (free) Samba project, which does everything but a full implementation of Active Directory.
Here are a few paragraphs of the opinion on the Directory Services issue. Notice that the CFI dismisses Microsoft’s proprietary interests in its own product.
190. . . . Microsoft itself observes in the reply that on that market 'the directory service is a key competitive feature responsible in large part for the success of particular products' and emphasises, in particular, that 'Active Directory is ... at the heart of Windows server operating systems', after stating that '[f]or both file and print services and user and group administration services, it [is] important to know with precision which user [is] entitled to access which network resources'.
191. Active Directory logs all network object information and allows it to be administered centrally. It fully integrates administration and user authentication and access control functionalities and thus ensures the security of the information. In addition, Active Directory uses the multi-master replication mechanism.
. . .
195. Thus, in Article 1(1) of the contested decision, [the commission] defines 'interoperability information' as 'the complete and accurate specifications for all the protocols [that are] implemented in Windows work group server operating systems and that are used by Windows work group servers to deliver file and print services and group and user administration services, including the Windows domain controller services, Active Directory services and Group Policy services, to Windows work group networks'.
233. In the light of those various factors, the Commission maintains, in particular, that a server running a non-Microsoft work group server operating system must be capable of acting as a domain controller, and not merely as a member server, within a Windows domain using Active Directory and, accordingly, be capable of participating in the multimaster replication mechanism with the other domain controllers.
234. The Court finds that, contrary to Microsoft's claim, it cannot be inferred from the degree of interoperability thus required by the Commission that the Commission intends in reality that non-Microsoft server operating systems must function in every respect like a Windows server operating system and, accordingly, that Microsoft's competitors must be in a position to clone' or 'reproduce' its products or certain features of those products.
But for Microsoft to assure that a rival’s server can act as a domain controller using Active directory, it will be required to assist the rival in cloning that functionality.
Microsoft argued (¶ 262) that “in order for a domain control running under a non-Microsoft work group server operating system to be capable of being placed in a 'blue bubble' composed of domain controllers using a Windows work group server operating system employing Active Directory, those different operating systems must share the same internal logic.” The court responded:
263. First, Microsoft fails to demonstrate that, in order to function together within the 'blue bubble', its work group server operating systems and those of its competitors must necessarily have the same internal logic.
264. Second, the applicant also fails to demonstrate that even if such identity of internal logic were required, this would necessarily mean that Microsoft had to communicate to its competitors information relating to the internal mechanisms of its products and, in particular, to the algorithms. . . .
265. Third, as regards the 'Intersite Topology' algorithm which Microsoft mentioned specifically at the hearing, it is quite possible that, as the Commission also submitted at the hearing, competitors need only be in a position to implement an algorithm giving the same result as that algorithm. In other words, Microsoft would not be required to give any information about the implementation of that algorithm in its work group server operating systems, but could merely give a general description of that algorithm, leaving it to its competitors to develop their own implementation of it.
This is cloning. The CFI’s logic fails to recognize that Microsoft’s disclosures and “descriptions” will be considered inadequate until the competitors have reverse engineered the algorithm.
3. “Pure” Server/Server Protocols
The CFI opinion requires Microsoft to disclose pure server/server protocols.
220. In the Windows work group server networks, client/server and server/server interoperability are closely interlinked and, in order that full interoperability can be achieved between a Windows client PC and a non-Microsoft server operating system, Microsoft must give access both to the client/server communication protocols and to the server/server communication protocols (recitals 177 to 182 and 689 to the contested decision), including those which are 'pure' server/server protocols, that is to say, protocols which are not implemented on the client PC which are but 'functionally related to the client PC’ (recitals 277, 567 and 690 to the contested decision).
221. The Commission denies that the contested decision envisages that Microsoft's competitors should develop products functioning in all respects like a Windows server operating system. In fact, the decision is intended to enable 'competing products [to] be created that w[ould] function differently, whilst being able to understand the messages conveyed by Microsoft's relevant products'. Thus, the interoperability information at issue will be used by Microsoft's competitors not to develop exactly the same products as Microsoft's, but to develop improved products, with 'added value'.
It is entirely possible that Microsoft’s competitors will be able to add value. But they will be enabled to do so by disclosures that reveal Microsoft’s innovative efforts. The court adds the following remarkable assurance:
242. Furthermore, as will also be explained in greater detail at paragraph 658 below, when the Court examines the circumstance relating to the new product, Microsoft's competitors would have no interest in developing exactly the same work group server operating systems as Microsoft's.
658. Nor would Microsoft's competitors have any interest in merely reproducing Windows work group server operating systems. Once they are able to use the information communicated to them to develop systems that are sufficiently interoperable with the Windows domain architecture, they will have no other choice, if they wish to take advantage of a competitive advantage over Microsoft and maintain a profitable presence on the market, than to differentiate their products from Microsoft's products with respect to certain parameters and certain features. It must be borne in mind that, as the Commission explains at recitals 719 to 721 to the contested decision, the implementation of specifications is a difficult task which requires significant investment in money and time.
It apparently does not occur to the CFI that competitors, given free access to the fruits of Microsoft’s R&D, would have a very strong incentive to compete with Microsoft on price alone. Because their “significant investment” would not approach Microsoft’s, their cost advantage would be substantial.
September 19 Update:
When I say in this post there is a danger that the remedy will facilitate "cloning," I do not mean an exact, instruction-for-instruction copy of Microsoft's code. I mean the term in the sense Judge Kollar-Kotelly used it in New York v. Microsoft Corp., 224 F. Supp. 2d 76, 175-76 (D.C. Cir. 2002), aff'd sub nom. Massachusetts v. Microsoft Corp., 373 F.3d 1199 (D.C. Cir. 2004):
"By cloning, the Court means the creation of a piece of software which replicates the functions of another piece of software, even if the replication is accomplished by some means other than the literal repetition of the same source code. In most instances, where a clone is created without a copyright violation, the clone emerges from a process of reverse engineering-which consists of the study of functionality in the original product and the attempt to produce a product which accomplishes the same end. The process of cloning the functionality of a competitor's product is usually an expensive and time-consuming undertaking which, if successful, will enable the cloned product to function as a replacement for the original product. To impose a remedy which facilitates the cloning of Microsoft's products-a far simpler task than the creation of a new product-would provide a windfall to Microsoft's competitors."
September 18, 2007 | Permalink
TrackBack URL for this entry:
Listed below are links to weblogs that reference Send in the Clones:
Kerberos was first developed at MIT. The protocol and reference implementation were released as open source.
Kerberos is freely available from MIT, under copyright permissions very similar those used for the BSD operating system and the X Window System. MIT provides Kerberos in source form so that anyone who wishes to use it may look over the code for themselves and assure themselves that the code is trustworthy.
Although the Kerberos trademark was abandoned, all the same, your reference to Microsoft "Kerberos" is misleading and, imho, unworthy of a scholar, unless you make clear that it's in the context of a particular vendor's Kerberos implementation.
A lot of people know the history here.
Posted by: nedu | Sep 18, 2007 5:12:56 PM
My lone reference to Kerberos was to "Microsoft’s 'Kerberos' Active Directory services." I think that makes clear I was referring to Microsoft's extension of the Kerberos standard. I did not intend to slight MIT or to credit Microsoft for the standard. The CFI, incidentally, makes the distinction and credits MIT (para. 170). Thanks for the links.
Posted by: Bill Page | Sep 19, 2007 8:48:46 AM