NOTE: The Microsoft covenant that is analyzed below has been amended several times by Microsoft. As a result, the promise at is appears at the Microsoft site is not identical to the one that I reviewed in writing this post. Further, there is no change history at the Microsoft site. As a result, the following analysis is no longer complete or current, and should therefore not be relied upon.
In a previous post, I compared the Microsoft XML Schema covenant not to sue with that offered by Sun in favor of ODF, and concluded it fell short. But how does Microsoft's covenant compare to its old XML Schema? From that perspective, its a real improvement.
Earlier this week I posted an analysis of the “covenant not to sue” announced by Microsoft with respect to their XML Reference Schema formats. The release of that covenant followed closely on Microsoft’s announcement that it and a group of allied companies would submit the XML formats to Ecma International, a European standards body to form the basis for an Ecma standard that would in turn be offered to ISO for adoption.
In that blog entry, I compared the commitment and impact of the Microsoft covenant to that of the covenant earlier announced by Sun in support of the OpenDocument OASIS Format standard (ODF), concluding that the Microsoft action, as a practical matter, fell short in a number of respects, when viewed from the perspective of an ISV or customer that needs to decide today which horse to bet on.
Some of my friends at Microsoft thought that this was an unfair way to present the covenant. By comparing the Microsoft covenant to Sun’s, I was necessarily ending up with a “glass half full” result. Instead, they thought I should have provided an analysis of the covenant solely on its own merits.
This strikes me as a fair request, so in order to present a more balanced picture, in this post I’ll look at the Microsoft covenant from the following perspective: how much better is the new covenant than the old 2003 XML Reference Schema license? At the end of this entry, I’ll then try and reconcile the two analyses and see where we come out.
So here we go. The existing XML license, you may recall, already represented an effort by Microsoft to loosen up its intellectual property rights in the XML Schema, in particular in response to the government customers that are now showing the most interest in ODF. As revised in November of 2003, the XML Schema license was also royalty free. But that applecart was upset this September, when the Massachusetts Information Technology Department (ITD) announced that it found the Microsoft license insufficiently open to meet the ITD’s new policy. The action was doubly stinging, because earlier in the process Microsoft and the ITD had reached a non-specific understanding that Microsoft would make the changes necessary in order to make its XML Schema licensing terms acceptable (the ITD later concluded that the changes offered did not go far enough).
The bottom line when comparing the old licensing regime and the new covenant is that the covenant represents a substantial improvement for developers and users. Here are the important differences:
A. A covenant not to sue of this type is self-executing. In other words, there is no need to go to a website and agree to the terms of use in order to benefit from the license, either through a clickwrap agreement, or (in the case of the old Microsoft license) by including a required notice in any software that a developer distributes, licenses or sells.
B. The principal concern of open source developers under the old license (the restrictions applicable to “downstream” parties) disappears, because the downstream party automatically has its own license under the covenant. Here is the old language:
If you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed in all copies and derivative works of your source code and in copies of the documentation and licenses associated with your Licensed Implementation:
“This product may incorporate intellectual property owned by Microsoft Corporation. The terms and conditions upon which Microsoft is licensing such intellectual property may be found at http://msdn.microsoft.com/library/en-us/odcXMLRef/html/odcXMLRefLegalNotice.asp.”
By including the above notice in a Licensed Implementation, you will be deemed to have accepted the terms and conditions of this license. You are not licensed to distribute a Licensed Implementation under license terms and conditions that prohibit the terms and conditions of this license.
You are not licensed to sublicense or transfer your rights.
The last restriction – the inability to sublicense – was particularly problematic for the open source community.
C. There are no longer any restrictions on the uses to which the specifications may be used. The old license, for example, includes this language:
Except as provided below, Microsoft hereby grants you a royalty-free license under Microsoft’s Necessary Claims to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations solely for the purpose of reading and writing files that comply with the Microsoft specifications for the Office Schemas. A “Licensed Implementation” means only those specific portions of a software product that read and write files that are fully compliant with the specifications for the Office Schemas.
Microsoft had included a limited carve-out for its government customers, as follows:
By way of clarification of the foregoing, given the unique role of government institutions, end users will not violate this license by merely reading government documents that constitute files that comply with the Microsoft specifications for the Office Schemas, or by using (solely for the purpose of reading such files) any software that enables them to do so. The term “government documents” includes public records.
All this is now swept away. The correlative language in the new covenant simply says:
Microsoft irrevocably covenants that it will not seek to enforce any of its patent claims necessary to conform to the technical specifications for the Microsoft Office 2003 XML Reference Schemas posted at http://msdn.microsoft.com/office/understanding/xmloffice/default.aspx (the “Specifications”) against those conforming parts of software products.
In actual practice, this last factor may not be as big a difference as the brevity of the new language suggests, but at minimum it leaves less room for concern about what is and is not permissible.
So is the new covenant a significant improvement? There is no question that it is, and Microsoft therefore deserves credit for moving its IPR position so substantially. Hopefully it will take the same posture with other patents in its portfolio in the future, where significant standards opportunities arise.
With all that being said, then, how do we most fairly reconcile the glass half empty of my last post and the glass half full described above into a single image?
The difference between the two views is that the Microsoft covenant does not relate (for example) to one of the many Web services specifications that it, IBM and BEA have submitted to various standards organizations over the past several years. In those cases, there were usually no alternative standards in play, nor (yet) any compliant products, and therefore any assertion made by Microsoft at the time of submitting a specification for consideration by a standards body would be pure gain to the marketplace — clearly a glass half full (or more).
With respect to the current situation, however, the ODF standard is already in the marketplace, is already supported by several products, and has already been submitted to ISO for adoption. So if one were to put oneself in the position of a developer or a government agency, the analysis of my previous post becomes relevant: am I better off under the Sun covenant and the OASIS IPR policy, or am I better off (or at least no worse off) under the Microsoft covenant and pledge to seek Ecma adoption, and then ISO endorsement?
From this market perspective, Microsoft arguably needs to go farther than Sun, rather than less far, to provide equivalent comfort to those currently choosing between ODF and the Microsoft schemas. The reason is because Ecma has not yet taken control of the XML schemas, much less adopted them. Until then Microsoft still controls (and can therefore change) the formats, or could withdraw the formats from Ecma if it was not pleased with the direction that the Ecma working group wished to go.
What could it do to close this situational gap, if it wished? Here are some suggestions:
1. Enter into a written agreement with Ecma not to withdraw the XML formats from forming the basis for a new Ecma standard, or disclose such a written undertaking, if it has already been entered into.
2. Announce at what point the XML formats will pass from Microsoft control to that of the Ecma working group (in other words, on what date will Microsoft have no greater voice than any other working group member over any changes the working group wishes to make to the formats?)
3. Announce whether, and how, the XML formats may change between now and the hand over date.
4. Make a commitment to remain a contributing member of the Ecma working group supporting continuing development of the formats, and more importantly, make a long term commitment to support the standardized schemas, so that others that support the new standard, or buy products that support the standard, are not stranded in the future. Yes, this is more than Sun has committed to, but Sun does not have an 85% (or greater) market share of office productivity software seats.
5. Disclose whether it is aware of any third party patents that would be infringed by implementation of the XML schema that are currently covered by Microsoft cross licenses, and whether the owners of those patents will be bound under those cross-license not to sue those that build implementations of the XML Schema under the new covenant.
6. Consolidate the promise to cover the Office 12 version of the XML formats into the covenant not to sue. Currently, the promise to do so is on a different Web page, making its legal force more questionable.
7. Clarify the relationship between the new covenant and the previously required copyright notice, and whether copyright notices will be required in any implementation of the XML Schemas if they are adopted by Ecma. I believe that this is less than obvious at the moment, after reading the various Web pages at the XMLS Schema pages of the Microsoft site.
Once again, and in fairness, it’s important to note that most of the above represent gap fillers, and are relevant only for the next 12 to 18 months (e.g., the time between now and the date upon which ISO may adopt a standard based on the Microsoft formats), and some concerns noted above will be eliminated as various milestones in the Ecma process are achieved. If Ecma, and then ISO, adoption follows, then there will be very few differences of substance to be found between the Microsoft and the Sun covenants that would be of concern to either developers or end-users.
So where does that leave someone today who needs to make a procurement decision? Necessarily, comparing not only apples and oranges, but quite a few other types of fruit as well.
On the one hand, Office is well known, widely used, and will continue to be energetically developed, while ODF implementations are new and not yet as fully featured. On the other hand, converters are already under development to transition Office documents for use with products that support ODF, and there are already multiple products in the marketplace that support ODF, including open source versions. Again, the XML formats have been created (not surprisingly) to date solely to meet the needs of Microsoft products and are therefore presumably well crafted for that purpose, while the ODF formats have been developed to serve a wider consensus of needs.
Most significantly for purposes of this analysis, though, is the fact that more things are known today about the terms upon which ODF may be implemented, and what ODF itself actually covers. After all, there will be other members of the Ecma working group, and the Ecma IPR policy will not require them to give as liberal assurances as Microsoft has offered in its covenant. Also, standards processes can be long, contentious and less than (how to say diplomatically) straightforward. Much can happen, and there is always the possibility of an impasse before the XML Schemas become ISO standards, if in fact that ever occurs.
But in the meantime, fair is fair. Microsoft has moved its position considerably, and it deserves points for doing so. Whether it has moved far enough from a strategic perspective remains to be seen.
Of course, we shouldn’t have too long to wait to find out. That’s why customers were invented.
Note: This entry does not constitute the rendering of legal advice; please consult your own attorney before making any decisions involving Microsoft’s intellectual property rights.
subscribe to the free Consortium Standards Bulletin