Northwestern University Law Review : Colloquy : 2008 : Page & Childers
Bargaining in the Shadow of the European Microsoft Decision: The Microsoft-Samba Protocol License
[Editor's Note: This week, we are pleased to present Professor Page's and Mr. Childers's Article on the Microsoft-Samba Protocol License. Part I appears today. Part II of this Article will appear later this week.]
On March 24, 2004, the European Commission (EC) held that Microsoft had abused its dominant position under Article 82 of the European Community Treaty by, among other actions, refusing Sun Microsystems' request for information that Sun needed to interoperate with Windows workgroup server products The EC ordered Microsoft to disclose "complete and accurate specifications for the protocols used by Windows work group servers in order to provide file, print, and group and user administration [i.e., directory] services to Windows work group networks." On September 17, 2007, the European Court of First Instance (CFI) affirmed the EC's liability ruling and its remedial order. About a month later, Microsoft's CEO, Steve Ballmer, reached an agreement with the head of the EC's competition authority, Neelie Kroes, on the terms under which Microsoft would license the protocols. In December 2007, with the active encouragement of the EC, Microsoft reached a licensing agreement for the covered protocols with Samba, an open-source development project that produces server software that emulates the behavior of Microsoft's server operating systems. The parties have begun to implement the agreement.
The Microsoft-Samba agreement is by far the most important tangible outcome of the European Microsoft case. The EC's other remedial order in the case, which required Microsoft to create a version of Windows without Windows Media Player, was an embarrassing failure. Immediately after the Ballmer-Kroes agreement, some anticipated a similar fate for the remedial order addressing Microsoft's refusal to supply rivals in the workgroup server market. The Samba agreement, however, is significant because it requires Microsoft to provide, to its most important rival in the server market, detailed documentation of its communications protocols, under terms that allow use of the information in open-source development and distribution. There is good reason to believe that Samba will be able to use the information to compete more effectively with Microsoft because Samba's development methods depend specifically on analysis of communications protocols. In a closely related development, Microsoft has now published all of the covered protocols on its website. While these actions will certainly enhance interoperability, they may also facilitate cloning and thus devalue Microsoft's intellectual property. Thus, it remains unclear whether the license will enhance or inhibit dynamic, innovative competition in the long run.
In this short Article, we assess what the Microsoft-Samba license might mean, both for the market and for antitrust policy. In doing so, we rely on published sources and on interviews with some of the key players in the negotiations. On the Microsoft side, we spoke to David Heiner, Microsoft's lead in-house antitrust counsel, and to Craig Shank, its lead negotiator for the Samba license. On Samba's side, we spoke to Eben Moglen, a professor at Columbia Law School, whose Software Freedom Law Center provided legal representation for Samba. In Part I, we briefly describe the function of servers and communications protocols in computer networks. We then discuss the special significance of the Samba project in the server market. Part II summarizes the reasoning of the EC and CFI in the workgroup server side of the European Microsoft case. Part III describes the negotiations that produced the agreement and spells out the terms of the resulting license. In Part IV, we consider the possible implications of the license and the disclosure process for Samba, Microsoft, and competition policy.
I. Servers, Protocols, Microsoft, and Samba
Most organizations and businesses of any size maintain computer networks in which server computers perform tasks for users of linked client computers. Both the server hardware and the client hardware are typically manufactured by vendors like Dell, IBM, or HP. In some networks the servers and clients run operating systems from a single vendor, but in most, the servers run a variety of operating systems while the clients run some version of Windows. Communications protocols allow the computers on all of these networks to interoperate. They provide rules that govern what, when, and how information is transmitted between servers and client computers as well as between different servers within the same network. Some protocols are industry standards and can be used to implement a variety of functions; others are tailored to the specific needs of the server's underlying functionality. The protocols thus amount to a language that allows users to request and receive a variety of services, including printing, saving on a network drive, displaying Web pages, and sending and receiving email. The language also enables the servers on the network to perform "directory services," that is, essential authentication and security functions.
In the mid 1990s, Novell was the leader in software that performed the file and print sharing functions of corporate networks, while Unix servers, often on the same network, typically controlled other applications like databases and email. Microsoft's server products began to gain a larger share of these markets during the 1990s and have now achieved substantial, if not dominant, shares in some segments. Microsoft's Active Directory, which controls directory functions, is one of Microsoft's most distinctive and innovative server technologies and was the focus of Sun's original demand for what the EC later called "interoperability information."
Today, the most important non-Microsoft technology in the server market is Samba, which emulates the behavior of Windows server products, but runs on Linux, a widely adopted open-source server operating system. Samba is available under version 3 of the GNU General Public License (GPLv3). It allows a variety of Unix-based and Linux-based operating systems to connect to Windows clients and servers. Significantly, however, the Samba project has not yet been able fully to emulate Active Directory. This shortfall became a key issue in the EC's liability ruling and in the remedial discussions, which we discuss below.
Because of its origins and characteristic methods of development, Samba is in a better position than most of Microsoft's rivals to benefit from the EC's remedial order. In 1991, Andrew Tridgell, a computer science Ph.D. student at the Australian National University, wanted his MS-DOS workstation to connect reliably to a Digital Equipment Corporation (DEC) server. By writing code that "spied" on the communications between the server and clients, Tridgell discovered that the DEC server was using a freely available standard industry configuration known as SMB over Netbios. With this knowledge, he was able to write and implement the first predecessor of Samba, which he posted on a few bulletin boards and newsgroups. In the process of uncovering the protocols, Tridgell began to develop the skills in network packet decryption that are the foundation of the Samba project. Two years later, Tridgell adapted his software to provide SMB/Netbios services on Linux. Tridgell's server management system was ideally suited to Linux because it allowed connection from other Unix and MS-DOS workstations. The software that would later become known as Samba began to accompany most Linux distributions.
Jeremy Allison of Great Britain joined Tridgell's project in 1993 and others followed. The team continued to use Tridgell's development methods to map Windows client and server communications, a process that was simplified by the fact that Microsoft's server products also spoke the industry-standard SMB/Netbios. Once the Samba source code was placed into a popular open-source code repository, development accelerated. The Samba team devoted significant resources to building competent online documentation. As a result, the solution rapidly became the essential workgroup server solution in almost every Linux distribution and Linux-based network device.
Samba is now the de facto standard for most non-Microsoft network-enabled products, and not only computers. Because Samba is free, firms using it can sell devices more cheaply than if the maker were required to purchase a license for Windows and Windows server for each unit sold. Samba also offers permissive licensing terms, ease of installation and configuration, compatibility with Linux/Unix, and access to Samba developers for support. Most important, because Samba is open source, device makers who need a particular feature added to Samba to make their device work properly can make the change to the Samba software itself.
Obvious benefactors of the Samba project are Microsoft's major competitors in the workgroup server market, including IBM, Apple, Sun, and Novell, all of which now use Samba as the engine for their proprietary workgroup server solutions. All add proprietary extensions that provide additional features and tools for managing the network. Their solutions are automatically compatible with Windows-based networks. Because they start with a complete networking solution, they can focus their significant resources on value-added features. In return, these competitors support the Samba project by employing key members of the Samba team to continue their open-source work on a full-time basis. Tridgell is currently employed by IBM. Jeremy Allison has worked at HP and Novell and is currently at Google, with the remarkable title of "Linux Evangelist."
Thus, Samba is both a clone of Windows server products and something more. It is a distinctive technology with a host of features, some of which are inferior to the corresponding features of Microsoft's server solutions, and some of which are superior. Samba has fueled a significant sector of the technology economy and has enabled the development of entirely new categories of devices.
II. The European Microsoft Decision, Protocol Licensing, and Samba
Microsoft has instituted protocol licensing programs under both the American and European antitrust remedies, but Samba has obtained a license only under the EC program. The different outcome stems from the broader goals of the EC program in the server market. In this Part, we first distinguish the goals of the two remedial programs, then examine the European rulings on refusal to supply, and finally describe the agreement between Neelie Kroes and Steve Ballmer on the terms under which Microsoft must license its protocols.
A. Two Approaches to Regulating Interoperability
The U.S. program has been an enormous undertaking for both Microsoft and government enforcement officials. It has resulted in greatly improved documentation of Microsoft's protocols, particularly after a critical "reset" of the program in the spring of 2006. The process, however, has been extraordinarily difficult, with little apparent benefit to rivals or competition. Part of the reason for the program's scant results has been its limited rationale, which stemmed from the theory of the government's case. Because the American case focused on Microsoft's efforts to thwart the "middleware threat" posed by Netscape's browser and Sun's Java technologies, the protocol remedy was only designed to foster the emergence of middleware on servers that would rival the Windows client operating system as a platform. Thus, the judgment was not intended directly to benefit producers of rival server operating systems. It did not, for example, require the licensing of protocols used for server-to-server communications, which would be necessary for the Samba project. Moreover, because the U.S. decree recognized that Microsoft is entitled to charge a license fee for its software patents, it was not, in its original form, useful to open-source developers like Samba, which reject software patents.
The "refusal to supply" portion of the EC's case, by contrast, was focused on competition among server operating systems from the outset. The case arose out of Microsoft's refusal of Sun Microsystems' 1998 request for detailed specifications of Microsoft's then-new Active Directory technology. Samba made only a cameo appearance in the EC's 2004 liability ruling. By the time the case reached the Court of First Instance, however, Sun and some other rivals of Microsoft had reached settlements with Microsoft that took them out of the proceedings, while Samba technology had become the core of the server products of many of Microsoft's rivals. Thus, both the arguments before the CFI and the implementation of the order addressed Samba and its inability (yet) to function as a domain controller performing Active Directory functions. As a result, representatives of the Free Software Foundation, including Tridgell, Allison, and Volker Lendecke (a German Samba developer) played a more active role in the appeal than they had in the original investigation.
B. The EC Liability Ruling
Under EC law, a dominant firm may be required to supply rivals in exceptional circumstances. Applying this standard, the EC held that Microsoft had abused its dominant position by refusing to supply Sun with "interoperability information." Sun had asked Microsoft for "the complete information required to allow [Sun] to provide native support for the complete set of Active Directory technologies on [Sun's Unix-based operating system] Solaris."The EC and the CFI held that Microsoft's refusal to provide certain interoperability information to Sun—essentially the communications protocols related to Active Directory, a subset of the broader category of information that Sun had actually requested—constituted exceptional circumstances.
Among other reasons for this result, the EC and CFI found that Microsoft had "disrupted its previous levels of supply" of this interoperability information and the information was necessary for rival firms to compete. Both of these assigned reasons were linked to Active Directory. Microsoft had never given anyone detailed interoperability information for Active Directory. It had, however, disclosed Windows source code to help AT&T develop Advanced Server/Unix (AS/U), which allows a Unix server to emulate a Windows NT server. Windows NT, however, was an earlier technology that included only early versions of directory services, not Active Directory. Microsoft decided not to update the AS/U license to include Active Directory technology because Active Directory was its primary competitive advantage over other server operating systems. This choice, according to the EC, departed from Microsoft's earlier policy of interoperation, and thus cast suspicion on its decision not to give Sun the interoperability information for Active Directory. In support of its finding that access to Microsoft's protocols was necessary for rivals to compete, the EC pointed to Samba's inability to emulate Active Directory.
One of the most hotly contested issues in the CFI proceedings was whether the disclosures the EC ordered would result in cloning of Microsoft's proprietary technology, particularly Active Directory. The EC demanded sufficient disclosures to allow rivals to achieve functional equivalence with Microsoft's software, including the ability to function as a "domain controller" for Active Directory services, a server that controls authentication for the network. This goal, the EC insisted, would not allow rivals "to reproduce [Microsoft's] 'interoperability solutions' [but only to] achieve an equivalent degree of interoperability by their own innovative efforts." Microsoft need only disclose the "specifications" of the functionality that the protocol permits, not its own "implementation" of that functionality or its source code. If disclosures of the specifications allowed the rival to "implement . . . support for the protocols underlying the Windows domain architecture," doing so would involve significant "time and effort." To be competitive, the licensee would have to use the specifications to "innovate" by creating a novel implementation of the Microsoft server feature set, presumably resulting in advantages. The EC reasoned, "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.'"
In response to this reasoning, Microsoft advanced what became known as the "blue bubble" argument. In the hearings before the CFI in 2006, John Shewchuk, a senior Microsoft Engineer, argued that servers called domain controllers, which perform certain integrated operations related to Active Directory, must not only use the same communications protocols, but must have the same internal algorithms. He illustrated this point with the diagram below, in which a blue bubble encloses the domain control servers.
Image 1: Microsoft's diagram illustrating the "blue bubble" argument before the Court of First Instance.
Active Directory uses a technique called "multi-master replication," which allows hundreds of domain controllers (or master directory servers), distributed in a network that may span continents, to synchronize their operations by exchanging updates through the most efficient routes using server-to-server protocols. To accomplish this function, however, each server must independently build and continually update a map or topology of the network. According to Shewchuk, only domain controllers with the same internal logic can make efficient assumptions about what other Active Directory servers will do when, for example, one server fails and the others must pick up its functions. Consequently, merely disclosing the protocols and specifications that servers within the blue bubble use would not allow a non-Microsoft server to function as a domain controller, as the EC required; Microsoft would have to disclose its proprietary algorithms. As Shewchuk put it, "[i]n order for me to have someone work with me inside the service boundary, they would need to have this same algorithm. That would mean I would have to explain to them how to create this map when they saw this information."
Tridgell responded at the hearings that "[w]hat the blue bubble represents is a bubble of secrecy. The protocols used inside that blue bubble are exactly the same in nature as the protocols used in other parts of Microsoft's Active Directory infrastructure." Because of the ubiquity of Active Directory on large corporate networks, the secrecy of its protocols gives Microsoft "a massive amount of leverage over its competitors." By implication, Tridgell claimed that Samba could achieve the necessary level of interoperability by protocol analysis alone. Samba co-founder Jeremy Allison has said that the Samba project has never reverse-engineered any Windows code but has used across-the-wire network protocol analysis to implement unique work-alike code. Evidently, the Samba team believes it can emulate Active Directory domain control functions using the same techniques.
The CFI found that Microsoft had failed to prove that the mandated disclosures concerning Active Directory would require it to facilitate cloning, in the sense of a detailed copy of its implementations. It qualified that conclusion, however, by observing that "Microsoft would not be required to give any information about the implementation of [the inter-site topology] algorithm in its work group server operating systems, but could merely give a general description of [the] algorithm, leaving it to its competitors to develop their own implementation of it." This "general description" exception has potentially radical implications for the implementation of Samba license. As we show below, Microsoft has sought to comply with this provision by disclosing "Windows behaviors" associated with each protocol.
Remarkably, the CFI also asserted that a rival server company would have no "interest in merely reproducing Windows work group server operating systems":
In offering this argument, the CFI seemed to have ignored Samba, which maintains its presence in the market without profit. Were its products to achieve perfect functional equivalence with Microsoft's, they would sweep the field because Microsoft's products have a positive price and Samba's are free.
C. The Kroes-Ballmer Settlement
Particularly in the latter stages of the European case, it became clear that a primary goal of the EC was to require Microsoft to offer a license that open-source developers could use. On October 22, 2007, about a month after the decision of the Court of First Instance, the EC's antitrust commissioner, Neelie Kroes reached an agreement with Microsoft's CEO Steve Ballmer that would require Microsoft to license its intellectual property, other than patents, for a nominal one-time fee of €10,000, and its patents for modest per-unit royalties. On October 24, 2007, Microsoft posted revised licenses for interoperability under its WSPP Development Agreements to reflect the Kroes-Ballmer agreement. Commentators and members of the free and open-source community complained, however, that the terms were still incompatible with the GPL, the standard open-source license employed by Samba and many others. Because competitors and open-source developers of workgroup server products generally rely on the Samba engine and the GPLv3 license, they regarded the new WSPP license as useless. Furthermore, they argued that the €10,000 flat fee and particularly the royalty-bearing patent license would discourage use by small free and open-source development teams, which typically have no operating budget. Members of the Samba team were also concerned about potential liability for patent infringement. Because of all these concerns, the Free Software Foundation and Samba complained to Microsoft about the new terms.
Microsoft agreed to enter a new round of negotiations in order to make the WSPP license terms more amenable to free and open-source projects. These negotiations were initially brokered by EU trustee Neil Barrett, who introduced the free and open-source parties to Craig Shank of Microsoft. Barrett's mediation efforts were important, but raised questions because the CFI decision had held that the EC's reliance on an expert trustee to implement the agreements was inconsistent with EC law. Neither Microsoft's representatives nor Samba's could fully explain to us how Barrett remained in place. Evidently, however, the EC interpreted the CFI's decision as restricting only the trustee's remuneration and some other formal aspects of his relationship to the commission. Whatever the reason, Barrett facilitated the negotiations that eventually produced the Microsoft-Samba agreement.
III. The Microsoft-Samba Agreement
On December 20, 2007, the Protocol Freedom Information Foundation (PFIF) and Microsoft Corporation agreed (the WSPP/No Patents agreement) that Microsoft would license, on terms friendly to open source developers like Samba, all of the protocols disclosed under the ongoing American and European protocol licensing programs. The Software Freedom Law Center (SFLC) created the PFIF as a nonprofit Delaware corporation to hold the master license and to license the documentation to free or open source developers. The PFIF paid Microsoft a one-time royalty fee of €10,000. The agreement provides a royalty-free copyright and trade secret license permitting liberal use of the protocols and documentation, subject to confidentiality and non-disclosure restrictions. In this Part, we describe the negotiations and the terms of the agreement from the perspectives of both sides.
A. Negotiating in the Shadow of the CFI Decision
In Microsoft's view, the CFI decision meant the arguments about disclosures were "over" and Microsoft was bound to comply. The agreement between Ballmer and Kroes, if not unconditional surrender, was a capitulation with only minimal concessions from the EC for the protection of Microsoft's most basic intellectual property. One indication of how Microsoft viewed the matter was its appointment of Craig Shank, an experienced transactional lawyer and business development executive, to head the negotiations. Shank took it as his goal to comply, despite the tension between the EC's requirements that Microsoft disclose (a) only the specifications of its protocols, yet (b) enough to allow a rival server to function exactly like a Microsoft server within the blue bubble. Thus, Shank was prepared to disclose more than the specifications to the extent necessary to achieve the requisite degree of interoperability.
According to Samba's attorney Eben Moglen, Samba took a very different view of the negotiations. The Samba team was disappointed by the EC's haste to "cash in" its CFI victory for the seeming political gain of a deal with Microsoft, and resented the pressure it placed on them to come to terms. They disagreed particularly with Kroes's decision to allow Microsoft to charge a running royalty for its software patents. The Samba team is ideologically opposed to software patents, a view not shared by the intellectual property section at the EC, which regards patents as essential to innovation. Despite Samba's reservations about the terms of the Kroes-Ballmer settlement, its engineers still believed that the disclosures would be extraordinarily useful to them in protocol analysis. However, they also feared that the EC at some point would lose interest in Microsoft's actions in the server market and become less willing to insist that Microsoft come to terms. These factors all placed pressure on Samba to reach agreement on a license.
Negotiations began in mid-October. The initial drafts of license agreements that Samba reviewed were based on the Workgroup Server Protocol Program license that Microsoft had created under EC regulation, but that the EC staff had redlined in an effort to comply with GPLv3. This approach, Moglen believed, produced drafts that were slanted in Microsoft's favor and that included inapplicable royalty schedules and incomplete attachments, all of which hindered the negotiation process. Nevertheless, the EC made clear that it wanted the Samba team to reach a deal with Microsoft by Christmas. The pace of the negotiations picked up when Tridgell proposed to Barrett and Shank that Samba's engineers speak directly to their engineering and business counterparts at Microsoft. Moglen was surprised to find that Microsoft's engineers and its protocol licensing team were both willing to talk and remarkably forthcoming. Tridgell and Shank (in his business capacity) then conducted discussions as lead negotiators, with the lawyers staying out of the way to the extent possible. The engineers overcame some sticking points and proposed terms streamlining administration of the disclosure process. Interestingly, Microsoft's competitors became aware of the negotiations, and contacted Moglen to lobby for terms they wanted to see incorporated in the deal. Samba's negotiators, however, tried to remain independent.
B. The Terms of the Agreement
The December 20 final agreement permits free open source developers, through the PFIF, to gain access to the relevant WSPP documentation subject to the agreement's non-disclosure terms. Tridgell identified several terms as being of particular importance to the Samba team: patent exclusions, quick expiration of non-disclosure agreements (NDAs), and exception of source code comments from NDA liability.
Like the original WSPP/No Patents agreement, the Samba license does not grant licenses to any of Microsoft's patents. The GPLv3 requires any code distributed under that license to be entirely free of patents, or to provide a patent license compatible with the GPL. Since Samba is licensed under the GPLv3, it was essential that the Microsoft license provide some means of avoiding infringement. The Samba team was particularly worried that their development efforts would infringe unknown patents, which Microsoft could then use to block distribution. To their surprise, however, Microsoft was willing to list, as an appendix to the agreement, all of the patents it claimed in the licensed information. Microsoft agreed not to sue any Samba licensee or end-user for infringement of an unlisted patent on account of their development, use, or distribution of the portions of Samba that implement the licensed protocols. The provision allows Samba, by successfully designing around all of the patents shown in the appendix, to comply with the GPLv3 and to guarantee its users freedom from potential infringement liability for their use of the covered portions of Samba. Craig Shank described this aspect of the agreement as the "patent map," part of an overall package of solutions to patent issues for both open source developers and commercial developers. The package includes the patent map, the stand-alone patent license, and Microsoft's "noncommercial patent pledge." While the patent exclusion may make the license less helpful to some developers, the Samba team members actually expressed a preference to avoid using patented software entirely by designing around it. In a recent podcast interview, Jeremy Allison described software patents as "pure evil," but also usually "pure rubbish" and easy to design around. Faith in the ability to design around patents appears to be a core element of open source ideology.
There were also two concerns about the effects of the non-disclosure agreements. First, the Samba team was concerned that potential licensees would be dissuaded from taking advantage of the program because of fears that non-disclosure limitations would diminish their employment opportunities. As a result, the new licensing terms provide for the expiration of those non-disclosure requirements addressing information that a developer "retain[s] in unaided memory," three months after he or she discontinues using the WSPP information. Second, the NDA provisions as originally drafted would have forbidden reproduction of the disclosure information. The Samba team thought this requirement might restrain developers' ability to include comments in their source code explaining how the code works because of fears that the comments might later be found to violate the NDA. Comments are important to open source development because they can provide useful information about the code in natural language, and thus allow the loose network of open source developers to communicate. The final revision of § 5.8 of the agreement excludes source code comments from liability under the NDA.
IV. Consequences of the Samba License
It is too early in the implementation of the disclosure process to say with certainty what effects it will have on the parties and competition. There is reason to believe, however, that this license will be more consequential than any implemented under the U.S. final judgments. Both parties to the agreement may benefit in some respects. It is also likely that the new protocol information will improve interoperability. But the longer-term consequences of the disclosures are less clear. If the disclosures are limited to "specifications" of protocols and general descriptions of Windows functions, they may not allow Samba to achieve functional equivalence within the blue bubble, as the EC and the CFI anticipated. If, on the other hand, the disclosures go beyond any reasonable definition of specifications in order to permit that level of interoperability, the program may facilitate cloning and thus the devaluation of Microsoft's core intellectual property. In this section, we consider the implications of the program for each of the parties and for antitrust policy.
As we have explained at greater length elsewhere, the documentation of protocols under the U.S. final judgments has been an arduous process, with few apparent benefits in the market. Nevertheless, those most closely involved in that process agree that the quality of the documentation of the protocols after the watershed "reset" in the spring of 2006 has markedly improved. The Technical Committee continues to test that documentation by developing its own prototype implementations, but Microsoft asserts that the documentation is already sufficient for any practical commercial development by its licensees.
Samba may stand to benefit from protocol disclosures more than any other company because its methodology depends on protocol analysis and test-driven development. According to Samba co-founder Jeremy Allison, Samba's development methods differ from those of Microsoft. Samba begins by developing client-side code, which it uses to test against Windows server products to ensure that the implementation is correct. When the client code tests properly, the Samba team uses it to develop and test a server implementation that behaves exactly like a Windows server product. Samba uses network protocol analysis to define an accurate set of specifications that its server products must meet. Samba thus has a development advantage over Microsoft in that it has the Windows server as a known benchmark. Samba's test-driven development can focus on the purely functional aspects of the software.
Samba's development methods should allow the Samba team to take full advantage of Microsoft's disclosures. Allison says a Microsoft engineer once warned him, "the worst thing we could do is dump our documentation on you because then you'd be as confused as we are." Nevertheless, Allison said the Samba team looks forward to receiving the documentation, particularly now that the documentation has been improved by the reset process under the U.S. enforcement program. Upon receipt of the documentation, Allison said, the Samba team will begin to write client-side tests against the disclosed protocols. Once complete, they will run those tests against Windows servers to prove the accuracy of the disclosed protocols. They will report to Microsoft any problems encountered in implementing the client-side test suites as errors in the documentation. Once the client-side test code is running properly against a Microsoft server, the Samba team will either run it against a Samba server (in the case of already-implemented protocols) or write server-side code for that protocol, which they can then test against the client-side test suite. An iterative process of rewriting, bug-fixing, and re-testing will occur until the Samba server responds to the client-side test code in a way that is identical to the response given by a Windows server. Allison hopes that the protocol disclosures will lead to more robust client-side test code and better documented Samba internals. These improvements might attract new developers who are not specialists in protocol analysis and who can devote their efforts to other aspects of Samba within their expertise.
Allison said that Samba already has a prototype implementation of Active Directory, available for download as Samba version 4. He claimed that "if [the disclosures are] any good," they should help the Samba team deliver a "second source" Active Directory suite sooner than they otherwise would. He expresses a "realistic" view that the new documentation will only be a starting point—the substantial portion of the work remains in the form of writing client-side test code, and filing bug reports with Microsoft. The Samba team has expressed enthusiasm for the tools Microsoft has developed to analyze protocols under the U.S. licensing program. The most important of these is Microsoft's NetMon, or network monitor, with an NPL (network protocol language) plug-in. This device allows engineers to change protocol description in real time as the protocol streams across the network. These devices will assist Samba in its own protocol analysis.
Allison's comments about using the protocol disclosures to help implement Active Directory might be considered optimistic. On the other hand, Craig Shank suggested that Microsoft took seriously its obligation to make protocol disclosures sufficient to allow Samba to implement a version of Active Directory that is fully interoperable. Thus, those disclosures could require more than specifications of protocols.
When parties contract, the law normally assumes that the contract will increase the wealth of both parties, at least ex ante because each is free to walk away from the bargaining table. That presumption does not necessarily follow when one of the parties is required to contract on regulated terms. Because of the extraordinary strictures the EC and CFI decisions placed on Microsoft, we cannot predict how the arrangement will affect Microsoft or competition.
The EC has required Microsoft to make disclosures sufficient to allow rivals to create server software functionally equivalent to Microsoft, what Shank calls a "drop-in replacement server." But the EC also insisted that its order would not require Microsoft to disclose any of its internal Windows server code, although it may be required to give a "general description" of some of its algorithms. Microsoft believes these positions are not consistent because portions of the server code within Shewchuk's "blue bubble" diagram, particularly the Active Directory suite, require perfect integration between Windows servers in order to function properly. Labeling and explanation of the data bytes transmitted in a certain protocol, according to Microsoft, cannot achieve this level of integration. Thus, the documentation must also include what Shank described as "Windows behaviors." These disclosures would include information in the form of explanatory text, pseudo-code, or similar descriptions of algorithms Microsoft uses in implementing the protocol wherever such information is thought necessary for interoperability. Thus, the purpose of these "Windows behaviors" is to assist competitors in producing a drop-in replacement server, without revealing Microsoft's proprietary internals, which presumably embody all of Microsoft's competitive advantage. Because Microsoft has now published all of the protocols covered by the license, technical readers can examine both the specifications and the associated Windows behaviors that Samba is receiving.
Whether these disclosures will be sufficient is unclear. It may be the EC will ultimately require Microsoft to disclose its servers' formulas, workflows, and other elements that, although not literally source code, functionally make up the internal logic of the source code. When asked, Shank admitted that he has been "kept awake nights" worrying about whether anything less than a clone would be sufficient to satisfy the Commission's evidentiary requirement of a drop-in replacement server. As if to confirm Shank's concerns, Moglen suggested that Samba's goal is to "commoditize the domain server." When David Heiner of Microsoft was told of this goal, he responded, "I know. Everything we sell, they want to distribute for free."
Of course, Samba would not agree with the characterization of the product they envision as a clone of Windows server software. They believe it will be a superior product. Samba's goal is to encapsulate the network domain controller in a $50 disposable appliance and commoditize domain services, as well as file storage (network storage devices) and print services (dedicated printer servers). Samba thinks Microsoft will then copy Samba's Active Directory implementation because it will be technically superior. If Samba succeeds in this regard, Microsoft could find itself relegated to the position of other server developers, building on Samba as an infrastructure and profiting by offering value-added services like administration tools.
Despite the obvious risks to Microsoft's business plan that the disclosures pose, there is some reason to believe there may be compensating benefits. Moglen said that the Samba team found Microsoft eager to get lots of information into Samba's hands. Moglen suggested that Microsoft may have changed its mind about the value of competing implementations, and that Microsoft sees some commercial benefit accruing from Samba's success. Moglen suggested, for example, that the growth of Samba will spread Microsoft's protocols, increasing the "mind share" Microsoft's products hold among developers. Heiner said that he had heard similar arguments from EC staff: Microsoft is a platform company and thus will benefit from the spread of its platform. Heiner is skeptical of this argument, with good reason. Heiner observed that Microsoft clearly had made a different business judgment over the past few years. Under the terms of the EC decree, Microsoft must license its protocols, without patents, for essentially nothing, and license the patents in its protocols for a nominal amount. Samba itself is free and competes directly with functionality in Windows. Thus, it is not entirely clear how Microsoft can profit from the platform benefits of the expansion of Samba, other than, perhaps, by being in a good position to sell add-on services.
Moglen also suggested that Microsoft could gain by commoditization in network storage appliances that use Samba. Network storage is a growing need in network architecture. More available, and cheaper, storage compatible with Microsoft's server software could expand market share for Microsoft. These developments might hurt competitors like EMC, particularly its VMware virtualizer division. Thus, low-cost hardware appliances produced by small startups incorporating Samba in their devices might drive bigger competing software vendors out of the market, and thus benefit Microsoft.
Apart from possible competitive benefits, Samba believes Microsoft will derive technical benefits from the relationship. Moglen predicted that Microsoft Server 2008 will face as many technical difficulties as Vista has on the client side. The relationship with Samba could help address some of those problems. In his podcast interview, Jeremy Allison commented that Microsoft requested and has received Samba's test suite to use in its own development. It may be that Microsoft is using the test suites to improve its protocol documentation in its mandated disclosures. It is also possible, however, that Microsoft is finding the suites useful in the development of its own server products themselves. The results of Samba's protocol tests are likely to be more useful and mature than feedback Microsoft may have received from licensees or other third parties in the past.
Moglen also suggested that Microsoft may benefit from better documentation of its protocols under the program. Moglen expressed surprise that Microsoft had not fully documented its protocols internally, requiring its developers to work only from application programming interfaces. Thus, according to Moglen, Microsoft does not understand its own protocols because of either an obsessive need for secrecy or organizational entropy. To the extent that collaboration with Samba produces better documentation, tools, and understanding, Microsoft engineers can in turn produce better code and enhance its ability to innovate.
The suggestions of possible mutual benefit to the development efforts of both Microsoft and Samba raise the issue of whether the program might evolve into a kind of unacknowledged joint venture to develop parallel, if not joint, products. Given the radical cultural and economic differences between the two enterprises, this possibility seems remote. Nevertheless, it is fair to say that the benefits of the program will not all be in one direction.
The protocol licensing program under the final judgments in the American Microsoft case has been costly and unrelated to market needs. That program has produced very few licensees of any kind and none that promise to evolve into a platform rival of Microsoft. The Samba license formed under the order in the European Microsoft case, in contrast, is both significant and perilous for global antitrust policy. It provides critical protocols and documentation to Microsoft's most important rival in the server market, a rival, moreover, whose development methods are focused on the analysis of those very protocols. Samba is thus more likely to put the disclosures to effective competitive use than any other licensee. The long-run peril is that the disclosures will go beyond the "specifications" that the CFI contemplated, and will allow Samba to clone Microsoft's proprietary algorithms. That result, although reducing prices in the short run, would inhibit dynamic competition by undermining the incentives of leading firms to innovate.
*. Marshall M. Criser Eminent Scholar, University of Florida Levin College of Law. The authors wish to thank David Heiner and Craig Shank of Microsoft and Eben Moglen of Columbia Law School and the Software Freedom Law Center for discussing these issues with us. The title of our paper is inspired, of course, by Robert H. Mnookin & Lewis Kornhauser, Bargaining in the Shadow of the Law: The Case of Divorce, 88 Yale L.J. 950 (1979). We again thank Eben Moglen for suggesting the analogy.
**. J.D., University of Florida Levin College of Law, 2008; software developer and management consultant, 1993–2004.
1. Consolidated Version of the Treaty Establishing the European Community, art. 82, 2006 O.J. (C 321E) 1, available at http://eur-lex.europa.eu/LexUriServ/site/en/oj/2006/ce321/ce32120061229en00010331.pdf (link).
2. Case COMP/C-3/37.792, Microsoft v. Comm'n, European Commission Decision ¶¶ 779–91 [hereinafter Microsoft, EC Decision], available at http://ec.europa.eu/comm/competition/antitrust/cases/decisions/37792/en.pdf (link).
3. Id. ¶ 999.
4. Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858 ¶¶ 1329–30, 1364 (Sept. 17, 2007), available at http://curia.europa.eu/jurisp/cgi-bin/form.pl?lang=EN&Submit=rechercher&numaff=T-201/04 (under the "Cases" column and in the row with "Judgment," follow the "T-201/04" link) (link).
5. See Steve Lohr & Kevin J. O'Brien, Microsoft Is Yielding in European Antitrust Fight, N.Y. Times, October 23, 2007, at C1, available at http://www.nytimes.com/2007/10/23/technology/23soft.html?_r=1&pagewanted=1&ref=business&oref=slogin (link).
6. Microsoft Work Group Server Protocol Program License Agreement (No Patents) for Development and Product Distribution (2007), available at http://www.protocolfreedom.org/PFIF_agreement.pdf (link); see infra Part III.
7. Telephone interview with Eben Moglen, Professor of Law, Columbia Law School, Founding Director, Software Freedom Law Center (Feb. 1, 2008) [hereinafter Moglen Interview]; Telephone interview with Craig Shank, General Manager, Competition Law Compliance Team, Microsoft Corporation (Dec. 27, 2007) [hereinafter Shank Interview].
8. See William H. Page, Mandatory Contracting Remedies in the American and European Microsoft Cases, 75 Antitrust L.J. (forthcoming 2008) (manuscript at 18, available at http://ssrn.com/abstract=1073103 (link)) (describing the failure of the EC-mandated versions of Windows to attract users).
11. See Teresa C. Mann Piliouras, Network Design: Management and Technical Perspectives 356 (2004).
12. See id.
13. See William H. Page & Seldon J. Childers, Software Development as an Antitrust Remedy: Lessons from the Enforcement of the Microsoft Communications Protocol Licensing Requirement, 14 Mich. Telecomm. & Tech. L. Rev. 77, 91–93 (2007), available at http://www.mttlr.org/volfourteen/page&childers.pdf (link).
14. Id.at 104 & nn.179 & 181. The EC decision against Microsoft focused on file, print, and directory services. See Microsoft, EC Decision, supra note 2.
15. See Mitch Tulloch, Windows Server Hacks xix (2004).
16. Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858 ¶190 (Sept. 17, 2007), (quoting Microsoft's reply).
17. Microsoft, EC Decision, supra note 2, ¶ 33; see infra notes 42–45 and accompanying text.
18. See generally Steven Weber, The Success of Open Source (2004) (describing the evolution of Linux).
21. See id.
22. Id. In fact, the name "Samba" was derived from a computer search Andrew ran for words containing the letters S, M, and B (i.e. SMB/Netbios). Id.
24. See id.
25. See, e.g., The Samba Archives, http://lists.samba.org/archive/samba/ (last visited May 30, 2008) (link). This represents but one of many online community-based support venues available to developers and users of Samba at no cost.
26. The source code for the Samba system, as well as for client software, development tools, and administration interfaces, is available for public download on the Samba site. Samba Download Page, http://devel.samba.org/samba/download/ (last visited May 30, 2008) (link).
27. See All About Microsoft, http://blogs.zdnet.com/microsoft/?p=725 (Sept. 20 2007, 10:13 EST) (quoting Jeremy Allison). The Samba license permits commercial products to incorporate the Samba source code without paying any licensing or royalties fees (essentially free). In return, a commercial producer of a product incorporating Samba must agree to publish any changes (improvements) that are made to the Samba source code. See GNU General Public License ver. 3, supra note 19. Novell made a separate agreement with Microsoft in 2006 regarding licensing of server technologies that is similar to the Microsoft-Samba agreement, but that provides licenses to all relevant Microsoft patents. See Microsoft, Microsoft and Novell Announce Broad Collaboration on Windows and Linux Interoperability and Support, Microsoft PressPass, Nov. 2, 2006, http://www.microsoft.com/presspass/press/2006/nov06/11-02MSNovellPR.mspx (link). That license has been controversial in the open source community. See, e.g., Novell Sells Out, Groklaw, Nov. 2. 2006, http://www.groklaw.net/article.php?story=20061102175508403 (link).
28. Samba does not provide any particular user interface for configuring the network. In fact, all Samba configuration options are managed in a single text file. There is no user interface per se. Therefore, companies offering Samba-based solutions differentiate themselves by supplying proprietary traditional user interfaces offering configuration and management of the network, running on their respective platforms.
30. Although network computing had little to do with the merits of the U.S. case, the government insisted that the consent decree include a provision requiring Microsoft to license and disclose interoperability information for the communication protocols that Microsoft client operating systems use to communicate with Microsoft server operating systems. The government was concerned that Microsoft would use secret protocols in its client operating systems to enable them to interoperate better with Microsoft server operating systems than with rivals from other vendors. That advantage would also potentially injure middleware applications that run on the rival's servers, applications that might evolve into rival platforms. See Page & Childers, supra note 13, at 93–102.
31. See id. at 121.
32. See id. at 126–36.
33. See United States v. Microsoft Corp., 231 F. Supp. 2d 144, 189–92 (D.D.C. 2002); see also Page & Childers, supra note 13, at 105–08.
34. In the remedy proceedings, the trial court considered various alleged bad acts by Microsoft in the server market, but found them only tangentially related to the liability rulings in the government case. New York v. Microsoft Corp., 224 F. Supp. 2d 76, 138–44 (D.D.C. 2002).
35. For a discussion of current status of software patents, see Robert P. Merges, Software and Patent Scope: A Report from the Middle Innings, 85 Tex. L. Rev. 1627 (2007).
36. See Posting of Steven J. Vaughan-Nichols to Linux-Watch, http://www.linux-watch.com/news/NS4465262350.html (Apr. 9, 2008) (link). Microsoft has recently gone beyond the requirements of the final judgments by publishing the protocols online and relaxing restrictions on use of its intellectual property by noncommercial users. See Microsoft Communications Protocol Program, http://www.microsoft.com/about/legal/intellectualproperty/protocols/mcpp.mspx (last visited May 30, 2008) (link).
37. See Microsoft, EC Decision, supra note 2, ¶¶ 346–47.
38. See id. ¶¶ 185–86.
39. See id. ¶¶ 293–97.
40. See European Committee for Interoperable Systems, A History of Anti-trust Problems: Microsoft Settlements to Resolve Anti-trust Disputes 2003–2007, http://www.ecis.eu/issues/documents/List_of_Microsoft_Settlements_total.DOC (link). Many of Microsoft's rivals, especially IBM, are members of ECIS and support its advocacy at the EC.
42. See Microsoft, EC Decision, supra note 2, ¶ 550.
43. See id. ¶¶ 779–84.
44. Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858 ¶ 2 (Sept. 17, 2007).
45. See Microsoft, EC Decision, supra note 2, ¶¶ 565–66; Case T-201/04, Microsoft Corp., 2007 WL 2693858 ¶ 712.
46. See Microsoft, EC Decision, supra note 2, ¶¶ 578–84; Case T-201/04, Microsoft Corp., 2007 WL 2693858 ¶ 308.
47. See Microsoft, EC Decision, supra note 2, ¶¶ 666–92.
48. See Marty Poniatowski, Unix User's Handbook ch. 29 (2d. ed. 2002). AT&T later licensed the AS/U technology to most major UNIX vendors, who provide what is essentially a "house brand" of the software that integrates with their own UNIX operating system products.
49. Microsoft, EC Decision, supra note 2, ¶¶ 211–17.
50. See id. ¶¶ 578–84; Pontiastowski, supra note 48.
51. Microsoft, EC Decision, supra note 2, ¶ 297.
52. Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858 ¶ 140 (Sept. 17, 2007).
53. Id.¶ 233.
54. Id. ¶ 140.
55. Id.¶¶ 199–200.
56. Microsoft, EC Decision, supra note 2, ¶¶ 719 & 721.
57. Id. ¶ 221.
58. See Minutes of Proceedings, Day Three, Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858, Court of First Instance of the Eur. Communities, Apr. 26, 2006, at 18 [hereinafter Minutes of CFI Proceedings, Day Three] ("What we are seeing in the blue bubble here is that they will all be twins. They will have identical logic. Each makes assumptions about the way other servers will work.").
59. See id. at 42–44.
60. See id. at 44–45. As the CFI understood the argument, "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." Case T-201/04, Microsoft Corp., 2007 WL 2693858 ¶ 262.
61. Minutes of Proceedings, Day Four, Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858, Court of First Instance of the Eur. Communities, Apr. 27, 2006, at 11–12 [hereinafter Minutes of CFI Proceedings, Day Four].
63. See id.
64. Case T-201/04, Microsoft Corp., 2007 WL 2693858 ¶¶ 263–64.
65. Id. ¶ 265.
66. Id.¶ 658. By contrast, Judge Kollar-Kotelly in the U.S. case defined cloning as "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." See New York v. Microsoft Corp., 224 F. Supp. 2d 76, 175–76 (D.D.C. 2002). This sort of cloning would provide Microsoft's rivals a "windfall" by allowing them to short-circuit the expensive process of reverse engineering. See id.
67. The passage also ignores IBM, Sun, Oracle, and others, who sell service ancillary to Samba, for example, like consulting services, hardware, and database software. See Case T-201/04, Microsoft Corp., 2007 WL 2693858 ¶¶ 258–65.
69. See Lohr & O'Brien, supra note 5 (discussing the fact that the the royalties were limited to a maximum of 0.4% of revenue from products sold using the patented technology).
71. See, e.g., Microsoft Posts the New License Terms for Interoperability in the EU Agreement—Updated, Groklaw, Oct. 24, 2007, http://www.groklaw.net/article.php?story=2007102408501134 (link); Vaughan Nichols, supra note 9. In a recent communication, Microsoft's Craig Shank suggested that many of these criticisms were "based on misunderstanding of the operation of the agreements as drafted. . . . That said, we clarified many of those issues in the agreement with Samba just to help reduce the friction—even if born of misunderstanding rather than substance." E-mail from Craig Shank to authors (Mar. 19, 2008) (on file with authors).
72. See Groklaw, supra note 70.
75. See Andrew Tridgell, Samba, Freeing Up the Windows Workgroup Protocols, December 20, 2007, http://samba.org/samba/PFIF/PFIF_history.html (link) [hereinafter Tridgell, Freeing Up Windows Workgroup Protocols].
76. See Shank Interview, supra note 7.
77. See Case T-201/04, Microsoft Corp. v. Comm'n, 2007 WL 2693858 ¶ 1278 (Sept. 17, 2007).
79. See Microsoft Work Group Server Protocol Program License Agreement (No Patents) for Development and Product Distribution, Exhibit A (citing App 1, Table 1) [hereinafter WSPP No Patents Agreement], available at http://www.protocolfreedom.org/PFIF_agreement.pdf (last visited May 30, 2008) (link).
81. See Tridgell, PFIF Agreement, supra note 74.
82. See id.
83. That is, there is no per-copy royalty charged for use of disclosed protocols. There was, as mentioned, a one-time royalty fee of €10,000 that was paid by the PFIF.
84. See Tridgell, Freeing Up Windows Workgroup Protocols, supra note 75.
85. See Shank Interview, supra note 7.
86. See id.
87. See id.
89. Moglen Interview, supra note 7.
90. See id.; Tridgell, Freeing Up Windows Workgroup Protocols, supra note 75.
91. See Moglen Interview, supra note 7.
92. See id.
93. See id.
94. See id.
96. See WSPP No Patents Agreement, supra note 79, § 2.1(b).
97. See Tridgell, PFIF Agreement, supra note 74.
98. See id.
99. See Brett Smith, A Quick Guide to GPLv3, http://www.gnu.org/licenses/quick-guide-gplv3.html (link) ("Whenever someone conveys software covered by GPLv3 that they've written or modified, they must provide every recipient with any patent licenses necessary to exercise the rights that the GPL gives them.").
100. See Tridgell, PFIF Agreement, supra note 74.
101. Id.; see also Moglen Interview, supra note 7.
102. See WSPP No Patents Agreement, supra note 79, app. 4.
103. See Tridgell, PFIF Agreement, supra note 74.
104. See Shank Interview, supra note 7. For the text of the pledge, see Microsoft Work Group Server Protocol Program, Patent Pledge for Open Source Developers, http://www.microsoft.com/about/legal/intellectualproperty/protocols/wspp/wspp.mspx (last visited May 30, 2008) (link).
105. See Moglen Interview, supra note 7.
106. See Interview by Don Marti with Jeremy Allison, LinuxWorld, http://www.linuxworld.com/podcasts/linux/2007/122007-linuxcast.html (December 20, 2007) (podcast) [hereinafter Allison Interview] (link). On the other hand, some reports suggest that the Samba team would have preferred that the EC require Microsoft to provide royalty-free licenses for use by open source projects. Allison makes at least one comment in the podcast expressing marginal disappointment in the patent licensing scheme. Less ambiguously, Andrew Tridgell is quoted on the Samba site saying, "we were disappointed the decision did not address the issue of patent claims over the protocols." See Samba and the PFIF, http://samba.org/samba/PFIF/ (last visited June 10, 2008) (link).
107. See Moglen Interview, supra note 7.
108. See WSPP No Patents Agreement, supra note 79, § 5.5.
109. See Moglen Interview, supra note 7.
111. See WSPP No Patents Agreement, supra note 79, § 5.8.
112. See Page & Childers, supra note 13.
113. See Shank Interview, supra note 7; see also Joint Status Report on Microsoft's Compliance with the Final Judgments at 4, United States v. Microsoft Corp., (D.D.C. filed Mar. 6, 2007) (No. 98-132 (CKK)), available at http://www.usdoj.gov/atr/cases/f221700/221759.pdf (link) ("The [Technical Committee]'s initial review of the Milestone 2 documents suggests that their overall quality is meaningfully higher than that of the Milestone 1 documents").
114. See Joint Status Report on Microsoft's Compliance with the Final Judgments, supra note 113, at 2–6.
115. Id. at 14–15 (stating that Microsoft is "unaware of any existing or potential licensee that has been unable to use any Communications Protocol because of flaws in the documentation").
116. See Allison Interview, supra note 106 (describing how the Samba team will use the protocol documentation in its continuing development).
117. Id. Samba developers encode all their knowledge about a specific protocol into a test suite. Id. Each protocol or set of protocols has its own tests. Id. When a bug is reported about Samba from an end-user, the Samba team repairs the faulty code on the server side, and then writes test code that codifies the "weird behavior" that led to the bug in the first place. Id. This ensures that the use scenario that caused the bug is preserved for all future version releases of Samba. Id. These individual tests are combined into a gigantic test process that can be run against the current build of Samba by execution of a "MAKE TEST" command. Id. This runs the full test suite (referred to as the "regression suite") on the latest build of the Samba server. Id. Samba utilizes world-wide build farms that run the tests on a variety of hardware platforms. Id.
119. See id. Of course, this raises the possibility that the point of failure is in the licensee's inability to implement the protocol as a test suite. However, in the case of the Samba team's principals, this is somewhat unlikely, and errors reported as a result of this process will likely have merit. See id.
120. See id.
122. See Moglen Interview, supra note 7.
124. See Page & Childers, supra note 13, at 119.
125. See Moglen Interview, supra note 7.
126. See Shank Interview, supra note7.
127. See John E. Lopatka & William H. Page, Bargaining and Monopolization: In Search of the "Boundary of Section 2 Liability" Between Aspen and Trinko, 73 Antitrust L.J. 115, 124–26 (2005).
128. Shank Interview, supra note 7.
131. To view the MS-SAMR protocol, see Microsoft Developer Network, Security Account Manager (SAM) Remote Protocol Specification (Client-to-Server), http://msdn2.microsoft.com/en-us/library/cc211750.aspx (last visited May 30, 2008). This specification includes, among other data, the Interface Description Language (IDL) for the protocol. See id. at Appendix A: Full IDL, http://msdn2.microsoft.com/en-us/library/cc212092.aspx (last visited May 30, 2008); id. at Appendix B: Windows Behavior, http://msdn2.microsoft.com/en-us/library/cc212098.aspx (last visited May 30, 2008).
132. See Shank Interview, supra note 7.
133. See Moglen Interview, supra note 7.
134. Telephone interview with Dave Heiner, Vice President and Deputy General Counsel, Microsoft Corporation (Feb. 4, 2008) [hereinafter Heiner Interview].
135. See Moglen Interview, supra note 7.
138. See Heiner Interview, supra note 134.
139. See Moglen Interview, supra note 7.
141. See Allison Interview, supra note 106.
142. See Moglen Interview, supra note 7.
144. Page & Childers, supra note 13, at 127.
Copyright 2008 Northwestern University
Cite as: 102 Nw. U. L. Rev. Colloquy 332 (2008).
Persistent URL: http://www.law.northwestern.edu/lawreview/Colloquy/2008/16