Month: September 2006

Readers may be interested in Andy Updegrove‘s analysis of the Open Specification Promise (OSP).  He published it today on Standards Blog.  I'm not a legal expert but found the discussion interesting.  The Standards Blog “examines how standards are developed, and their impact on business, society, the world, and the future.”  Frighteningly, it tells us there are currently over 1,000,000! 

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.

Overall, I am 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.