Microsoft has just posted the text of a new patent "promise not to assert " at its Website, and pledges that it will honor that promise with respect to 35 listed Web Services standards. The promise is similar in most substantive respects to the covenant not to assert patents that it issued last year with respect to its Office 2003 XML Reference Schema, with two important improvements intended to make it more clearly compatible with open source licensing. Those changes are to clarify that the promise not to assert any relevant patents extends to everyone in the distribution chain of a product, from the original vendor through to the end user, and to clarify that the promise covers a partial as well as a full implementation of a standard.
I learned about the new covenant from Microsoft yesterday, which provided me an advance copy of the covenant and the FAQ that accompanies it and an opportunity to ask questions about what it is intended to accomplish. I did have a few requests for clarifications that I'll incorporate below which may resolve some of the questions that might occur to you as well.
Of course, Microsoft (along with IBM and BEA) proposed most, if not all, of these standards to begin with, but I am still impressed with the new covenant, and am pleased to see that Microsoft is expanding its use of what I consider to be a highly desirable tool for facilitating the implementation of open standards, in particular where those standards are of interest to the open source community.
By way of general introduction to those not familiar with this type of mechanism, a non-assertion covenant (also sometimes called a “covenant not to sue”, or in this case, a “promise not to assert”) is at minimum a pledge given by a patent owner that someone that implements a standard will not be sued for doing so by the patent owner, subject to certain limitations. In effect, it is similar to the more traditional promise given by companies when they engage in the development of a standard, but with several important differences:
1. Instead of reserving the right to require each implementer to agree to the terms of a license agreement of the patent owner’s choosing, the promise is “self-executing,” meaning that the implementer doesn’t have to do anything at all, except stay within the conditions of the covenant. Where, as with the new Microsoft promise, it is explicit that no one down stream need obtain a license as well, a key requirement of many of the most popular open source licenses is met as well.
2. Unlike the usual promise to license on RAND (“reasonable and non-discriminatory”) terms, where the terms themselves are almost never made public in advance, and often never at all, all of the terms in a non-assertion covenant are out in the open, and apply equally to all. When such a promise is made before the standard is approved, that’s even better, because there has been an increase in the number of disputes lately relating to whether the terms actually offered by a patent owner that has made a simple RAND promise have in fact been reasonable (for more see this blog entry , as well as this one).
Such covenants and promises, when they go far enough, are essential to the implementation of open source software under the most popular open source licenses, and as you’ll see from the Microsoft Web page, it has gone to the trouble of consulting with a number of members of the open source community in advance regarding the specific wording of the new promise, and has secured approving quotes from two of them: a commercial customer (Red Hat) and a respected open source authority (Larry Rosen).
Promises and covenants such as the one that Microsoft has announced today have historically been unusual, but have lately been made more frequently, especially after IBM made a well-publicized promise not to assert 500 patents against open source software. Similar promises followed from Sun Microsystems, Nokia and Oracle, among others.
That being said, of course, the specific details of a non-assertion covenant are extremely important, and the wording of each promise made to date by a vendor has varied, sometimes simply to reflect the favorite phrasing of its legal advisors, but often in important ways as well.
With this as an introduction, let’s take a look at the new Microsoft promise, both on an absolute as well as comparative basis. Here’s what it says, and what I take it to mean:
Microsoft irrevocably promises…
While there are some ongoing issues that relate to all such covenants, and to regular standard setting promises as well (is the promise binding on someone to whom the vendor sells the patent?), the word “irrevocable” is the important one, and represents the desired pledge that the promise may not be later revoked, although the statement might better have been worded “Microsoft irrevocably promises (except as provided below),” because conditions do apply that would void the promise if violated by someone relying on the promise.
…not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation….
As noted earlier, the explicit downstream promise is helpful (Necessary Claims will be defined later in the text). But note that the same conditions apply to those downstream as to the original party.
…to the extent it conforms to a Covered Specification (“Covered Implementation”),…
The new promise relates to 35 standards, and may be extended to others in the future. It appears that the promise is a “base level,” because additional assurances may be added with respect to future versions of the same standard. According to the FAQ that accompanies the new language, the phrase “to the extent” is meant to include partial as well as full implementation of a standard, a grant of rights that goes beyond what many standards organizations require as a pre-condition to a patent owner making its patent claims available to implementers.
…subject to the following. This is a personal promise directly from Microsoft to you, and you acknowledge as a condition of benefiting from it…
While the promise is irrevocable, it is not unconditional. In order to enjoy the benefits, an implementer must accept the terms that follow.
…that no Microsoft rights are received from suppliers, distributors, or otherwise in connection with this promise….
This limitation is actually less important than it might at first seem, since the definition of “Microsoft Necessary Claims” that appears later clarifies that Microsoft is, in fact, also pledging rights under patents that it “controls” as well as owns. Presumably this would include third parties to the extent that it is able to do so under license agreements or other rights granted by third parties as well as with respect to patents owned by controlled subsidiaries of Microsoft, but that would be a good subject for an addition to the list of FAQs.
…If you file, maintain or voluntarily participate in a patent infringement lawsuit against a Microsoft implementation of such Covered Specification, then this personal promise does not apply with respect to any Covered Implementation of the same Covered Specification made or used by you….
This provision goes by a number of names, one of which is “defensive revocation,” and represents an exception to the introductory “irrevocable” promise. It is extremely common in standard setting and can have benefits to all implementers, who may benefit indirectly from the revocation of the rights of use of someone that is bringing infringement suits against other implementers. The addition of the new language that runs down the distribution change is helpful in the context of open source, since someone that loses its rights will not result in the loss of someone downstream that does not join in the law suit.
…To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement…
The inclusion of “Microsoft-controlled” patents is notable, as not all standard setting organizations require a member to disclose or license such claims. Absent this language, implementers would want to be sure to understand the intellectual property rights (IPR) landscape relating to the standard in question if, for example, it was based upon a submission made by Microsoft that included any third-party rights.
… only the required portions of the Covered Specification…
This is the degree to which the great majority of standards organizations require a commitment. However, in a given case, an implement needs to be careful to understand how complete a standard may be, and how the standards organization in question defines “required,” which can be more or less extensive, depending upon the organization.
…that are described in detail and not merely referenced in such Specification….
While not usually phrased in this fashion, this is a common limitation intended to clarify that, for example, other standards that may be referenced, or so-called “enabling technologies,” the use of which would be required to use an implementation (e.g., the computer upon which the software is running) are not included.
…”Covered Specifications” are listed below….
To begin with, the 35 listed Web Services standards.
…This promise is not an assurance either (i) that any of Microsoft’s issued patent claims covers a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe patents or other intellectual property rights of any third party. No other rights except those expressly stated in this promise shall be deemed granted, waived or received by implication, exhaustion, estoppels, or otherwise.
This is the standard “boilerplate” language that keeps lawyers happy.
The FAQ provides additional details, although in a few cases, I found that they raised questions rather than resolved them. Here are two with respect to which I requested clarification, and what I learned:
Q: Does this OSP apply to all versions of the standard, including future revisions?
A: The Open Specification Promise applies to all existing versions of the specification(s) designated on the public list posted at http://www.microsoft.com/interop/osp/, unless otherwise noted with respect to a particular specification (see, for example, specific notes related to web services specifications).
The key word here is “existing,” which in context means “now existing.” The question thus arises, what about future versions of the same standards?
As with traditional standard setting commitments, patent owners are wary about making open-ended promises, since in an extreme case a competitor could seek to extend a standard to describe part of, or all of a product of a patent owner, going far beyond what had been anticipated by the owner at the time that it made its commitment. Although there are differences from organization to organization, typically when a new version of a standard is approved, a member remains bound by so much of the standard as does not change, but is not bound by any new material that is added to it unless it is then a member, and agrees to do so.
And that is what Microsoft is committing to do, when you read the note at the top of the table of standards to which the pledge applies. For a comparison, see the language in the Sun ODF covenant, which is analyzed here.
I also asked about this FAQ, which I found to be rather opaque:
Q: If a listed specification has been approved by a standards organization, what patent rights is Microsoft providing?
A: We are providing access to necessary claims consistent with the scope of our commitments in that organization.
Would this mean, for example, that if Microsoft had pledged less to a standards organization, that only the lesser pledge would apply? The response was no, just the opposite. The example given was that if a definiton of “required portions” was more liberal within a given standards organization than another, in each case, the definition of the applicable organization would control. In other words, the Microsoft promise would incorporate the definition of the standards organization in question. Microsoft would also continue to honor the commitments that it made in any organization of which it was a member, and would therefore continue to provide an actual license, if requested, by any implementer that desired one (as some will), to the extent that it had previously committed to do so.
Exactly how open source friendly is the new language? The FAQ is surprisingly cautious on that score, reading as follows:
Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?
A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).
On a first read, this seems pretty modest, and it will be quite interesting to see the reactions that the new language draws. If a given specification is not well detailed and will need lots of work in the future, then the pledge will only work well for so long as Microsoft stays involved with that standard. More significantly, the pledge only relates to “compliant” implementations, which does run afoul of the open source right to change anything. From a standards point of view, that serves a purpose, as it furthers the spread of interoperable implementations, which is what standards are all about. That works well from that perspective, but may leave some open source advocates less happy. Still, nearly all standards obligations are so limited, so to the extent that this limitation is regarded as unfortunate, the same objection could be made against nearly other vendor as well.
Be that as it may, I think that this move should be greeted with approval, and that Microsoft deserves to be congratulated for this action. I hope that the standards affected will only be the first of many that Microsoft, and hopefully other patent owners as well, benefit with similar pledges.
Note: While I provide legal services to a variety of standard setting organizations (including OASIS, which has set many Web Services standards), the opinions expressed above are mine alone. I have not been consulted by OASIS or any of my other standards clients in connection with the new Microsoft covenant.
For further blog entries on Intellectual Property Rights, click here
subscribe to the free Consortium Standards Bulletin
(and remember to Buy Your Books at Biff’s)
To anonymous: You’re missing three important detail here:
– This has nothing at all to do with ODF, but with 35 other standards
– This has to do with standards, not code
– This has to do with 35 standards that Microsoft wants you to use, and that you don’t have to, as compared to OpenXML, where the specification was offered to Ecma as a defensive strategy against ODF
– Andy
There is some concern among interested parties about the intent of the word “required” in this phrase:
“only the required portions of the Covered Specification”
In your commentary you say:
“This is the degree to which the great majority of standards organizations require a commitment.”
I’m aware of the IPR policies of some standards organizations, and can’t find any instance of this kind of qualification. It is not even clear what “required” is referring to. Some standards include both required and optional features, but it is typical that for an implementation to be useful it must support all the specified features, required and optional. A patent grant that only covers required features simply doesn’t do the job.
Someone said the correct interpretation of “required” is “those portions required by the implementor” which might make some sense but seems redundant.
Can you comment more on what you think “required” means in this statement?
– RL “Bob” Morgan (who would have authenticated to post if the system had sent his password)
I think that if you look at more IPR policies, you’ll see that this is in every single one of them, although you may not be looking in the right place. You can find hundreds of such policies by browsing through my listings here, if you’re really bored some time. I expect that I’ve read well over 200 IPR policies over the years, and have drafted at least 35 of them, and negotiated them (at least once, and as many as 25 times) with just about any technology company that you can think of that takes these matters seriously enough to bring their lawyers into the process (for proof, see gray hair at temples on picture above; I’m actually only 23 years old).
In fact, there is a wide variation in what “required” means. In the majority of IPR policies, “required” means what you’d expect – those parts of the standard that are essential to achieve the level of interoperability that is needed to make the standard “work.” There are some standard setting organizations, however that find it necessary, either rarely, or regularly, to make compromises. One example is where, in order to achieve consensus, or for legitimate reasons, they may approve two alternative ways to meet one or more elements of the specification. In those cases, they will (if they are doing the job right) define “required” to include not only those elements where there is a single way, but also those elements where more than one way of complying is required.
There are a few organizations, usually with fewer members, and therefore where it is easier to get members to make stronger commitments, that define “required” as meaning anything in the spec. But there aren’t many of those.
It’s also important to note that specificaitons only go so far. It may be that an implementation of a specification may be totally useless without additional, non-pledged patented technology. Like, for example, a computer.
Ok, that’s a silly example. But where do you draw the line between the silly example, and the clear example, where the standardized technology is useless without something more, that is just an appendage to the standard, with no independent utility? And what do you do about the “extensions” that may be created by dominant players, that become de facto “standards” in their own right just because so many people but the monopolist’s products?
Those are tougher questions. And, unfortunately, the current standards system has no very good answers for them.
– Andy
Unfortunately, I’m handicapped by two things: not being technically competent to answer, as well as not knowing much about the individual standards themselves, so you’re way ahead of me on both of those scores.
I think it’s also worth noting that the story could, to a greater or lesser extent, be different for each standard – MS may have no incentives to play games with some, but may have temptations, intentions, or better technical opportunties with respect to others.
Another thing that I think is worth taking into account in this case is the fact that many, if not all, of these standards were joint submissions by Microsoft, IBM and BEA – the so-called “Men in Black.” One could assume that with billions at stake on this initiative, as far as staking their future business, IBM would have done their homework and their negotiating with Microsoft pretty thoroughly before going forward.
All of which isn’t to say that Microsoft is entitled to expect anyone not to take past behavior into practice, or course. All I can give my opinion on is how good the language is – which is my area of competence. I’ll need to leave to others that are more knowledegeable about the software and the specifications themselves, such as yourself, to suggest what the potential for mischief may be when it comes to the technical particulars of each standard.
Thanks for the comments
– Andy
Making SOAP in and of itself available is not an empty
promise. Yes, you can use SOAP to deliver proprietary data formats, but
you can also use it to deliver all sorts of open standard formats as
well as your own home-grown formats. Giving developers a guarantee of
freedom to use SOAP is not nothing.
Just because you’ve given somebody a bucket doesn’t grant them the right to carry off anything they want from your store without paying for it. Nevertheless the bucket has value. They can use it to transport their cow’s milk for sale to a neighbor. But you haven’t given them the milk. Just the bucket.
I would be the first to agree that Microsoft has a history of
misleading PR and maintaining dominance through vendor lock-in. But I don’t see your objection about wrappers as an example of that.
And I believe it’s actually possible for companies to change. Bill Gates may not change much, but old leaders leave, new ones are hired, and new perspectives creep in. Look at IBM, the former monopolizing monolith, now promoting all sorts of open standards and patent pledges. Do you think IBM is insincere in its support for open standards?
Lars