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.
Settlements
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 PFIF
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.
Patents
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'.
Residuals
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.
|