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


Groklaw Gear

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

You won't find me on Facebook


Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

No new stories

COMMENTS last 48 hrs
No new comments


hosted by ibiblio

On servers donated to ibiblio by AMD.

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.


Samba Team Receives Microsoft Protocol Documentation -Updated 2Xs | 274 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Corrections Thread
Authored by: tyche on Thursday, December 20 2007 @ 01:36 PM EST

"The Truth shall Make Ye Fret"
"TRUTH", Terry Pratchett

[ Reply to This | # ]

Once again, it's the little guys who do the right thing
Authored by: Anonymous on Thursday, December 20 2007 @ 01:43 PM EST
Bravo, Samba and Protocol Freedom - you've done what the "big boys"
like Novell won't do, taken the time to do it right and honoring both the letter
and intent of licenses and law.

Maybe someday we'll see leadership like this come from an actual honest-to-gosh
business. In the meantime, hats off to you for your courage, tenacity, and

[ Reply to This | # ]

OT here
Authored by: SpaceLifeForm on Thursday, December 20 2007 @ 01:44 PM EST
Please make any links clickable.


You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

News Picks commentary here
Authored by: SpaceLifeForm on Thursday, December 20 2007 @ 01:48 PM EST


You are being MICROattacked, from various angles, in a SOFT manner.

[ Reply to This | # ]

Of course now Microsoft will 'modernise' it's protocols
Authored by: kawabago on Thursday, December 20 2007 @ 01:55 PM EST
Making all that documentation obsolete. A funny thing about it. Why a
non-disclosure agreement to write open source code, isn't that kind of

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: PolR on Thursday, December 20 2007 @ 02:12 PM EST
Congratulations to the Samba team and a big Thank You from us all. This is
tremendous work you are doing facing difficult opposition.

We will wait to see the report on what you see when you read the documentation.
Is it really up to what it is supposed to be? We don't want to sound cynical,
but the history is history and to quote Yogi Berra, it's not over until it is

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: KayZee on Thursday, December 20 2007 @ 02:20 PM EST
A big thank you to everyone at the Samba team for seeing this through.

While I may always be suspicious of MS, it seems like there are a few people
there trying to do the right thing. Too bad it couldn't have happened sooner.

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: Anonymous on Thursday, December 20 2007 @ 02:21 PM EST
Notice a story on Groklaw played a key role in getting the licencing terms
modified so they would be acceptable to the FOSS community, but PJ was too
modest to brag about it.

[ Reply to This | # ]

Authored by: Sean DALY on Thursday, December 20 2007 @ 02:32 PM EST
This is fabulous news!

Jeremy, tridge, Volker, Carlo, Georg -- Congratulations to all of you for
persevering and never giving up.

I think I'll celebrate in my own quiet way :)


[ Reply to This | # ]

It's good news. But ...
Authored by: Anonymous on Thursday, December 20 2007 @ 02:36 PM EST

It's good news and is the result of a lot of hard work by Tridgell, Moglen, Piana and many others. I suspect a lot of work has been done behind the scenes by several dedicated people.

What sticks in my throat just a little is this:

After paying Microsoft a one-time sum of 10,000 Euros

Microsoft didn't pay €10,000 to any of the (many) people who developed the Internet protocols (like these) which it used for free. At a conservative estimate, Microsoft has used, without payment and mostly without acknowledgment, about 1,000 times as much material from the academic/free software community as it has ever contributed. Moreover, the material it has used is of vastly superior quality to the obfuscated rubbish it has contributed, having been reviewed, commented on and improved by some of the best computer scientists in the world.

In my view, Microsoft should be paying €100,000 to Tridgell and the other members of the Samba team for reviewing, commenting on, and providing an OS-neutral implementation of, Microsoft's botched attempt at a network protocol.

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: billposer on Thursday, December 20 2007 @ 02:42 PM EST

I'm having trouble understanding what aspects of the documentation could be confidential when it is used to write open source software? Any previously secret aspects of the protocols will be revealed by the code, won't they? The only information not obtainable from the code will be things like the reasons for doing things a certain way, which, if Microsoft considers them secret, are not strictly necessary in documentation and which therefore Microsoft is entitled to omit. So, what exactly does the NDA protect?

[ Reply to This | # ]

still very suspicious, here
Authored by: mcinsand on Thursday, December 20 2007 @ 02:56 PM EST
Have we heard any indirect feedback on the quality of this alleged
documentation? I'll be very surprised if it's useful. In fact, I'd be that it
comes in the same mode as the 'documentation' for O²XML: 1% information, 99%
chaff, and still some key points missing.

Ooops, is my cynicism showing?

[ Reply to This | # ]

Show-stopper patents?
Authored by: Anonymous on Thursday, December 20 2007 @ 02:56 PM EST
Is it possible that any of the patents listed are so fundamental to Samba that Samba would be unimplementable without infringing? If so, is there a way of gracefully exiting from the documentation NDA and still be free of a willful patent infringement claim?
P.S. Congratulations to all for this.

[ Reply to This | # ]

Please do the same thing for Microsoft document formats
Authored by: Anonymous on Thursday, December 20 2007 @ 03:00 PM EST
Otherwise we'll never overcome the MS Office Monopoly.

[ Reply to This | # ]

Is it useful?
Authored by: Anonymous on Thursday, December 20 2007 @ 03:13 PM EST
I ask because given Microsoft's... other... documentation *cough*MSDN*cough*,
sometimes it seems like the only way to figure out how things actually work is
to run your own tests.

They seem to treat their code as their specification (see also: OOXML) and
there are plenty of times where they do things that are ridiculous and

So I guess I wonder if these specs reflect the actual behavior, or the designed
behavior? And whether, in spite of the expected flaws, the documents are useful
in telling them things they don't already know?

[ Reply to This | # ]

This is truly a landmark - Congratulations to all Involved :)
Authored by: SilverWave on Thursday, December 20 2007 @ 03:15 PM EST
Very well done and thanks for all the hard work!

Software Patents give Hardware Patents a bad name.

If the Pharmaceutical industry does not want to be included in the backlash...
arrange for a separation.

[ Reply to This | # ]

Daryl is it snowing in hell?
Authored by: Anonymous on Thursday, December 20 2007 @ 03:40 PM EST
It has frozen over if Microsoft complies with open standards and protocals.

[ Reply to This | # ]

Authored by: Anonymous on Thursday, December 20 2007 @ 03:50 PM EST
Bet 10 to 1 Macroshaft is about to introduce something entirely incompatible and
compelled migration by sheer lack of alternative.

[ Reply to This | # ]

Amazing achievement - I wonder why MS agreed?
Authored by: SilverWave on Thursday, December 20 2007 @ 04:09 PM EST
Maybe some "understanding" between the commission and MS?

we are missing an important piece of the puzzle...

"Interesting times indeed".


Software Patents give Hardware Patents a bad name.

If the Pharmaceutical industry does not want to be included in the backlash...
arrange for a separation.

[ Reply to This | # ]

I can't help being suspicious
Authored by: sbicknel on Thursday, December 20 2007 @ 04:17 PM EST
When Microsoft licensed the Windows 3.1 APIs to IBM so they could enable OS/2
users to run Windows programs on their desktops, it looked like Microsoft was
being very generous.

However, they were already planning on dumping those APIs for incompatible ones
in Windows 95. They knew that being able to run Windows 3 programs on OS/2 would
not matter.

I can't help wondering if the same thing is happening here.

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: Anonymous on Thursday, December 20 2007 @ 04:33 PM EST
Well, this is one squirrel that just fell out of its tree!

Thanks Tridge.

One thought, what does this do for Microsoft's list of patents that it has been
shouting about?


[ Reply to This | # ]

Once Bitten...
Authored by: sproggit on Thursday, December 20 2007 @ 04:36 PM EST
... Twice Shy.

Like many of the people who have already posted comments in response to this
article, I have to admit to certain doubts about the completeness of this deal
from Microsoft.

I would be interested to understand what the terms and conditions are - with
respect to this deal - that require Microsoft to:-

1. Ensure that their documentation remains up to date each time that they
introduce changes to the specification.

2. Guarantee that any such changes will be communicated to this new Delaware
corporation in sufficient time to permit subscribers in the FOSS community to
incorporate any such changes to FOSS implementations.

It will also be interesting to track and change the frequency and extent of
making changes to these protocols. We have speculation in response to this
article that MS will wait for people to complete FOSS implementations before
making changes that effectively enforce the FOSS community to play perpetual

Having said that, one thing that the FOSS community has demonstrated is that it
can be more responsive and productive in terms of developing and releasing
code... so perhaps any such attempts will be doomed to failure.

Here's another thought for you... Many of us [myself included] have long
suspected that MS harvest code logic from the general FOSS landscape. See
earlier posts I have made that show that Microsoft's "Windows Services For
Unix" is in fact based on BSD Unix. So... what's to stop MS from releasing
a specification and then studying the FOSS code that is written to implement it.
I would quite expect the FOSS community to produce top quality code and it
wouldn't surprise me in the least if the FOSS code is better than anything MS
generate, or if MS felt inclined to "borrow" some...

[ Reply to This | # ]

PJ's Parlor
Authored by: webster on Thursday, December 20 2007 @ 04:50 PM EST
1. It is most gratifying to see that the company and chatter in PJ's parlor are
credited with an assist in beginning the negotiation that produced the
agreement. The fare and style are civilized there. Key people with the ability
to reason and act got it done. It is quite a productive mix.

2. The proof will be in the pudding. One can't imagine that the Licensor will
sell a bag of protocols that won't work. What will that say for thier
competence? How do they get their own programs to work with the servers. Will
they continue to deceive? If they fail now with an EC Trustee in their
bathroom, the sanctions will have to be much more drastic.

3. It would seem that this would spur much innovation since many have been
sidelined by the monopoly. It should also benefit the licensor of the API's
since more stuff would harmonize with theirs. They can even get away with more
bundling if others are free to interoperate more readily.

4. Is this a half-step before two steps back? Will the Licensor raise patents
somehow? Maybe if the Monopoly starts to crumble into a small majority, they
would be desperate enough to start delaying with API updates and rattling their
patents. This would frustrate the EC. Patents are a risky game for players on
all sides. Even the Monopoly can have too many fronts. This API matter is
settled. They will watch for a while. Why else would they go this far? There
seem to be many face saving tokens in the agreement. There are also legal
deterrents. It looks like they designed any show-stopper patents out of this.

5. Just as they worked with Monopoly employees to reach this agreement, they
will work with them to implement it. Many employees just want to do their job
well. Corporate battles are above them, lining up code is their thing. Many
work for both sides, burning no bridges, as they climb the promotional ladder.
No doubt the "sinister innovations" are mandated from above.

6. There will probably be a protocol middle program that will allow all Linux
programs to run on Monopolyware soon. What a hoot!

7. A cheer to Messrs. Allison, Tridgell, Barrett, Shank*, Lendeke, Vinje, Mr.
Piana and the Samba Dancers for a tremendous effort. Thanks must also go to the
organizations that made them available and paid them. It is a great victory for
the free world, for men over a tyrant. Translating the technical arguments into
explanations comprehensible by a lay board was an immense accomplishment. It is
like sitting down to write great poetry or good jokes. One can't tell if it
works until it is tried. Making accurate,lucid, persuasive arguments out of
technology and the applicable law is a chore and a challenge. Well done.


[ Reply to This | # ]

Is my paranoia showing in section 7.4 b
Authored by: tdarkelf on Thursday, December 20 2007 @ 05:19 PM EST
Disclaimer: IANAL I am just someone who looks for the worst in people.

Section 7.4- Additional Claims. Microsoft agrees at its expense and Licensee’s request to defend Licensee in a lawsuit ... provided that:

(b) Microsoft controls the defense and/or settlement of the Additional Claim,

Since Microsoft controls the defense AND settlement.
Would it be possible for someone to sue PFIF and when/if Microsoft defendd the suit they settle.
As part of the settlement admits infringement of copyright and/or patents.

The result would be a FOS company (in effect) admitting violating someone IP.
A black mark on open source as a whole.

[ Reply to This | # ]

Microsoft gets paid as a penalty?
Authored by: kh on Thursday, December 20 2007 @ 05:36 PM EST
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.
Only Microsoft could arrange to get paid as part of an antitrust penalty!!! Especially given that most of the protocols come from publicly funded or publicly available standards.

[ Reply to This | # ]

Authored by: Observer on Thursday, December 20 2007 @ 06:36 PM EST

BTW, the podcast with Jeremy Allison is excellent.

The Observer

[ Reply to This | # ]

Authored by: whoever57 on Thursday, December 20 2007 @ 07:12 PM EST
Does this include the protocols used between Outlook and an Exchange server?

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: fredex on Thursday, December 20 2007 @ 07:36 PM EST
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 an area that may be of concern (note that I haven't read the actual agreement yet, only Tridge's summary):

In the future, MS goes through the process to add new patents (for things that are now not prohibited by the agreement) to the agreement. What then happens to pre-existing code that implements/infringes one or more of those patents?

I propose that there needs to be a grandfather clause in there somewhere.... Otherwise it's an un-marked minefield.

[ Reply to This | # ]

After all this time you still fail to understand the Novell deal
Authored by: Anonymous on Thursday, December 20 2007 @ 09:05 PM EST
it's quite sad really.

Either you put blinders on, or you don't want to listen to what it's really

Instead, GL continues to bash Novell for no good reaason.

As a member, I serious wonder why there hasn't been a C&D or slander case
entered against GL, but that's just me.

I don't think it serves anyone to continue to bash Novell for no good reason,
especially since it's obvious that most GL members/readers don't even understand
the deal in the first place.

we've tried explaining it, but no one is listening, seems no one cares. they'd
rather continue their bashing.

After all, where's the fun in a boring story, right?
no sensationalism.

that's ok, this won't get posted.
or if it does, the GLers who don't get the deal will flame it to death

yes, we understand. there there... it will get better.
here, have a cookie...

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: Anonymous on Thursday, December 20 2007 @ 09:21 PM EST
How does this help WINE?

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: Stefan Wagner on Thursday, December 20 2007 @ 10:47 PM EST
Let me guess: 6000 pages? ;)

don't visit my homepage:

[ Reply to This | # ]

Thoughts and suggestions
Authored by: John Hasler on Thursday, December 20 2007 @ 11:28 PM EST
1) PFIF should try to produce at least one reference implementation of each
protocol that is heavily commented and designed to be clear and straightforward
rather than fast and efficient. These can serve as documentation for those who
cannot or will not sign the NDA.

2) A group (completely seperate from and independent of PFIF) should be formed
to "inverse engineer" the above-mentioned reference implementations
and produce Free documentation for the protocols.

3) Wherever it makes sense to do so the protocols as documented in 2) should be
entered into the standards process to become ISO standards.

4) People should be encouraged (though not, officially, by PFIF) to spend time
working with PFIF (and make real contributions), wait out their 90 days, and
join the effort proposed in 2). They should, of course, work entirely from

IOANAL. Licensed under the GNU General Public License

[ Reply to This | # ]

Avoiding patents?
Authored by: leopardi on Friday, December 21 2007 @ 03:19 AM EST

Now that we know what the patents are, how do we avoid them? How do we implement the portions of protocols which are the subject of patent claims without violating the patents? Is there a known technique for this? Or do we still need to have the patents invalidated?

[ Reply to This | # ]

An early Christmas present
Authored by: Anonymous on Friday, December 21 2007 @ 04:52 AM EST
When the settlement agreement was announced I expressed a great deal of concern
about various aspects of the original proposal. I'm staggered by the skill with
which SFLC and the Samba team have negotiated an agreement which
(coincidentally) has addressed the heart of the concerns I have. And I didn't
even include it on my letter to Father Christmas.

Thanks to all those involved and I hope the agreement is a useful tool in
furthering the development of Free Software.

Nigel Whitley

[ Reply to This | # ]

Samba Team Receives Microsoft Protocol Documentation
Authored by: ledow on Friday, December 21 2007 @ 04:55 AM EST
Oh, well done everyone involved. I've only half been paying attention to this
case because I imagined that MS would never be made to release anything that it
didn't want to and we'd only end up with a bare scraping of some SMB/CIFS basics
that we already knew, but in a cryptic format.

But looking through the list: AD Authentication, Group Policy (BIG, BIG issue
for running servers that control Windows stations with very, very little Open
Source success at the moment), Netlogon protocols, even down to the new realms
of "Network Health" (i.e. preventing network access to infected / old
/ obsolete / insecure machines). Plus provisions for some other stuff that's
gonna be in Server 2008.

With patent protection (in the form of a guaranteed list of patents that we are
safe once we avoid... at least from Microsoft... obviously it wouldn't stop
someone like, erm, Novell from suing for breach of their workgroup server
patents), OS-compatible (if not friendly) provisions, one-off licenses and a lot
of guarantee over future behavious (EC complaints procedures, notification of
changes to patents, the RAND side of things etc.). Just the fact that this
suggests that the EC will be watching is a step up, I thought that they would
have abandoned their involvement much earlier and then this
"five-year" license would turn into 5 minutes of useful collaboration
and the rest would be spent arguing with MS over the exact terms of the

Perhaps MS got stung a lot harder than it thought it could be - I've certainly
not seen such co-operation from MS in any field for a very long time. And when
you're working against lawyers hired by the company owned by the most expensive
man in the world, it's no mean feat to be able to not just win the case but win
it with a lot of positive outcomes for yourself and everyone else.

Now the next question is... when do we get the docs, how soon can we turn that
into code and when can I finally replace the incredibly expensive Server
products and their overbearing licenses in order to interact with networks that
are specified as being Windows-only? I run networks in schools and this may be
the biggest step forward for computing in education for a long time - at last we
might be able to have Windows on the desktop to please all the educational
software developers / school management and Linux on the back-end to please all
the technicians / bean-counters!

[ Reply to This | # ]

did Samba just get a little less open?
Authored by: Anonymous on Friday, December 21 2007 @ 05:12 AM EST
"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."

How can "many eyes [make] all bugs shallow" if the spec is hidden?

[ Reply to This | # ]

Where are the trolls, there ought to be trolls, well, maybe next year.
Authored by: Ian Al on Friday, December 21 2007 @ 06:32 AM EST
It's a good thing. Thanks and congratulations to those who got this for us and
those who helped.

I counted only one troll. This has got to be seriously damaging for Microsoft's
business plan. The patent FUD has been herded into a corner, at least for this
issue, and will be dispatched with a bolt gun. A Christmas gift to the US to
make up for their flawed software patent regime, perhaps! I expected more trolls
as with the Opera issue. Perhaps they are too stunned to comment.

Ian Al

When nothing else makes sense, use Linux.

[ Reply to This | # ]

Second update: 14820 pages
Authored by: PolR on Friday, December 21 2007 @ 06:32 PM EST
This is a little more than twice the size of OOXML.

[ Reply to This | # ]

Funny thing.
Authored by: Anonymous on Friday, December 21 2007 @ 07:18 PM EST
I never expected Loons to be delirious about at last being able to do exactly
what Microsoft wants them to do.

[ Reply to This | # ]

It won't be over until there are at least 2 implimentations
Authored by: kh on Saturday, December 22 2007 @ 06:28 AM EST
Since it has been documented (and Microsoft has effectively admitted) that
Microsoft has obscured the protocols for servers and has patents even to stop
competition in that area, I still think that we can't say it is over until there
are at least 2 working implementations.

[ Reply to This | # ]

Samba 4 Impact?
Authored by: geste on Saturday, December 22 2007 @ 01:25 PM EST

I am a grateful user of Samba 3.x. We use it with a Fedora Directory Services LDAP backend for my organization of around 350 people. This announcement is great news and I want to congratulate the Samba team for their staying power and continued work.

Sometime before January 1, I plan to run up a Samba 4 domain in our test environment. So my question is: "To what extent does this new agreement help with the team's development of Samba 4?" I sometime have a hard time teasing out the different elements at play in SMB services. Will the team pursue further disclosure agreements related to Samba 4 and post-NT4 AD-type services/protocols? Or is this even needed?

Not sure if this is a point best discussed on Groklaw, but, other than the announcement on, I did not see discussion of this on the main samba mail list.

Thanks again to everyone who helped make this happen!

[ Reply to This | # ]

Authored by: grouch on Saturday, December 22 2007 @ 05:51 PM EST
This is an extremely impressive body of work! The details about the negotiation, given by Tridge and Mr. Piana, should dispel any fears that the agreement contains gaping loopholes which seem typical for agreements with Microsoft. (Perhaps the DoJ should take lessons from this crew on who to involve in negotiations regarding software). The collaboration among developers and lawyers is remarkable. It looks like the best expertise available was brought to bear on this agreement!

(I know; everybody else has moved on. I'm not a speed reader, so it took me a while to absorb all this).

-- grouch

"People aren't as dumb as Microsoft needs them to be."
--PJ, May 2007

[ Reply to This | # ]

What they document may not be what works well...
Authored by: xtifr on Monday, December 24 2007 @ 01:47 PM EST

Back when WordPerfect was still a contender for mainstream market share, MS came out with a new system, WindowsV3, and documented how it worked so that ISVs (Independent Software Vendors) could write software for it. The only problem was: the protocols they documented were not the ones that they,themselves, used. They worked, but not as well as the hidden, secret APIs which MS's own software used. So when software which competed with MS's offerings came out, it was slow and awkward and ugly compared to MS's. And lo, MS grew and their competitors fell.

Traditionally, the only way to find out which MS protocols were both stable and useful was to reverse engineer their software to find out which ones their own software relied on. (And even that could be iffy.) How do we ensure that isn't the case in this case? What will the Samba team do if the protocol documented by MS doesn't match what's been reverse-engineered off the wire? Trust MS? Or stick with what's actually known to work and work well?

Obviously, the way I phrased the question makes the proper answer seem obvious, but is the Samba team really viewing it that way?

Do not meddle in the affairs of Wizards, for it makes them soggy and hard to light.

[ Reply to This | # ]

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 )