Glyn Moody has written a post about a system called U-Prove. Glyn notes that the software is being licensed under a BSD licence and notes that is a good thing, but then observes that there is a patent encumbrance on the code, and indicates this is a bad thing. In a comment, Sam Ramji refers off to this article of mine, kindly remarking it is a ‘good post’.
The essence of Glyn’s argument is that the OSP does not preserve the freedom of free software, so it is not sufficient. Sam appears to be adopting my comments to the effect that it’s hard to single out one company for the patent blame game.
In the context of free software patents are problematic. In the ideal world patents on software wouldn’t exist and there wouldn’t be a problem. However, they do exist. Moreover, part of the reason they exist is because of a variation of mutually assured destruction – many businesses believe they need to acquire patents in order to defend against other patents.* Jonathan Schwartz sets out some of the sad, tawdry circumstances in which this logic plays out here.
I think it is a non trivial problem to find wording which preserves just the defensive potential of patents (which, is actually their offensive potential limited to specific circumstances of exercise) while preserving freedom when licensing software. Some of the more detailed free software licences attempt this. It is, I think, a more difficult problem to craft such wording to apply to standards – because standards purport to be agreed by some collection of people, while freedom requires that everyone be permitted to pursue their own goals. Thus, any ‘promise’ or ‘covenant’** which is limited to an agreed specification must necessarily be inconsistent with freedom in a way qualitatively different to a patent clause in an open source licence. Moreover, any wording which applies to a particular version of a specification will be inconsistent with the evolution of that specification. In short, promises made in relation to specifications are likely to always be problematic (the best to hope for is a disclaimer – per W3C).
Therefore, if the words themselves are likely inadequate, the issue of who is saying the words, and what one can reasonably read into them becomes much more important. In the OSP post that Sam refers to I explicitly reference another, earlier, article on the OSP which calls this issue out. With this in mind, I note that Microsoft has recently chosen to specifically draw out the Linux/open source angle in its cross licensing deals with Amazon and IO Data. It didn’t need to, but presumably chose to. It seems reasonable to conclude this is signaling. These are grounds that would justify a reasonable person finding the OSP inadequate.
If Microsoft wants people like Glyn to trust them, they should perhaps incline against, rather than toward making the will to contend by battle […] sufficiently known.
* This, by the way, is much the same argument used by Hobbes in favour of the need for a common power to counter the war of all against all (hence the quote above). In this case however the common power (parliament) rather than saving us from a state of war of all against all has plunged some of us into a version of it.
 ‘…said Horacio Gutierrez, corporate vice president and deputy general counsel, in the news release. “Microsoft’s patent portfolio is the largest and strongest in the software industry, and this agreement demonstrates … our ability to reach pragmatic solutions to IP issues regardless of whether proprietary or open source software is involved.” The press release is here, it doesn’t fall over itself as much as the IO Data one below.
 ‘...said David Kaefer, Microsoft general manager of intellectual property, in a statement announcing the latest deal. “Microsoft has a strong track record of collaboration with companies running Linux-based offerings, and this agreement is a reflection of our commitment to partner with industry leaders around the world.” ‘ In fact, on Microsoft’s press release page (at 12 March 2010) the call out comprises of the words: “I-O Data customers will receive patent covenants for their use of devices running Linux and related open source software.” The press release is at pains to refer to it.
Knock me down with a feather – apparently the OSP covers the GPL.
Q: I am a developer/distributor/user of software that is licensed under the GPL, does the Open Specification Promise apply to me?
A: Absolutely, yes. The OSP applies to developers, distributors, and users of Covered Implementations without regard to the development model that created such implementations, or the type of copyright licenses under which they are distributed, or the business model of distributors/implementers. The OSP provides the assurance that Microsoft will not assert its Necessary Claims against anyone who make, use, sell, offer for sale, import, or distribute any Covered Implementation under any type of development or distribution model, including the GPL. As stated in the OSP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft’s implementation of the same Covered Specification. This type of “suspension” clause is common industry practice.
Any statement from the authors of the OSP to the effect that it covers GPL implementations is a good thing. Indeed, I called for something much like this in February (actually, I asked for the addition of “A: yes” in the GPL question, but they’ve opted for “A: Absolutely, yes” instead). However, given the history of this issue it is best to receive it with at least some caution. Over an extended period during the passage of DIS 29500 through ISO the shepherds of DIS 29500 were repeatedly invited to make a statement about the OSP’s coverage of GPL implementations. They repeatedly declined to do so, including an express statement of GPL ignorance in the OSP FAQ. As recently as a month or so ago the Australian arm was bravely reiterating the ignorance line.
Now, apparently, it has always been exceedingly clear that the OSP covers GPL implementations. Had this been conceded twelve, or even six months ago it would have saved a lot of people a lot of heartache.
It is certainly good to see this concession to the GPL in the FAQ as well as other indications that the OSP may become free software compatible. We should ask whether this alone is sufficient or whether more would be required before covered specifications can be considered to be interoperable with free software.
One of the reasons that the GPL ignorance line was trotted out for so long might have been concern over the the SFLC’s criticism of the OSP. To put it in simple terms, the OSP does not travel with the code. So writing a (eg) GPL* implementation of an OSP covered specification in the expectation that the code may be re-used for other things (which is a cornerstone of interactions in the free software community) creates a problem. That code becomes encumbered by a patent mine which arms itself when the code is (non-conformingly) reused. At best, even with this addition to the FAQ, the OSP still fails to respect the freedom of free software implementations (whether GPL or otherwise) of covered specifications.** It is unclear, for example, what effect the “no surrender of others’ freedom” clauses of the relevant GPLs would be in the event of a successful patent action against a non-conforming implementation.
Aside: Given the clauses in GPLv3 relating to patents and discriminatory patent licences (and the fact that many GPL v2 licences permit “GPL v 2 or later” licensing) it is an interesting question as to whether this endorsement of the use of the GPL will have broader impacts on the patents related to the covered specifications.
In one sense this is a problem created by a defective patent law, rather than the terms chosen by any one company. In that sense, it would not be appropriate to criticise any particular company for granting a patent licence in terms similar to those used by other industry participants (at least, that is, if the other industry participants had expended the same amount of effort to threaten the open source ecosystem with patent liability).
* The GPL is used here only for convenience, the effect seems to be independent of the particular licence.
** There is a blog post by Richard Wilder (the link I was first given for this article has 2008/7/25 in the link, but the same article appears to be served for links with this replaced by x/y/z where x > 1000, and y and z < 100) described by Sam Ramji as a “clarification of the OSP” which discusses partially conforming implementations. It is not clear what the status of this post is in varying or affecting the interpretation of the OSP, but let’s assume it is a binding statement. I am not sure I fully understand the context, but the focus of the post seems to be on implementations which are a subset of the full specification covered by the OSP. While it mentions non conformance due to bugs it seems to indicate that if the bug-affected parts are therefore non-conforming then they will not be covered by the OSP (although the OSP coverage of the conforming part of the implementation will not be affected). If this reading is correct, then presumably the same logic would apply to non-conforming parts which are due to a modification of code made in the exercise of a person’s freedoms.
I have not seen any official document summarising the outcome of the OOXML seminar at UNSW last year. However, the main thing that I have heard unofficially in relation to the open specification promise is that pains were taken to compare its wording to the wording of similar promises made by IBM.
To make such a comparison presupposes that when two people say the same thing they ought to receive the same reception. Is this justified?
Microsoft chief executive Steve Ballmer has warned users of Red Hat Linux that they will have to pay Microsoft for its intellectual property.
So the two top level points [about the Novell-MS deal], as Ron whispered to me, technical interoperability and patent peace of mind, and we’re trying to provide both of those things to our customers in a way that works for the business interest of the open source development community, and the Microsoft development community. – Steve Ballmer at the Press Conference announcing the Novell-MS Deal.
For those who have access to Google, there are others in a similar vein. Perhaps those who are not in the open source community will not be as aware of this history.
Two people want to come onto your land but you’re concerned that they don’t fish in your lagoon. The first one has spent the last 18 months talking about how he has rights over those fish and he’s mapped out a strategy to get them and if you want peace of mind you’d better give him some of those fish. The second one has made some non specific noises about fish and some off hand comments to the effect that fish ought to be left alone. Both of them tell you if they come on your land they won’t fish in the lagoon.
Should you take each of them at their word equally or should you be more cautious with one of them?
Microsoft’s Covenant Not to Sue (CNS) – except that the covenant doesn’t appear to be there anymore. The URL redirects to a site about the ECMA process. The page mentions the CNS, but doesn’t provide (as far as I can tell) any way to get there. The current URL might be here but who knows?
There are some analyses of the CNS and OSP floating around out there. I don’t intend to repeat the issues here. Rather, I thought I’d approach it from the point of view of the cynical pedant reasonable developer who is considering implementing OOXML or part of it. These are off the top of my head thoughts unsupported by anything in the way of research…. perhaps a better knowledge of US law or ISO rules might clear some of these issues up? So, what are some observations we can make about the CNS and the OSP?
First, they are both given by Microsoft. Given that “Microsoft” is a number of different companies (and other structures – MS Licensing GP) within a broad corporate group the fact that these are given by “Microsoft” is less than completely illuminating. Presumably they mean Microsoft Corporation? This becomes particularly relevant because the scope of the promise/covenant is limited to the patent claims held or controlled by “Microsoft”. To be meaningful a person relying on these claims would need to be able to assess exactly which patents were held or controlled by Microsoft. The prudent developer at this point would try to identify how patents are held within the Microsoft corporate structure.
Second, both the CNS and the OSP are limited to patent claims – which seems to be inadequate. I understand, for example, that “microsoft” appears in part of the OOXML namespace, so presumably trademark issues will arise. It seems hard to believe a decent copyright lawyer could not also construct a copyright case in respect of the specification per se. Perhaps there is some ISO rule which covers these aspects?
Third, both are silent as to the time at which the ownership or control of the relevant patents is to be assessed. If Microsoft controls a patent today, but that control ceases tomorrow, can an implementer breathe easily or not? Is there scope for Microsoft to sell a patent to someone like Acacia Research Corporation and for them to then be able to assert that patent against implementers of the standard?
Fourth, and leading on from the third, neither is expressed as a licence. While Microsoft had the luxury of being able to use words such as “permit” or “license” they specifically chose not to. Rather, they structured the statement as a forebearance from suit. The reason for this is unclear, but it does seem worthy of further thought. What if the effect of this structuring is to preserve the underlying rights including the right to sue? If that were the case, then the right would stay alive if transferred to a third party. The third party, which has not given any such covenant would therefore be at liberty to commence suit.
Can Equities Prevent Sharp Practice?
Fifth, each document has a rider excluding other rights including rights by way of estoppel (the OSP words are “No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppel, or otherwise”). You might think that transferring a patent to a third party in order for that party to sue under it was sharp practice and surely there would be an equity that would stop it. Who knows? Could the exclusion wording in the CNS/OSP be used to argued against such an equity? If the CNS/OSP is considered at law to be a licence then a third party would be in a much worse position as the developer could plead a valid permission.
Sixth, and also leading on from the third, if the OSP/CNS are not licences within the meaning of the patent law (something I express no view on at the moment other than to return to the observation above that the word “license” could have been used and wasn’t) then they will be inadequate in any jurisdiction which has criminal penalties for patent infringement. The reason being, that a private party cannot waive the commission of a crime. That is something for the State. That is, if the patent is not a licence, then the relevant conduct will be infringing conduct, albeit not actionable in a civil action by virtue of the OSP/CNS. If the conduct is criminal in the absence of a licence, then a promise not to sue will not convert the criminal conduct. That is, there is no way to rectify criminal conduct after the fact. Rather, the conduct must be licensed beforehand so that the conduct does not become criminal.
Seventh, both expressly refrain from making any statement that OOXML is free from third party patents. This is hardly surprising given that both are designed to apply to a number of different specifications rather than just OOXML. However, this raises the issue – what assurance does a developer have that such a large specification is not the subject of third party patent claims? The pedigree of the specification is certainly no reason for hope, Microsoft has been the target of third party patent claims for some time now including some high profile losses in patent suits. The fact that the specification has been developed behind closed doors and on a fast track means that there has been no adequate opportunity to evaluate the likelihood of third party patent claims against the specifications. The sheer size of the document suggests there will be at least a couple hiding in there somewhere.
Eighth, both lack any feeling of warmth. Each has been drafted by lawyers, is designed to be used for a number of different specifications and to give rights only over what is absolutely necessary. In short they are clinical documents – not the sort of things which inspire trust.
Ninth, the ISO is apparently happy, having reviewed the OSP, to sprinkle the holy water on it and absolve OOXML of any IP issues (I understand that this is on the basis that the OSP meets the ISO’s requirements for IP licensing). On this we must give pause to consider exactly when the ISO requirements for IP licensing were last reviewed. If they don’t cover copyright and trademark issues (which, since the OSP is a patent only document, they don’t appear to) surely they must be in need of a refresh?
Exactly what is the effect of these words: “you acknowledge as a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise”. Thoughts?