The PFIF Agreement
Andrew Tridgell Samba Team 20th December 2007This 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 AgreementsAs 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 RulesBefore 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 ReactionThe 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 agreementLater 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 ExhibitsAfter 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 AppendixesAfter 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 SambaWe 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.
PatentsBefore 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 ProcessOnce 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 ImplementationOne 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'.
ResidualsGiven 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 CommentsAn 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 DiscussionAn 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 StepsThere 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.