decoration decoration

When you want to know more...
For layout only
Site Map
About Groklaw
Legal Research
ApplevSamsung p.2
Cast: Lawyers
Comes v. MS
Gordon v MS
IV v. Google
Legal Docs
MS Litigations
News Picks
Novell v. MS
Novell-MS Deal
OOXML Appeals
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v Novell
Sean Daly
Software Patents
Switch to Linux
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.

To read comments to this article, go here
Samba Team Receives Microsoft Protocol Documentation -Updated 2Xs
Thursday, December 20 2007 @ 01:29 PM EST

The Protocol Freedom Information Foundation has just signed an agreement with Microsoft to receive the protocol documentation needed to fully interoperate with the Microsoft Windows workgroup server products and to make them available to Samba and other Free Software projects. Here's a podcast where Samba's Jeremy Allison explains the news to Don Marti of LinuxWorld.

No. This isn't a bit like the Novell-Microsoft agreements. This is for access to Microsoft's protocols, as ordered by the EU Commission and agreed to by Microsoft. It's a good thing, in my opinion, and the Samba guys worked really hard to make this as good as it gets. Note that it's a copyright agreement, with no per-copy royalties, not a patent licensing, but there's a list of patents. Samba has not agreed to license them. Rather it will avoid them, and with a list of them provided by Microsoft, they can and so can you. There is no acknowledgment of them by Samba, no money paid for them, nothing. This is what Novell and others could have done, and thanks to Samba, everyone is a bit freer today.

Here's the press release, and two articles that explain a bit about how it came to be and what the agreement contains, both written by Andrew Tridgell, the creator of Samba. And here is the agreement [PDF] itself. Note that a Delaware corporation was formed for the purpose, The Protocol Freedom Information Foundation, and it is the licensee. So it can provide "detailed documentation on Microsoft protocols to developers in the free software community under non-disclosure terms, while still allowing for the development of free software under open licenses, including the GNU General Public License". That means, as Tridgell puts it, "Writing code which interoperates with Microsoft operating systems just got a lot easier." First, the press release, then the history, then the contents of the agreement explained from Tridge's perspective, how he understands the agreement. And he even provides a redline version [PDF], so you can see the original agreement Microsoft proposed and all the changes that ensued.

Update: There's a Microsoft reaction in this Reuters article, Microsoft signs rare open-source deal, under EU orders. They are "pleased".

Update 2: Carlo Piana, one of the attorneys involved on the Samba side, has now commented on the agreement on his blog, Law is Freedom, explaining it, and providing this information: "The total number of pages of which the documentation is made is 14820."

Piana's words on the agreement itself are worth repeating:

This is not the end of the problem, because there are strong issues with software patents, which remain largely unaddressed, but something of a start.

This is a major step forward to full interoperability, and Samba wanted to make it right. This is why we decided to remain silent, earlier in October, when Microsoft and the Commission announced an overhauled WSPP. We were not at all satisfied with the actual provisions of the agreement, which we did believe fell short of the commitment of making them available to Free Software. Andrew Tridgell, backed by Jeremy Allison, Eben Moglen, Volker Lendecke and my humble self have negotiated hard with Microsoft and reached an agreement that, as imperfect as it can be, will make life easier not only for Samba, but for all those who implement Microsoft's protocols for interoperable products.

One of the most interesting features of the new arrangements is that any possible risk of being tainted by the access to privileged documentation is avoided, and developers are free to use it for writing and releasing source code to the public, commenting it, discussing it quite openly. There is more. Developers will be free to continue writing code even after the expiry or termination of the WSPP without taking back a single line of code, and even retaining "residuals", in other words, unaided memory of the information they accessed.


Samba Team Receives Microsoft Protocol Documentation

December 20th 2007. Today the Protocol Freedom Information Foundation (PFIF), a non-profit organization created by the Software Freedom Law Center, signed an agreement with Microsoft to receive the protocol documentation needed to fully interoperate with the Microsoft Windows workgroup server products and to make them available to Free Software projects such as Samba.

Microsoft was required to make this information available to competitors as part of the European Commission March 24th 2004 Decision in the antitrust lawsuit, after losing their appeal against that decision on September 17th 2007.

Andrew Tridgell, creator of Samba, said, "We are very pleased to be able to get access to the technical information necessary to continue to develop Samba as a Free Software project. Although we were disappointed the decision did not address the issue of patent claims over the protocols, it was a great achievement for the European Commission and for enforcement of antitrust laws in Europe. The agreement allows us to keep Samba up to date with recent changes in Microsoft Windows, and also helps other Free Software projects that need to interoperate with Windows".

Jeremy Allison, co-creator of Samba said, "Andrew did a superb job in negotiating the agreement with Microsoft. We will be able to use the information obtained to continue to develop Samba and create more Free Software. We are hoping to get back to the productive relationship we had with Microsoft during the early 1990's when we shared information about these protocols. The agreement also clarifies the exact patent numbers concerned so there is no possibility of misunderstandings around this issue."

Volker Lendecke, head of the Samba Team in Europe said, "I am very pleased to see that the European Commission acknowledged Free Software as a valid competitor in the IT industry and that the License conditions on the protocol information offered to the Free Software world are indeed compatible with the GPL. This is much better than what we have seen in similar cases in other countries and the Commission has done a great job to push the case to this point."

Compatible with Free Software

After paying Microsoft a one-time sum of 10,000 Euros, the PFIF will make available to the Samba Team under non-disclosure terms the documentation needed for implementation of all of the workgroup server protocols covered by the EU decision.

Although the documentation itself will be held in confidence by the PFIF and Samba Team engineers, the agreement allows the publication of the source code of the implementation of these protocols without any further restrictions. This is fully compatible with versions two and three of the GNU General Public License (GPL). Samba is published under the GNU GPL which is the most widely used of all Free Software licenses. In addition it allows discussion of the protocol information amongst implementers which will aid technical cooperation between engineers.

Under the agreement, Microsoft is required to make available and keep current a list of patent numbers it believes are related to the Microsoft implementation of the workgroup server protocols, without granting an implicit patent license to any Free Software implementation.

No per-copy royalties are required from the PFIF, Samba developers, third party vendors or users and no acknowledgement of any patent infringement by Free Software implementations is expressed or implied in the agreement.

The patent list provides us with a bounded set of work needed to ensure non-infringement of Samba and other Free Software projects that implement the protocols documented by Microsoft under this agreement. Any patents outside this list cannot be asserted by Microsoft against any implementation developed using the supplied documentation. Unlike the highly dubious patent covenants recently announced by some companies this warranty extends to all third parties. Also unlike past agreements, this agreement has been carefully scrutinized by the Software Freedom Law Center, the premier legal experts for the GPL and Free Software.

Microsoft must keep the documentation up to date with new products and provide error correction assistance to parties signing the agreement. Disputes will be resolved by the Trustee appointed by the Commission as part of the court decision.

The Samba Team would like to extend our heartfelt thanks to Carlo Piana from the Free Software Foundation Europe and Eben Moglen of the Software Freedom Law Center, who have been our legal representation on this case. They have provided world-class legal services for many years and we are sincerely grateful.


Freeing up the Windows workgroup protocols

Andrew Tridgell
Samba Team
20th December 2007

The Samba Team has gone through rather an amazing journey over the last few years, culminating in todays announcement where we finally get guaranteed access to detailed documentation on all the protocols we have been working on over the years, plus many protocols we have yet to look at.

This article is an attempt to explain some of the history behind todays announcement. In a separate article I will go through some of the key aspects of the PFIF agreement, and explain how it will work in practice.

How it started

Back in September 1998 Sun Microsystems wrote to Microsoft asking for documentation to allow Sun to build software which was interoperable with Microsoft Active Directory. Microsoft turned them down.

It turns out that Microsoft, because of its position in the market, is obligated by anti-trust laws to provide that documentation, along with a wide range of other documentation for related "workgroup server" protocols. In December 1998 Sun lodged a complaint with the European Commission and so began one of the most significant legal actions in the history of the IT industry.

The big question for the free software community was whether the legal mechanisms that deal with anti-trust could cope with the extra complexities involved with free software licensing. We saw this case as an opportunity to correct some of the imbalance between the way that Microsoft can develop its server products and the way that the Samba Team needs to develop competing products, but for that to work we needed to be sure that any outcome from the case would not result in benefit only to proprietary implementers of the workgroup server protocols, but also to free software.

The EC Investigation

Following up on the Sun complaint, the European Commission launched an extremely detailed investigation of the workgroup server market. The investigation took years, and involved both deep technical investigations of the networking protocols involved as well as intensive investigations of the workgroup server market and the impact that Microsoft's position and actions in that market were having.

In a short article like this it is difficult to do justice to such a detailed and complex investigation, but I would like to say that it was a truly impressive piece of work. I was particularly impressed by the ability of the commissions investigator's to understand the complex pieces of technology involved.

Getting Involved

The investigation had already been running for a few years when we first had the opportunity to get involved. When that happened, Jeremy Allison and I had a long discussion on the merits of being involved in such a complex legal process. Would Microsoft take retaliatory action against us in some way? Would the case consume so much of our time that we lost vital development momentum? Could the case be won? Would the other participants in the case stick with it to the end? Would the result of the case be applicable to free software?

We had so many questions and no real way to judge the answers. In the end we decided that we should be involved just because it was the right ethical and moral thing to do. Microsoft had a stranglehold over much of the IT industry, and we had the opportunity to help loosen that grip just a little. That had to be a good thing.

My own involvement with these crucial early stages was very limited. Jeremy Allison and Volker Lendecke led the way, dealing with an enormous load of technical and legal information. They were helped enormously by the Free Software Foundation Europe, and especially by Carlo Piana, a lawyer for the FSFE who spent a huge amount of time untangling the complexities of anti-trust law in Europe.

One of the more significant of our early involvements was when Jeremy Allison presented information about Samba on behalf of the Free Software Foundation Europe at an oral hearing in November 2003. This was important as Microsoft had tried to portray the existence of Samba as proof that it was not necessary for them to provide any documentation to competitors. As a key developer of Samba, Jeremy was able to explain how Samba had been developed, and how lack of protocol documentation was hampering our attempts at full interoperability.

Expanding the case

During the investigation by the commission the case grew somewhat, expanding into areas beyond those raised in the original 1998 letter from Sun to Microsoft. Perhaps the most significant expansion was the inclusion of RealNetworks as an additional party, along with the complaint that the bundling of Microsoft Media Player with Windows was illegally harming the market which RealPlayer was trying to compete in.

The result was that the case now had two major parts. The original part, which dealt with interoperability, and the new part which dealt with bundling. The part which directly affected Samba was the interoperability part.

The Decision

In March 2004 the European Commission finished its investigation, and adopted a decision. That decision was, like the whole case, complex, but the key piece for us was that Microsoft had abused its monopoly position, and that in future Microsoft would be required to provide protocol documentation. This was the first big step towards the announcement that we have made today.

As part of the decision, the commission decided that there should be a trustee to oversee the compliance of Microsoft with the detailed implementation of the decision. The trustee that was appointed, Professor Neil Barrett, led a team which looked carefully at the documentation that Microsoft produced, and reported back to the commission on the degree to which the documentation met the standards of the decision. Neil was selected from a list of experts suggested by Microsoft.

The Appeal

The decision was not the end of the matter however. As is their right, Microsoft decided to appeal, which moved the whole case from being a matter handled by the European Commission, to a matter now handled by the European courts.

Like the original investigation, the appeal process was long and complex. It had quite a different character to the original investigation however. In the original investigation the European Commission conducted the case itself, in its role as competition watchdog for Europe. In the appeal the commission was the defendant in a court action brought by Microsoft, with the commission needing to defend its decision to the court, and Microsoft trying to prove that the commission had erred.

Meanwhile, the commission continued to pursue compliance by Microsoft with the original decision. On several occasions Microsoft announced that they now considered themselves to be compliant, only to find that the commission, using an impartial evaluation of the trustee, did not agree. While we had relatively little involvement with that process, we did get to see some of the documents exchanged between the parties, and were impressed with the depth of analysis that the trustee undertook in looking at the Microsoft documentation.


During the initial investigation a wide range of companies had helped provide evidence to the commission. Key among those companies, at least as far as the interoperability portion of the case was concerned, was Sun, Novell and the CCIA. These three helped provide a large part of the technical information which the commission needed to conduct its investigation.

Soon after the decision was handed down, and the appeal process began, Microsoft entered into settlements with all three of these key players, plus a number of other key companies. In total during the period of the appeal, Microsoft entered into settlements worth about 3.6 billion US dollars.

The settlements with Sun and Novell were particularly significant for the interoperability part of the case. The settlement with Sun meant that the original complainant could no longer play an active part in the appeal, while the settlement with Novell not only prevented them from providing direct input on their vast experience with the workgroup server market, but also meant that Jeremy Allison could no longer be directly involved in the appeal. Jeremy was employed by Novell at the time.

All was not lost however. The evidence that these companies had already provided was still available to the commission, and the extremely thorough investigation that the commission had undertaken meant that they were able to conduct the appeal without the help of these key players.

The Court of First Instance

These settlements led to Volker Lendecke and myself becoming more involved in the case, stepping in where Jeremy could no longer be involved. The FSFE now had the status of an 'intervener' in the case, which meant we were able to provide technical support to the commission in their defense of the appeal. This effort was led by Carlo Piana, the lawyer for the FSFE, with Volker and myself providing technical support as needed.

By this stage the case had acquired quite a high profile, and we learned that it would be heard by a full panel of 13 judges in the Court of First Instance in Luxembourg. We had decided that Volker would be the one to present to the court, as he had been deeply involved in the case for so long, and had previously presented information in the case with such success.

In late January 2006 the date for the week of hearings in the appeal was finally set. By an extraordinarily unlucky coincidence, the case was to be heard in Luxembourg in the last week of April 2006. That was the same week as the annual SambaXP conference in Germany. Volker Lendecke is the primary organiser of SambaXP, which left him in a very tricky position of having to be in two places at once.

After some discussions I ended up taking the place of Volker as the person to present our material to the court, so Volker could continue to look after SambaXP.

The Appeal Hearing

The weeks leading up to the hearing in 2006 were quite intense, with lots of legal briefings. Carlo did most of the hard work, with my role mostly to provide technical input where it was needed. The week before the hearing I went over to Brussels to meet up with Carlo and others helping with the case. I worked a lot with Ronald Alepin, who was an expert witness presenting a broad industry view of the interoperability part of the case. We ended up making a joint presentation, with me concentrating on the technical side of the interoperability protocols, while Ronald gave a broader view.

One big bonus was Alan Cox from RedHat. He turned up in Luxembourg and was a big help in working out how things should be presented and explained to the court. Some of the information we were trying to get across was quite technical and it was a challenge to present it in such a way that all the judges could understand, while at the same time keeping everything completely accurate. I think we succeeded, but only with the help of people like Alan (and many other helpers!) who offered ideas on how to make the presentation less daunting to someone who may not have the right technical background.

A Long Wait

After the appeal hearing in April 2006 it took 15 months before the ruling was announced. We thought that the case had been presented well, and we had a lot of faith in the extremely thorough work the commission had done, but we didn't know for sure what the outcome would be.

We finally heard the result on 17th September 2007, and were relieved to hear that the commission had won a resounding victory. It was particularly nice that the judgement document was very clearly written, and showed that the victory had not just been because of some legal point of law, but had been because the court had properly understood the technical details of the case and the reasoning behind the commissions decision. This was important, as it made a further appeal less likely, and established the interoperability principles involved in the case in a very firm manner.

The Agreement

One of the results of the court decision was that Microsoft would finally be required to offer detailed protocol documentation to their competitors, including open source competitors like us. This was what the commission had been pushing for since 2004, but now there really was no further opportunity for delay or misunderstanding.

We first got an idea of how this might work in October 2007, when Microsoft posted a pair of license agreements on their WSPP website. The basic form of the agreements were that Microsoft would provide a choice to licensees. They could pay a single flat fee of 10,000 Euro, which would give access to the protocol documentation but without any patent licenses. Or a licensee could choose to pay the fee plus a per-copy royalty which would give access to the documentation, plus a patent license on a set of Microsoft patents which were possibly relevant to the workgroup server protocols.

Our initial reaction was dismay. The per-copy royalties on the patent license were completely incompatible with the principles of free software, so we knew that we could not even consider that agreement. We had hoped that the commission would view the courts decision of the 17th of September as sufficient to warrant a patent license which didn't involve a per-copy royalty, but unfortunately that was not the case.

We were certainly pleased that there was an option for a flat-fee agreement which would give us access to the protocol documentation, but the terms of that agreement as they were posted in late October included a number of sections which made the agreement very hard for us to accept. After so many years, we wondered if the effort had been wasted, and we would not be able to get access to the protocol documentation that we wanted.

Then a remarkable thing happened. Responding to an article on Groklaw where the agreement was being discussed, the trustee Neil Barrett posted a suggestion that I get in touch with him. Neil directed me to Craig Shank, who heads up Microsoft's protocol licensing team. Neil thought that Craig would be the right person to talk to to try and fix some of the problematic parts of the agreement.

This in turn resulted in several weeks of intensive discussions, during which we found that Microsoft was indeed very willing to make modifications to the agreement to make it more suitable for use by the free software community. Microsoft was keen to ensure that it complied with the court ruling, Neil Barrett was happy to help facilitate those discussions, and of course we were more than willing to point out the parts of the agreement that were problematic for free software projects.

We weren't able to change the fundamentals of the agreement, so we still didn't have a complete solution to the patent problem, but we did find a way to put quite a strong boundary around which patents we needed to avoid. We also couldn't change the fact that the protocol documentation would need to remain confidential - the decision by the commission did not force Microsoft to publicly document their protocols, which is of course what we would have preferred, only that Microsoft must license the documentation under reasonable and non-discriminatory terms.

Despite these limitations, we were able to make a great deal of progress. These discussions were helped a great deal by our legal counsels, especially Eben Moglen of the Software Freedom Law Center, and Carlo Piana of the FSFE. The agreement was also critically examined by key people (including lawyers) from various Samba vendors, and various free software community members.


The result is what we are announcing today. There is now a new organisation, the Protocol Freedom Information Foundation, which is a Microsoft WSPP licensee, and which can provide detailed documentation on Microsoft protocols to developers in the free software community under non-disclosure terms, while still allowing for the development of free software under open licenses, including the GNU General Public License. Writing code which interoperates with Microsoft operating systems just got a lot easier.


The PFIF Agreement

Andrew Tridgell
Samba Team
20th December 2007

This article will give my own perspective on the agreement entered into today between the Protocol Freedom Information Foundation (PFIF) and Microsoft. I led the negotiations around the agreement, so I thought I should try to explain why it ended up in the form that it did, and how I see this agreement being used in practice.

I've written a separate article giving some historical background to the agreement, so if you haven't read that article then I suggest you do that first. This one probably won't make much sense without the history.

Please keep in mind that this article is my personal perspective, and I am not a lawyer. I have been deeply involved in this agreement, but a lawyer may well have a different perspective.

Earlier Agreements

As I hope is clear from the background history article, we did not come into the negotiations for this agreement with a blank slate. The commission had decided that the initial framework for the agreement should be drafted by Microsoft, and they in turn based the agreement text on an earlier agreement that came from the Department of Justice anti-trust case in the United States. That earlier US agreement is known as the Microsoft Communication Protocol Program, or MCPP.

The agreement that we were working towards (called the Workgroup Server Protocol Program, or WSPP) had some similarities to the MCPP, but also had some very significant differences. For a start, the MCPP agreement was based around the idea of per-copy royalties, and did not make any provision for implementations under free or open source software licenses.

So it was not that surprising that when Microsoft first published their proposed WSPP agreement towards the end of October 2007 that it still carried a lot of baggage from the MCPP program. The agreement was also more complex than it might have been if it had been drafted from scratch for the WSPP program. Much of this complexity still remains in the final PFIF agreement, although some of it has been fixed.

The Ground Rules

Before we got involved with this agreement, the European Commission and Microsoft had already thrashed out the basic rules. Microsoft was required to provide full and accurate documentation on all their file, print and UGA (user, group and authentication) protocols in exchange for a one-time fee. Microsoft was also required to offer a separate agreement where licensees could choose to license a set of patents that might be relevant for the same set of protocols, in exchange for per-copy royalties.

The commission and Microsoft had also agreed that the first agreement (called the no-patent agreement) would be compatible with the open source licensing requirements of free software projects such as Samba, but that it would still allow Microsoft to keep the WSPP documentation itself as confidential information.

That is how we ended up with the rather unusual situation where Microsoft would be receiving a payment as part of their penalty for past anti-trust abuses. The commission believed the license fee was a necessary part of the solution, and it believed that it could not require Microsoft to make the protocol documentation public in the same way that many other companies have made their protocol specifications public. The commission also thought that it could not require Microsoft to enter into flat-fee compulsory licensing of its patents.

So the challenge was to meet all these competing demands yet still produce an agreement that was workable. The WSPP agreement which Microsoft announced on the 24th of October was the first attempt to do that.

Initial Reaction

The initial reaction in the free software community mirrored our own initial reaction to the agreement. The wording was scary, and we reacted quite negatively. What we didn't understand at the time was that this agreement was just the starting point for negotiations, and that there was an opportunity to discuss the details of the agreement with Microsoft to try and solve the problems that we had noticed.

As I mentioned in the article talking about the history of this case, we were informed of the possibility of negotiations by Professor Neil Barrett, the trustee for the commission. Neil introduced us to Craig Shank of Microsoft, and we entered a period of negotiation that lasted several weeks, and resulted in a great many improvements in the wording of the agreement. This ultimately resulted in something that we thought would work.

Anatomy of the agreement

Later in this article I will try to explain some of the changes we asked for in the agreement, in the hope of highlighting the areas we were particularly concerned about while at the same time giving an idea of how we think this agreement will be used in practice. However, before I can do that, I need to explain a bit about how the agreement is structured. In this summary I will of course have to gloss over many important features of the agreement, and the lawyers among you will almost certainly want to just read the agreement, but hopefully this brief summary is useful for some people. Of course there is also a level of detail and analysis that is privileged communication with our lawyers that I won't talk about here.

The agreement is, at its heart, a non-disclosure agreement (NDA). The PFIF is agreeing not to disclose certain confidential information, while Microsoft is agreeing to provide technical documentation which can be used to help build an implementation of the WSPP protocols.

As is common with legal agreements, section 1 is a glossary of definitions of the terms used in the agreement. Whenever you see a capitalised term in the body of the agreement then that is referring back to one of the definitions in this section (or a definition in some other section). Some of these definitions are quite complex, and some of them got even more complex during the negotiations.

Section 2 deals with the actual license grant. This is where Microsoft grants us a license to use the WSPP documentation to build an implementation, but it also grants a number of other very important things, including the ability for licensees to subcontract to other entities. That subcontracting section is what made it possible for the PFIF to be the licensee, allowing the free software projects working with PFIF to benefit from the agreement without each of them having to pay a license fee.

The last part of section 2 deals with dispute resolution. It describes the role of the trustee, and describes how we will work out any disagreements that might arise. That section also deals with the 'non-discriminatory' part of the commission's RAND requirement, which means that if Microsoft enters into a similar agreement with someone else which has better terms, then we will have the opportunity to also benefit from those terms.

Section 3 is where Microsoft promises to provide the documentation that we need. It deals with the timeliness of that documentation, how errors in the documentation will be dealt with, how and when updates will be provided and what type of technical support will be provided.

Section 4 deals with the license fee, which is what the PFIF needs to pay to Microsoft in order to get access to the protocol documentation. It is a one time fee of 10,000 Euros, which would be a lot of money for many free software projects, but which isn't too much when it only has to be paid once by the PFIF.

Section 5 deals with the confidentiality of the WSPP documentation. This is where the licensee (the PFIF) promises to keep the documentation confidential, while at the same time describing how free software projects may release source code and source code comments without violating these confidentiality provisions. This section also deals with 'residuals' which allows people who no longer have access to the documentation to escape the confidentiality provisions after a period of time. That is essential for anyone who wants to be able to change jobs in the IT industry.

Section 6 deals with various legal warranties and remedies. Perhaps the most important part of this section is the bit which ties this agreement to the 2004 European Commission decision, and ensures that the agreement meets the terms of that decision. This section also contains a key warranty that was the center of much of the negotiation that I was involved with, which is the warranty of the completeness of the list of patents that Microsoft has declared.

Section 7 deals with various indemnifications, plus an interesting section which raises the prospect that some day Microsoft could end up defending Samba in court. It isn't very likely that this will ever come to pass, but it is a curious thing to think about.

Section 8 is one of those capitalised sections in legal agreements that are so hard to read. It is a limitation of liability, with some important caveats related to the commission's decision and confidentiality.

Section 9 deals with the term of the agreement, and what happens when it terminates. The key points are that the agreement lasts for five years, but it can be extended under similar terms. It is also important to note that even when the term has expired we are allowed to keep the documentation that we have at the time.

Section 10 is headed 'miscellaneous' and contains a grab bag of stuff that doesn't easily fit into one of the other sections. Perhaps the most important is the part that establishes the right of complaint to the European Commission if needed (though we hope it won't be needed), plus the penalties if the documentation is not as complete as it is supposed to be.

The Exhibits

After the body of the agreement comes two exhibits. The first exhibit is the list of protocols that the PFIF selects to license, which is all WSPP protocols. This is really a hang over from the MCPP agreement where each protocol had a separate fee attached, so it made sense to only choose the protocols that were most relevant.

The second exhibit is a set of program entry requirements, which apparently is designed to prevent criminal organisations getting access to the protocol documentation. We already have a commitment from Microsoft that the PFIF passes these entry requirements.

The Appendixes

After the exhibits comes four appendixes. The first appendix gives the pricing principles that the commission agreed with Microsoft, along with a list of the WSPP protocols currently available.

The second appendix links to a set of sample protocol specification documents, supposedly to give some idea of how the protocols will be documented. I didn't find the examples very useful myself, instead relying on comments from existing MCPP licensees and the trustee that the documentation is indeed usable.

The third appendix is a result of Microsoft being sued for patent infringement while the negotiations were underway. Section 3.3 of the agreement says that Microsoft needs to notify us of litigation which might be relevant to the WSPP protocols, and this is the first of those notifications.

Appendix 4 is a list of patents, which is the key to the patent list completeness part of the agreement added during the negotiations. It might seem scary to have a list of patents in an agreement like this, but it really is a good thing. See the section below on patents for details.

The PFIF and Samba

We are finally through the basic description of the agreement. As I warned you, it is complex. Some of that complexity arises from the nature of the problems it is trying to address, and some of it arises from the chop and change drafting process that was used.

Now that you have the basics, I will try to describe how this will work in practice. As I have mentioned before, the entity which has actually signed this agreement is the PFIF (Protocol Freedom Information Foundation), which is a Delaware corporation created by the Software Freedom Law Center especially for this agreement. So 'licensee' in the agreement is the PFIF.

So how does this help free software projects? The way it works is that free software developers can become subcontractors to the PFIF, using the subcontracting provision in section 2.1(b) of the agreement. When a developer (such as myself) becomes a PFIF subcontractor, they will get access to the relevant WSPP documentation under similar non-disclosure terms to those given in the agreement.

So when I become a PFIF subcontractor I will be able to access the WSPP documentation and I will be able to use that documentation to implement new features in Samba. The resulting code that I write (along with the source code comments) will be completely unencumbered as provided for in the agreement, and can be released under the terms of the GNU General Public License just like Samba is currently released.

If for some reason I decide that I no longer need or want access to the documentation in the future then I have the option of withdrawing from that arrangement, at which time the 'residuals' clock starts ticking, and three months later I am completely free of the non-disclosure terms of the agreement.

We don't yet know exactly how many members of the Samba Team will become PFIF subcontractors, but it is likely to be several of us at least. Some team members may prefer to hold back and wait and see how the others find the experience.

We also don't know how many free software developers from other projects will want to become PFIF subcontractors. I think there will be quite a few, but it is up to them. The PFIF is now a community resource and I suspect a number of projects will find that the documentation made available by becoming a PFIF subcontractor will be worth signing up for.


Before I go on to a description of the changes we requested in the agreement, I should say something about patents as this is bound to be a hot topic of discussion.

For me, one of the key things about free software and patents is that we are all in the same boat. It is vitally important to the continued success of the community development model that one part of the community does not enter into an agreement which gives some people patent protection while leaving other people out in the cold. That is why I was so opposed to the patent agreements recently entered into by Novell, Xandros and other companies. I considered those agreements to be dubious at best, and certainly a violation of at least the spirit of the GNU General Public License. I was very glad to see this sort of shenanigans prevented in version 3 of the GPL.

I am also a conscientious objector when it comes to patents. Although some of my research work has been cited by other people in their patent applications, I don't have any patents of my own, and I intend to keep it that way. If you work for a big IT company then you probably know that not having any patents can sometimes be a tricky thing to achieve. Perhaps my headstone will read "died with no patents, and proud of it".

So it may seem a bit strange that I have now helped negotiate an agreement between the PFIF and Microsoft which has a appendix containing a bunch of patent numbers, and even stranger that the appendix was added at my request. I'll try and explain before the flames get too hot.

The Samba Team has for a long time put a lot of effort into ensuring that we don't infringe any patents. I have spent countless hours talking to patent attorneys, and analysing patents to ensure we don't infringe. The problem is that the number of patents we have to analyse is unbounded. We have generally found it isn't too much of a problem to avoid infringement of patents that we know about, but what about patents that we don't know about?

That is why this agreement presented us with an opportunity. For the Samba project one of the most obvious concerns has been the possibility of infringing Microsoft patents. While we hoped that the decision would lead to a complete solution to this problem by requiring Microsoft to license all of its patents with a single flat fee, the European Commission didn't think that was possible. So instead we proposed a system which would give us a bounded set of work in our patent analysis efforts.

That is what section 6.2(b), along with the definition in section 1.10, provides us with. For the patents on the list in appendix 4 we need to apply our usual procedures of patent analysis and non-infringement to ensure that we avoid the patents. For all the patents not in that appendix, Microsoft is now committed not to assert the patents against anyone developing, making or distributing an implementation of the WSPP protocols.

The key to this part of the agreement not harming the community and not causing GPL problems is the "or any third party" wording in section 6.2(b), along with the "or derived therefrom" wording in section 2.2. That means we aren't just protecting a subset of the community - everyone gets the same protection.

Where things get complex is in the handling of new patents. The horrendous alphabet soup in the definition of "Subject Patent Claims" in section 1.10 is trying to cover all of the ways in which new patents might arise, and how they are dealt with. The idea is that Microsoft can get new patents into the list of patents we need to be careful of, but only if they give the PFIF plenty of warning.

This is obviously not a complete solution to the problem of patents on these protocols, but it is at least a step in the right direction. We now have a bounded set of work to do to ensure we don't infringe any Microsoft patents on these protocols. This means Samba vendors can deploy Samba with confidence, and a degree of certainty regarding their exposure to Microsoft patents.

I should also mention that Microsoft made a separate pledge (not as part of this agreement) to not assert any patents directly against non-commercial open source projects. Please be assured that we did not ask for that pledge, and we will not in any way rely upon it. That pledge is an example of the sort of divisive patent covenant which does not cover all users and distributors of free software. For a patent pledge to be useful it must cover all users and distributors of a piece of free software, not just a subset of the community.

To avoid any misunderstanding, the PFIF agreement also states in more than one place that the agreement does not imply that Samba in any way infringes any Microsoft patents, and does not prevent us from contesting the validity or applicability of any patent.

The Negotiation Process

Once Neil Barrett introduced me to Craig Shank from Microsoft, we embarked upon a lengthy negotiation process where we raised issues that we saw with the agreement and Microsoft responded. This process began with a mutual agreement that each issue that was raised should be tied back to a practical problem that the Samba project might face in taking advantage of the agreement. That was a good foundation, as it helped ensure that the negotiation process didn't get stuck in a quagmire of legal technicalities.

As I have said before, I am not a lawyer. Instead I'm a programmer who occasionally reads legal agreements, so it was critically important that all of the negotiations were overseen by legal counsel who could advise us on the meaning and interpretation of legal agreements. For that role we once again relied on Eben Moglen and Carlo Piana, who have both shown an incredible degree of patience in assisting us throughout this process.

We also sought input from various Samba vendors and their lawyers, who provided invaluable insight into how the agreement might affect their use of Samba. In total I think there must be at least a score of lawyers who have carefully looked over this agreement and suggested one change or another, plus of course all the members of the Samba Team and several members of the free software community which I thought might have some valuable input on an agreement like this one.

My role was to collate and filter all this input into a useful form and present it to Microsoft. That then led to discussions on how to solve the problems, which resulted in new drafts, which then resulted in more comments. That process continued for a series of 8 drafts over several weeks.

The first draft was what we started with, which Microsoft posted to the WSPP website in late October. The other drafts were the results of our negotiation. In total about 50 changes were made during the drafting process. Some of those changes were very small, and some involved removing whole sections or adding new sections. In each case the aim was to ensure that the agreement became a clearer document, which did not do anything to impede usage by free software projects.

I will describe a few of the highlights of the changes that were made in the sections below. You may also find it useful to have a look at this markup document which shows all of the changes that happened between the initial draft on October 24th and the final agreement.

It is also worth noting that we expect other organisations (vendors, large IT companies etc) to also approach Microsoft for a WSPP license. They may well have different needs to us, and may end up asking for some terms which are a bit different than we were happy with. However, because of the way the RAND provisions in this agreement work, if they do negotiate something that would also be good for us then we will have the opportunity to benefit from those improved terms.

Licensed Server Implementation

One of the first changes we asked for was to get rid of the word 'Server' from the term 'Licensed Server Implementation' throughout the agreement.

We wanted that change because of the way we develop Samba. When we write Samba, we don't start with a server implementation, we start with a client library, then use that client library to develop a test suite, these use both of those as a guide to developing a good server implementation. Without this change to the agreement we were concerned that we may not be able to keep following this software engineering approach as we would only be able to distribute a server implementation, not a client implementation.

This change, like quite a few of the changes we asked for, may not even have been necessary. The definition of "Licensed Server Implementation" didn't explicitly tie it to only server code, but we didn't want any possibility of misunderstanding, so we asked for the change. In a later draft we ended up dropping the word 'Licensed' as well, leaving it as just 'Implementation'.


Given my allergy to long term non-disclosure agreements, a very important change from my point of view was the addition of the three month residuals period. I wanted to be absolutely sure that I had a way (other than dying!) of leaving this agreement behind and no longer being bound by the confidentiality terms if I decided I wanted out.

This is also critically important for anyone who may want to change jobs in the future, as it is not uncommon for a prospective employer to ask what existing NDAs you are bound by. None of us could assume that all our future employers would be happy with the confidentiality terms of this agreement, so we had to make sure we could leave them behind if need be.

Source Code Comments

An area that sparked considerable discussion was section 5.6 of the agreement that dealt with comments in our source code. We wanted to make it very clear that we could continue with our existing practices of comments in our source code, so that there would not be any disagreement or misunderstanding down the track over what was acceptable. This goes to the heart of the "confidential documentation but open code" aspect of the agreement.

The source code comments provision was also extended to cover commit messages, as it has been our habit over the years to include quite verbose commit messages explaining the reasoning behind our code changes. We did not want to have to change that practice, so we wanted our existing commenting and commit message approach to be specifically allowed in the agreement.

Related to this was the fact that our source code would necessarily have some similarities to elements of the documentation. This is a natural result of the nature of many of the protocols we deal with, and avoiding those similarities to avoid any possible claims of copyright infringement would be a real burden to writing good code. To address this, we asked for a new section in the agreement, section 5.8, which provides for a specific acknowledgement that these similarities are expected, and will not be the basis for a copyright infringement claim.

'Obtained From' versus 'Contained In'

One subtle but important change was the change in section 2.3, where we asked for the words 'contained in' to be changed to 'obtained from'.

This section of the agreement deals with the the distribution of material that may be in the documentation. We already know a great deal about the WSPP protocols, and we wanted to ensure that by signing this agreement we did not somehow put ourselves in the situation that we cannot distribute information that we already know. A good example of this is the various papers we have written, and two theses written by Andrew Bartlett and Stefan Metzmacher. It would be a step backwards if we could no longer publicly distribute those documents because the same material now happened to be included in the WSPP documentation.

This change was also reinforced by some related changes in section 5.4, which lists some of the exclusions to what is considered confidential, both in terms of information we already know, and information we may know in the future.

Inter-Licensee Discussion

An important practical change to the agreement was made with the addition of section 5.6(b), which requires Microsoft to establish a mailing list for discussion between licensees, and which allows for development discussions directly between licensees and at plug-fests.

This matters because we are expecting that this WSPP agreement will lead to a greater level of cooperation within the industry on the protocols that Samba implements. Without this change we could be left with the situation that cooperation becomes impossible, as each company would be isolated from other companies and the free software community by the confidentiality requirements of the agreement.

In years past there was a great deal of cooperation between CIFS vendors, particularly at regular plug-fest events, but in recent times that cooperation has stagnated, partly because many of the vendors had signed up to confidentiality agreements with Microsoft as part of the MCPP program. We wanted to ensure that the WSPP agreement didn't perpetuate that problem.

Next Steps

There were lots of other changes, some more important than others, but I won't try to describe them all here. You can read the agreement and the redline yourself to see what has changed, and what was left alone.

Now that the PFIF has entered into the agreement, the next step is for interested free software developers to approach the PFIF to ask to become subcontractors, so they can get access to the documentation. It may take a couple of weeks to establish that process, but I hope that early in the new year we will see the first results start to filter through, with new features in Samba and other projects.

This whole process has been long and exhausting for everyone involved, but I think it has been worth it. We live in interesting times.

  View Printable Version

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )