By William H. Page[*] & Seldon J. Childers[**]
III. The Microsoft-Samba Agreement
On December 20, 2007, the Protocol Freedom Information Foundation[78] (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.[79] The Software Freedom Law Center (SFLC)[80] created the PFIF as a nonprofit Delaware corporation to hold the master license and to license the documentation to free or open source developers.[81] The PFIF paid Microsoft a one-time royalty fee of €10,000.[82] The agreement provides a royalty-free[83] copyright and trade secret license permitting liberal use of the protocols and documentation, subject to confidentiality and non-disclosure restrictions.[84] 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.[85] 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.[86] 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.[87] Thus, Shank was prepared to disclose more than the specifications to the extent necessary to achieve the requisite degree of interoperability.[88]
According to Samba’s attorney Eben Moglen, Samba took a very different view of the negotiations.[89] 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.[90] 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.[91] 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.[92]
Negotiations began in mid-October.[93] 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.[94] 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.[95]
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.[96] 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.[97]
Like the original WSPP/No Patents agreement, the Samba license does not grant licenses to any of Microsoft’s patents.[98] 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.[99] Since Samba is licensed under the GPLv3, it was essential that the Microsoft license provide some means of avoiding infringement.[100] The Samba team was particularly worried that their development efforts would infringe unknown patents, which Microsoft could then use to block distribution.[101] 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.[102] 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.[103] 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.”[104] 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.[105] In a recent podcast interview, Jeremy Allison described software patents as “pure evil,” but also usually “pure rubbish” and easy to design around.[106] 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.[107] 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.[108] Second, the NDA provisions as originally drafted would have forbidden reproduction of the disclosure information.[109] 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.[110] 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.[111]
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.
A. Samba
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.[112] 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.[113] The Technical Committee continues to test that documentation by developing its own prototype implementations,[114] but Microsoft asserts that the documentation is already sufficient for any practical commercial development by its licensees.[115]
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.[116] 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.[117]
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.”[118] 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.[119] 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.[120]
Allison said that Samba already has a prototype implementation of Active Directory, available for download as Samba version 4.[121] 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.[122] The most important of these is Microsoft’s NetMon, or network monitor, with an NPL (network protocol language) plug-in.[123] This device allows engineers to change protocol description in real time as the protocol streams across the network.[124] These devices will assist Samba in its own protocol analysis.[125]
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.[126] Thus, those disclosures could require more than specifications of protocols.
B. Microsoft
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.[127] 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.”[128] 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.[129] Because Microsoft has now published all of the protocols covered by the license,[130] technical readers can examine both the specifications and the associated Windows behaviors that Samba is receiving.[131]
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.[132] As if to confirm Shank’s concerns, Moglen suggested that Samba’s goal is to “commoditize the domain server.”[133] When David Heiner of Microsoft was told of this goal, he responded, “I know. Everything we sell, they want to distribute for free.”[134]
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).[135] Samba thinks Microsoft will then copy Samba’s Active Directory implementation because it will be technically superior.[136] 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.[137] 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.[138] 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.[139] 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.[140] 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.[141] 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.[142] 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.[143] 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.
Conclusion
The protocol licensing program under the final judgments in the American Microsoft case has been costly and unrelated to market needs.[144] 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.
————
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).
80. For a description of the SFLC’s activities, see its home page, http://www.softwarefreedom.org/ (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.
88. 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.
95. 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.
110. Id.
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.
118. 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.
121. Id.
122. See Moglen Interview, supra note 7.
123. Id.
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.
129. Id.
130. See Microsoft Developer Network, Windows Server Protocols (WSPP), http://msdn2.microsoft.com/en-us/library/cc197979.aspx (last visited May 30, 2008) (link).
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.
136. Id.
137. Id.
138. See Heiner Interview, supra note 134.
139. See Moglen Interview, supra note 7.
140. Id.
141. See Allison Interview, supra note 106.
142. See Moglen Interview, supra note 7.
143. Id.
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
(Comments)
Comments