In the spirit of contribution, then, here are six observations about their covenant:

1. Patent protection is contingent on a conformant implementation. "Conformant" is not defined, meaning there is uncertainty needing legal advice.

2. There is no provision for partial implementation, meaning true community-based development is not covered until complete.

3. It may well mean that implementation of just a word processor is impossible -- it implies that you have to implement everything (spreadsheets & all) to reach the bar.

4. It is specific to the version currently existing, meaning I can be hooked into supporting it now, but when Office 12 or Office 13 comes out & I update to be compatible with the format in that I can get sued. The covenant Sun uses creates ongoing protection.

5. It does not grant patents to the ECMA standard as it only applies to Office 11 XML. This means a new covenant will be needed for the ECMA work.

6. If the same form of words were used for a contribution to ECMA, then those prototyping the ongoing evolution of the standard as ECMA changed it would lose protection the instant any change was made. It applies only to Microsoft's input, not to ECMA's output. Or maybe they would rather ECMA didn't change anything?

Together, these six problems seem to be show-stoppers for open source, no matter how positive Brian Jones or even Larry Rosen may feel about it all -- as David Berlind says, we only know they won't sue what they unilaterally consider to be "conforming" uses. As it stands, I don't think their covenant gives open source developers sufficient confidence to implement the spec it covers, let alone the forthcoming specs that it doesn't. Assuming Microsoft intends, as they say, to open their data formats, we expect to see some further work and clarification to address these issues.

I had similar questions, particularly the what-does-conforming-mean question? Why isn't that defined? And if it isn't, how could you ever know where the line is? Phipps writes that it's an issue needing legal advice. But if Microsoft doesn't define it, the lawyers won't know either. And may I just point out in passing that being an ECMA standard doesn't mean it is open? ECMA follows a RAND policy, the terms of which are incompatible with the GPL and most OS licenses. And in a FAQ on Office 2003 XML Reference Schemas, Microsoft tells us something interesting about RAND terms:

Q. Are Microsoft's licenses for its Office 2003 XML Reference Schemas RAND?

A. While there is no formal definition of RAND (reasonable and non-discriminatory), we believe that all of the terms in our licenses for the Office 2003 XML Reference Schemas are RAND. The patent license, including the defensive suspension clause and all other terms, are terms customarily found in standards-related patent licenses.

Catch that? "No formal definition." Or, wiggle room. This ECMA Powerpoint document states that ECMA doesn't define RAND either, and that's not all it doesn't do:

IPR Policy

Ecma does not:

Assess the essentiality of patents for implementation of a standard
Register patents used in standards or
Define the term "Reasonable And Non Discriminatory" (RAND)

Instead, members grant (not necessarily royalty-free) licences under RAND terms, by default

If, in very rare cases, contributing members do not accept RAND terms, there are several options:

Ecma stops the project
Participants collectively buy the license
Participants circumvent the patent by alternative implementations of the standard

How reassuring do you find that? Here, the patent covenant not to sue means you don't need to get a license from Microsoft on the schemas, but the point I'm making is that RAND does not equal Open. If anything, the opposite.

I believe the requirement in Massachusetts is not just that a format be a standard, but that it be an *open* standard. ECMA in no way speaks to that important requirement, in my view. So, if Microsoft wishes to qualify in a way that won't elicit derision, it still would have some work to do to qualify even if ECMA rubberstamps its application. ECMA describes itself like this:

Ecma is driven by industry to meet the needs of industry, generating a healthy competitive landscape based on differentiation of products and services, rather than technology models, generating confidence among vendors and users of new technology.

When a standards body says it is "driven by industry to meet the needs of industry", you might want to consider what that means in this context. The Commonwealth is trying to meet the needs of government, not the needs of Microsoft, presumably. ECMA has no such agenda. We won't need to guess as to the result. Novell's Miguel de Icaza writes:

Novell will be sending some folks from our Open Office team to the newly created ECMA TC45 working group. We hope to determine if the standard will be open enough and the details complete enough to allow for interoperability.

The whole Internet world is watching, so Microsoft will have to be real, or it will become obvious.

I asked Marbux to explain Microsoft's covenant to me, and hence to all of us here, and to list everything he sees. If you only have time to read one section, I'd suggest section 3.

But for the truly busy, let me quote just part of one section:

When Microsoft does update the covenant not to sue to cover Office Open XML, the company might also consider expanding the covenant's scope to expressly repudiate previously asserted inconsistent limitations of rights, such as the Office 2003 Schemas patent license and the Open Packaging Conventions draft patent license discussed in the Developer Tools Licensing Issues section of this article.

Microsoft is sending a mixed message by presenting developers with inconsistent documents like the covenant not to sue and those patent licenses. I.e., one limits rights, while the others expand some of the same rights and vice versa. Compare the covenant not to sue with the Office 2003 Schemas patent license. ...

In contrast [to Sun's covenant], Microsoft's covenant is far more convoluted and limits developer rights in a three-step process. In the first step, Microsoft makes promises only regarding its "patent claims necessary to conform" to its file format specification. I assume that somewhat bewildering phrase means that Microsoft is making no promises regarding patent claims not necessarily infringed by a "conforming part" of a software application. All other Microsoft patent claims remain in play.

However, the more typical construct I have assumed Microsoft meant to use in itself begs the question of what is "necessary." I.e., if Microsoft can later prove that a different programming solution producing the same result would not infringe, then Microsoft can argue that the covenant does not apply because the infringement was not necessary. For example, the draft Microsoft Open Packaging Conventions Patent License discussed in the next section states:

A claim is necessarily infringed only when it is not possible to avoid infringing when reading or writing packages that implement the Open Packaging Conventions, or rendering packages as allowed by the Open Packaging Conventions.

It is not absurd to suspect that Microsoft might make such arguments in regard to the covenant not to sue.

However, the covenant's putative patents are not identified, so there is no means provided for developers to determine whether there is a non-infringing work around for a Microsoft patent claim. The result is that Microsoft in effect asks developers who would work with Office Open XML to roll the dice on whether they gain any protection whatsoever from Microsoft's promise not to sue.

In the second step of its limitation of developer rights, Microsoft promises not to sue only in regard to "conforming parts" of software products. The language employed provides absolutely no guidance on what constitutes a "conforming part" of a software product. Is that any more than the file format XML code itself? Precisely what in the maze of coding interdependencies that is typical in a complex software program might be confidently demarcated as a "conforming part" and therefore exempted from a Microsoft patent infringement lawsuit? Microsoft's covenant not to sue over "conforming parts" of a software program provides scant confidence that any code in a software product will not provide grounds for a Microsoft infringement lawsuit.

Bottom line? Unless Microsoft clarifies, no one will dare to touch their XML, and that makes it not open at all. Marbux sums up:

In summary, Microsoft should consider taking prompt action to align its licensing documents with its public statements regarding developer freedom to use its forthcoming Office Open XML file format specification. Those documents presently impose unnecessary restraints on developers' implementations of the new Microsoft Office Open XML specification. . . .

If Microsoft truly desires to see Office Open XML widely used by other developers, Microsoft must allow them the freedom to add and subtract from the Office Open XML specification to accommodate the features of their own applications and to innovate. Accordingly, Microsoft should consider amending the covenant not to sue with binding definitions making it clear that developers can adapt the Office Open XML specification to their own applications as needed.

Microsoft might also consider amending the covenant not to sue to extend its promises to subsequent versions of the specification as Sun Microsystems did in its OpenDocument covenant not to sue. That omission can only create doubt that revisions to the specification may be used on the same terms. Developers need certainty that they will be allowed to update their software creations as file format specifications mature. Microsoft provides no such assurance.

Finally, Microsoft might consider moving beyond mere tweaking of its existing covenant not to sue. Because Microsoft has not yet committed to final wording on its covenant not to sue in regard to Office Open XML, the company is in a position to mirror the language of the Sun Microsystems covenant not to sue in regard to the OpenDocument XML standard.

That would cure all of the deficiencies discussed above.

Or as they might put it in Brooklyn, it ain't open 'til it's open.

***********************************

The Microsoft Covenant Not to Sue - Sending a Mixed Message
~ by Marbux

NOTE: The Reader should understand that the author of this article is retired and no longer practices law. Accordingly, nothing in this article should be regarded as legal advice. Should you desire legal advice regarding subjects discussed below, you should consult your own attorney.

1. Introduction
2. The Microsoft Covenant Not to Sue
3. Developer Tools Licensing Issues
4. The Government Procurement Environment
5. Conclusion
6. Notes

1. Introduction

Facing mounting pressure to support the OpenDocument XML file format standard in its flagship Office software suite, Microsoft responded by announcing it would instead submit its own Office 12 XML file format — now under development — for consideration as a formal standard. Groklaw has already covered the initial announcement. This article addresses software patent licensing issues involved with that announcement. Copyright and trade secrecy issues are not examined.

In summary, Microsoft should consider taking prompt action to align its licensing documents with its public statements regarding developer freedom to use its forthcoming Office Open XML file format specification. Those documents presently impose unnecessary restraints on developers' implementations of the new Microsoft Office Open XML specification.

[ Contents ]

2. The Microsoft Covenant Not to Sue

Microsoft followed up its initial announcement of its intent to submit the Office Open XML specification to standardization processes with public release of a covenant not to enforce its patent portfolio ("covenant not to sue") against those who use its Office 2003 XML file format, which Groklaw has also already reported.

However, that is not the file format Microsoft intends to submit to the standardization processes. The company has not yet issued licensing information for the new Microsoft Office Open XML file format scheduled to be released with Microsoft Office 12 about a year from now. Office Open XML is the file format Microsoft said it will submit to standards bodies.

A Microsoft developer said that the company would later "update" the Office 2003 XML file format covenant not to sue¹ to "cover" the Office Open XML file format once its specification was "posted." B. Jones, Microsoft Developer Network, New approach to licensing with the Office XML formats (November 22, 2005) ("[w]e'll of course update this to cover the [Office] 12 schemas as soon as we get those posted").

That statement is sufficiently vague that a court would not likely hold that it creates any enforceable Microsoft obligation. But in any event, Microsoft will likely carry through with that plan. In the remainder of this article, I will assume that the existing covenant not to sue will in fact be used without change other than to bring the Office Open XML specification within its scope, except where I make suggestions for its amendment. (However, the unavailability of the covenant that will actually be used with the proposed standard obviously prevents any analysis of the final document.)

When Microsoft does update the covenant not to sue to cover Office Open XML, the company might also consider expanding the covenant's scope to expressly repudiate previously asserted inconsistent limitations of rights, such as the Office 2003 Schemas patent license and the Open Packaging Conventions draft patent license discussed in the Developer Tools Licensing Issues section of this article.

Microsoft is sending a mixed message by presenting developers with inconsistent documents like the covenant not to sue and those patent licenses. I.e., one limits rights, while the others expand some of the same rights and vice versa. Compare the covenant not to sue with the Office 2003 Schemas patent license.

Assuming the language of the existing covenant not to sue is the model for the covenant applicable to Office Open XML, as indicated by Brian Jones, Microsoft might also consider further altering some of that language. With key words emphasized, the covenant not to sue provides in relevant part:

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.

By contrast, the corresponding portion of Sun Microsystem's covenant not to sue regarding the OpenDocument XML specification reads:

Sun irrevocably covenants that … it will not seek to enforce any of its enforceable U.S. or foreign patents against any implementation of the Open Document Format for Office Applications (OpenDocument) v1.0 Specification, or of any subsequent version thereof ("OpenDocument Implementation") in which development Sun participates[.]

Sun's covenant applies to "any implementation" of the OpenDocument standard as well as to any implementation of any subsequent version of the standard, so long as it is a version of the standard that Sun participates in developing. The rights granted are unambiguous and broad ("any implementation").

In contrast, Microsoft's covenant is far more convoluted and limits developer rights in a three-step process. In the first step, Microsoft makes promises only regarding its "patent claims necessary to conform" to its file format specification. I assume that somewhat bewildering phrase² means that Microsoft is making no promises regarding patent claims not necessarily infringed by a "conforming part" of a software application. All other Microsoft patent claims remain in play.

However, the more typical construct I have assumed Microsoft meant to use in itself begs the question of what is "necessary." I.e., if Microsoft can later prove that a different programming solution producing the same result would not infringe, then Microsoft can argue that the covenant does not apply because the infringement was not necessary. For example, the draft Microsoft Open Packaging Conventions Patent License discussed in the next section states:

A claim is necessarily infringed only when it is not possible to avoid infringing when reading or writing packages that implement the Open Packaging Conventions, or rendering packages as allowed by the Open Packaging Conventions.

(Emphasis added.) It is not absurd to suspect that Microsoft might make such arguments in regard to the covenant not to sue.

However, the covenant's putative patents are not identified, so there is no means provided for developers to determine whether there is a non-infringing work around for a Microsoft patent claim. The result is that Microsoft in effect asks developers who would work with Office Open XML to roll the dice on whether they gain any protection whatsoever from Microsoft's promise not to sue.

In the second step of its limitation of developer rights, Microsoft promises not to sue only in regard to "conforming parts" of software products. The language employed provides absolutely no guidance on what constitutes a "conforming part" of a software product. Is that any more than the file format XML code itself? Precisely what in the maze of coding interdependencies that is typical in a complex software program might be confidently demarcated as a "conforming part" and therefore exempted from a Microsoft patent infringement lawsuit? Microsoft's covenant not to sue over "conforming parts" of a software program provides scant confidence that any code in a software product will not provide grounds for a Microsoft infringement lawsuit.

In the third limiting step, Microsoft closes its covenant with the only language it did apparently copy from Sun's covenant not to sue:

No other rights except those expressly stated in this covenant shall be deemed granted, waived or received by implication, or estoppel, or otherwise.

In Sun's covenant, the same language does not serve as a major limitation of rights because the grant of rights in its covenant is broad and contains no obvious ambiguity. In Microsoft's covenant, the same language acts as a further restriction of developer rights. That is because Microsoft's covenant contains the two-step restrictions discussed above and those terms are vague and ambiguous. Implication and estoppel are the tools traditionally used by courts to cure vagueness or ambiguity in a contract such as a covenant not to sue. In Sun's case, the language serves as protection for Sun from unanticipated arguments. In Microsoft's case, the language acts to further restrict developer rights.

When the three limitations are combined, the Microsoft promise not to sue is largely meaningless: (i) the no-waiver-or-estoppel provision acts to compel a narrow interpretation in Microsoft's favor of the "necessarily infringed" and "conforming parts" phrases; (ii) so interpreted, the "necessarily infringed" portion minimizes the number of its patent claims that are subject to Microsoft's promise not to sue; and (iii) so interpreted, the "conforming parts" phrase minimizes the amount of developers' code that is protected from suit.

Such problems are compounded by the lack of definitions for the word "conform" and its variant "conforming." If read restrictively, those terms could reasonably be interpreted as prohibiting implementation of subsets and supersets of the Office Open XML specification. See e.g., Sun Microsystems v. Microsoft, 188 F.3d 1115 (9th Cir. 1999) (Microsoft modification of the Java compiler specification).

Both subsets and supersets are critical to the ability of developers to use the Office Open XML file format. In the context of explaining why Microsoft chose to develop its own XML format rather than supporting the OpenDocument XML standard, Microsoft Office developer Brian Jones said:

Our primary goal at Microsoft was to create an open format that fully represented all of the features that our customers have used in their existing documents, documents that have been created using the existing Office products over the past couple decades. … The interoperability problems will start to come up if there are features that are present in one application but not present in the other application. You have to assume this will be the case since every application out there has a different set of customers that request different features.

Microsoft's Alan Yates compressed the same explanation:

Our customers require us to support the full feature set of Office and Office 12. They would not accept us supporting anything that didn't support some features or hid other features.

By the same logic, Microsoft should not expect other developers' customers to "accept [those developers] supporting anything that didn't support some features or hid other features."

Absent the right to create subsets and supersets, the Microsoft covenant not to sue would effectively limit competitors to writing add-on applications for Microsoft Office. They would not be granted the right to adapt the specification to stand-alone applications.

Such an interpretation, however, is at odds with statements about developer freedom issued by Microsoft officials in announcing its planned submission of Office Open XML for certification as an open standard. Therefore, there is reason to suspect that Microsoft did not intend that the "conforming" terms be interpreted as forbidding creation of subsets and supersets of its file format specification.

It may be that Microsoft actually intended a meaning more akin to the definition of "conformance" in the World Wide Web Consortium's XML 1.0 specification. That definition, far too lengthy to quote here, illustrates a minimum level of detail that Microsoft should supply in a definition of "conform" and "conforming." See also Sun Microsystems v. Microsoft, supra (Sun license required that Microsoft maintain Java compiler compatibility with a specified test suite).

If Microsoft truly desires to see Office Open XML widely used by other developers, Microsoft must allow them the freedom to add and subtract from the Office Open XML specification to accommodate the features of their own applications and to innovate. Accordingly, Microsoft should consider amending the covenant not to sue with binding definitions making it clear that developers can adapt the Office Open XML specification to their own applications as needed.

Microsoft might also consider amending the covenant not to sue to extend its promises to subsequent versions of the specification as Sun Microsystems did in its OpenDocument covenant not to sue. That omission can only create doubt that revisions to the specification may be used on the same terms. Developers need certainty that they will be allowed to update their software creations as file format specifications mature. Microsoft provides no such assurance.

Finally, Microsoft might consider moving beyond mere tweaking of its existing covenant not to sue. Because Microsoft has not yet committed to final wording on its covenant not to sue in regard to Office Open XML, the company is in a position to mirror the language of the Sun Microsystems covenant not to sue in regard to the OpenDocument XML standard.

That would cure all of the deficiencies discussed above. Such a change would also provide additional benefits. It would, for example: (i) eliminate any informed concern that the Microsoft format is more encumbered than the OpenDocument format; and (ii) eliminate the licensing incompatibilities that may otherwise frustrate feasible interoperability between the two formats.

[ Contents ]

3. Developer Tools Licensing Issues

Microsoft might also seriously consider including a binding policy statement regarding licensing terms for developer tools to work with Office Open XML. As detailed below, Microsoft's only licensing message to the industry is that it intends to keep necessary tools under lock and key. If that is not the message Microsoft wishes to convey, the company should consider clearly stating its actual relevant policy in the binding covenant not to sue discussed in the previous section. Such a message should be delivered soon, else silence itself be construed as a message.

A published draft Microsoft patent license for its Office Open XML packaging conventions is highly troubling because it: (i) casts a patent infringement cloud over any other method for packaging information in Office Open XML files; and (ii) is so restrictive that it limits developers to creating add-on tools for Microsoft Office.

I stress that the patent license is a draft; however, it conveys an ominous message to developers and government software procurement officials. Microsoft should therefore consider expressly repudiating it along with the additional restrictive license required for downloading the conventions.

Recall that the Office Open XML specification has not yet been published much less become a formal standard, and there is not yet a binding covenant not to sue if other developers use the format. Competitors' access to tools needed for use of the file format is no small issue because of Microsoft's apparent decision not to incorporate existing standards into Office Open XML as the OpenDocument standard does.

OpenDocument reuses existing standards whenever possible. It uses SVG for drawings, MathML for equations, etc. This makes the format infinitely more transparent to someone familiar with XML technologies. It also allows you to reuse existing tools that understand these standards. In contrast, Microsoft has decided to reinvent the wheel at every turn.

A. Hudson, et al, Groklaw, Format Comparison Between ODF and MS XML (November 26, 2005). Developer tools to work with the Microsoft format must therefore be reinvented as well. It matters what licensing terms Microsoft will impose on such tools.

Microsoft has made no commitment to allow others to create developer tools required for its unique file format. See B. Jones, Microsoft Developer Network, Office XML Formats: Standardizing the Microsoft Office Open XML formats (November 21, 2005) ("[i]n addition, we'll provide plenty of tutorials, best practices, and all kinds of tools to help folks work with the formats") (emphasis added).

Therefore, it is disturbing that Microsoft has made no commitment to abandon the draft patent license for its Open Packaging Conventions. Microsoft summarizes those conventions as follows:

The Open Packaging Conventions specification describes the method for packaging information in a file format, describing metadata, parts, relationships, and application of digital signatures. This specification is intended both for data format producers, who want to store data or content in a package that conforms to the Open Packaging Conventions including specific data formats such as the XPS Document format, and format consumers, who want to access and render or process the contents of a format that conforms to the Open Packaging Conventions, including the XPS Document and Microsoft Office Open XML formats.

Microsoft WHDC, Open Packaging Conventions (September 13, 2005) (emphasis added).

Internal data storage of the Office XML Formats is segmented into discreet components; for example, embedded code is stored separately from the document content inside the file. Each component within a single file is compressed using ZIP compression technology. In addition to the compression of each document segment, the entire document is also compressed using ZIP compression.

Microsoft Office Open XML Formats Frequently Asked Questions.

Microsoft's use of the ZIP file format for such purposes is hardly unique:

ZIP files generally use the file extensions ".zip" or ".ZIP" and the MIME media type application/zip. Some software uses the ZIP file format as a wrapper for a large number of small items. Generally when this is done a different file extension is used. Examples of this usage are Java Jar files, id Software .pk3/.pk4 files, package files for StepMania and Winamp, and some OpenOffice.org document formats. The OpenDocument format is usually sent as a Jar file, so it can be easily uncompressed and compressed using tools for ZIP files.

ZIP file format - Wikipedia

That Microsoft would suggest that it has patent rights to assert for a method of packaging information in ZIP files is in itself somewhat discomfiting as discussed below. However, I am here concerned with the larger licensing message conveyed to the software industry and to government software procurement officers by Microsoft's proposed assertion of severe patent license restrictions on tools needed for developers to work with Office Open XML.

Microsoft's draft Open Packaging Conventions Patent License includes much of the same language used in the Microsoft Office 2003 Reference Schemas patent license found wanting in the recent Massachusetts Executive Department's rejection of Microsoft's XML file format as a software procurement standard.

As with the latter license, the Packaging Conventions license requires inclusion of a Microsoft patent rights notice in licensed implementations and developers are prohibited from sublicensing or transferring their rights. Those provisions make the Microsoft Open Packaging Conventions incompatible with all open source software licenses certified by the Open Source Initiative ("OSI").

The no-sublicensing-or-transfer provision also blocks use of the Microsoft packaging conventions by anyone other than Microsoft who develops Office Open XML software for distribution, whether proprietary or licensed under an OSI-approved license. See my previous detailed and referenced discussion of the Office 2003 Reference Schemas patent license, including the specific reasons such provisions block use of the Schemas by other developers.

An additional issue with the draft packaging conventions patent license is a conflict between two important provisions. On the one hand, developers are told "[y]ou are not licensed to sublicense or transfer your rights." On the other hand, the license states, "[i]f you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed[.]" The license does not explain how a developer might "distribute, license or sell" software when they are prohibited from any "sublicense or transfer" of their rights. That ambiguity should be resolved if the draft patent license is not expressly repudiated.

It is also troubling that Microsoft's draft Packaging Conventions license excludes permission to use any Microsoft patented technology:

(ii) covering any Enabling Technologies that may be necessary to make or use any product incorporating a Licensed Implementation, or (iii) covering the reading or writing of packages other than packages that implement the Open Packaging Conventions, or rendering of packages in a manner that is different than the rendering allowed by the Open Packaging Conventions. "Enabling Technologies" means technologies that may be necessary to make or use any product or portion of a product that complies with the Open Packaging Conventions, but are not expressly set forth or required in the Open Packaging Conventions, such as general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like.

The implicit suggestion that Microsoft holds patent rights in this area but declines to license relevant claims unless the Microsoft packaging conventions are used implies that any developer that uses other tools for packaging information in Office Open XML files is at risk of a Microsoft patent infringement lawsuit.

Microsoft also declines to license any right to use the packaging conventions in any "general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like." Furthermore Microsoft also forbids any developer who does use the Open Packaging Conventions from sublicensing or transferring any of their rights.

To put it mildly, the patent license does not allow much wiggle room for anyone but Microsoft to do any development work involving Office Open XML. Unless developers are willing to risk a Microsoft patent infringement action over unspecified patent claims involving XML packaging conventions, Office Open XML files can only be read or written using Microsoft "general word processing, spreadsheet or presentation features or functionality, operating system technology, programming interfaces, protocols, and the like."

Even further issues are created by the inclusion of the following portions of the draft patent license:

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 or writing package that implement the Open Packaging Conventions, or rendering packages that implement the Open Packaging Conventions as allowed by the Open Packaging Conventions.

. . . . .

You are not licensed to sublicense or transfer your rights.

. . . . .

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 packages that implement the Open Packaging Conventions, or by using (solely for the purpose of reading such packages) any software that enables them to do so. The term "government documents" includes public records.

As I pointed out in my article dissecting the very similar Office 2003 Reference Schemas patent license, the "[e]xcept as provided below" phrase causes the prohibition against sublicensing or transfer of rights to extinguish the grant of rights to "sell, offer to sell, import, and otherwise distribute Licensed Implementations," leaving only the right to "make" and "use" a Licensed Implementation. The "[b]y way of clarification of the foregoing" phrase — which is also superior to the major grant of rights by way of the "except as provided below" phrase — necessarily implies that the license will be exceeded if the Licensed Implementation is used for anything but reading government documents (applying the expressio unius est exclusio alterius canon of contractual construction).

Because at the present time, the packaging conventions are separate from the Office Open XML specification, simply adding that specification to the existing covenant not to sue would not thereby confer Microsoft permission for others to use the packaging conventions. Therefore, Microsoft should consider explicitly bringing the packaging conventions within the scope of the covenant not to sue.

Should anyone decide after their lawyers read the draft patent license that they would prefer to download and review Microsoft's XML packaging conventions before agreeing to the patent license, they must first agree to yet another restrictive license that amongst other provisions, includes an indemnification provision: "[i]f there is litigation, the losing party must pay the other party's reasonable attorneys' fees, costs and other expenses."

Considering Microsoft's demonstrated ability to inflict and absorb legal expenses, plus the extremely narrow rights granted by the packaging conventions patent license in any event, the indemnification provision creates a considerable disincentive even to consider using both the packaging conventions and Office Open XML.

For reasons such as those discussed above, the present state of its legal pronouncements to the industry and government procurement officers leaves the message that Microsoft intends to impede their right to package data in the Office Open XML file format under implicit threat of a patent infringement action.

Indeed, by suggesting that it may assert patent rights in the area of XML package management, Microsoft casts a patent cloud over all others who package XML information in the ZIP file format. To diminish such concerns, Microsoft should consider announcing precisely what patent rights it holds in this area and explaining in detail its position regarding others' rights to use that technology. Such important matters should not be left to speculation.

Just as importantly, there is no binding Microsoft commitment to make any of the developer tools it plans to create for working with Office Open XML available under any less restrictive terms, or to allow other developers to create their own tools. But the language of the draft XML packaging management patent license suggests that Microsoft intends to keep developer tools for Office Open XML under lock and key. Unless that is its actual intent, Microsoft should consider correcting the misimpression in a legally binding document.

[ Contents ]

4. The Government Procurement Environment

On the other hand, if Microsoft management did intend to foreclose other developers from using its specification, they might consider asking its lawyers to make a more thorough study of relevant government procurement law. An anticompetitive approach to standardizing a specification may spell unanticipated trouble in the government software procurement arena.

Microsoft has indicated that its decision to submit Office Open XML as a proposed standard was driven at least in part by government procurement requirements:

Some customers, particularly in the public sector, have been telling us that they would like us to take this step. They are focused on the long-term management and archiving of digital records and want to use our document formats. They have told us that they would like to see us pursue this step as a measure of goodwill toward them and their interests and we are now following through on their request.

See also Computerworld: ("'We have a few barriers (with government contracts),' said Alan Yates, general manager for Microsoft Office").

Those barriers are significant. The OASIS OpenDocument standard is pending before the International Organization for Standardization ("ISO") for approval as an international standard. Approximately one month before Microsoft announced its decision to submit Office Open XML as a proposed standard, an OASIS Adoption Forum was held in London, U.K. devoted in part to the OpenDocument file format standard. At that conference:

Barbara Held from the eGovernment services division (IDABC) of the European Commission, said it can only recommend the open file format to member states if it is issued by a public standardization body, such as ISO. "Only specifications that are issued by public standardization bodies are considered standards by the European Commission. So, from the perspective of the European Commission, OASIS' OpenDocument format is not a standard," said Held, in a speech at the OASIS event. She said that IDABC will start recommending OpenDocument if it is approved as an ISO standard, as it already fulfills its criteria on open standards.

If the format becomes an ISO standard, this will not only impact the policy of European member states, but will also allow public sector organisations to tender for OpenDocument-compatible applications. "Only public standards can be referred to in calls for tender," said Held. "If we started tendering and asked for OpenDocument formats, someone could sue us. Instead we have to say, 'someone that is producing a document format that's open.'"

ZDNet U.K., ISO deciding whether to adopt OpenDocument (October 19, 2005). According to the same report, "the president and chief executive of OASIS[] said … that an ISO committee is due to vote 'shortly' on whether OpenDocument will be accepted as an international standard."

The European Commission's IDABC (formerly IDA) has enormous influence on government software procurement within the European Union, as it is the agency responsible for coordinating government software communications interoperability from the European Community level down to local government units. See e.g., OASIS Cover Pages, IDA Releases European Interoperability Framework for Pan-European E-Government Services (December 6, 2004). An IDABC "recommendation" bears considerable weight in European government software procurement.

Conceivably, Microsoft management inferred from such reports that adoption of Office Open XML as an ISO standard is all that is necessary, and that allowing other developers to use the standard is not a necessary condition of Microsoft products remaining eligible for government procurement contracts.

However, the very purpose of the relevant requirement of procurement tenders based on national or international standards is to end government procurement specifications that have discriminatory effect.

The overarching applicable law is the international Agreement on Government Procurement, one of the general trade agreements administered by the World Trade Organization. See my extensive previous discussion of that treaty in the context of the recent debate over Massachusetts Executive Department software procurement standards.

Regarding European law, Microsoft's attorneys may find it helpful to review a legal memorandum [PDF] prepared for the Initiative for Software Choice ("ISC"), an international government software procurement lobbying organization that includes Microsoft in its membership. I offer that memorandum because I suspect that Microsoft officials may trust its legal analysis more than mine.

The memo, after surveying the European precedents and noting their relationship to the Agreement on Government Procurement, makes plain that the purpose of the European procurement laws is to foster competition for government tenders by eliminating tender specifications that have discriminatory effect. It quotes Article 23 of the E.U. Public Procurement Directive:

Technical specifications shall afford equal access for tenderers and not have the effect of creating unjustified obstacles to the opening up of public procurement to competition.

The ISC memo concludes in part that:

[T]he conditions for performance of contracts must be compatible with Community law. As such, they may not be directly or indirectly discriminatory and must be indicated in the contract documents.

Any Microsoft plan to gain a competitive advantage in government software procurement through establishment of a discriminatory standard — if such a plan exists — should be thoroughly vetted by counsel.

[ Contents ]

5. Conclusion

Licensing issues surrounding Office Open XML remain a major concern. The over-all licensing message to the software industry and to government procurement officers conveyed by Microsoft's covenant not to sue and the draft patent license for the Office Open XML packaging conventions conflicts with Microsoft's public statements regarding the freedom that it will allow to developers working with Office Open XML. The message to developers left by the two legal documents is that they can only use Office Open XML to write add-ons for Microsoft Office, unless they are willing to risk a Microsoft patent infringement lawsuit.

It warrants consideration that licensing terms can also play a role in standardization body decisions whether to adopt a proposed standard. See e.g., Ecma Code of Conduct in Patent Matters ("[t]he General Assembly of Ecma shall not approve recommendations of Standards which are covered by patents when such patents will not be licensed by their owners on a reasonable and non-discriminatory basis").

Microsoft should promptly reconcile the disparity between its public pronouncements and its legal documents within the context of a published binding legal document so that developers and potential customers can plan whether to: (i) use the Microsoft Office Open XML file format; or (ii) pursue alternatives such as solutions based on OpenDocument XML.

[ Contents ]

6. Notes

¹ Although they are not the same thing, both patent licenses and covenants not to sue have the legal effect of allowing the use of a patented invention on specified terms without liability. The author has therefore occasionally amalgamated both concepts by using the phrases licensing issues and licensing message as encompassing both patent licenses and covenants not to sue.

² The Microsoft covenant not to sue is a grammatical horror that defies precise understanding. The phrase "patent claims necessary to conform" to the specification ignores the reality that software is written in code, not in patent claims. No patent claim is "necessary to conform to technical specifications." Once that error is recognized, the sentence dissembles into gobbledygook. I have attempted to work with the phrase nonetheless.

[ Contents ]