Our decision in the 1990s to release Globus software as open source has resulted in me learning far more than I ever thought I'd need to know about the law. I suspect that not all readers know as much as they should about the licensing issues involved in both open standards and open source software. That is unfortunate, because there are subtleties that can result in confusion, uncertainty, and even liability. In this regard, I found a recent posting by the OpenDocument Foundation of interest. It certainly convinced me that I don't understand as much as I thought I did about these issues. I'm glad that we've adopted the standard Apache v2 license for Globus software.
The OpenDocument Foundation posting follows:
Recently the OpenDocument Foundation cast a "no" vote on the OASIS WS-Reliable Messaging ("WS-RM") specification. Our reason is that we strongly object to the IPR licensing model, "Royalty Free on RAND terms", as it applies in particular to the WS-RM standards proposal. Paul Fremantle, Co-chair of the WS-RX TC, has requested that we post a comment with our vote fully explaining our position, which we are grateful to provide.
As a general matter the Foundation has historically opposed the use of software patents to limit developers' rights to implement supposedly "open" software communications protocols and file formats. Such limitations are a legal, as opposed to technical, barrier to fulfillment of the fundamental market requirement of software interoperability. The controversy leading to the European Parliament's overwhelming rejection of the European Commission's proposed Directive on Computer-Implemented Inventions (software patents) amply demonstrates that the Foundation is scarcely radical in this position.
However, that broader issue is not raised by the Foundation's "no" vote at OASIS on the latest draft WS-Reliable Messaging ("WS-RM") specification; In the WS-RM situation, the Foundation's "no" vote addresses the irreconcilability of endemic Microsoft public statements about the openness of the RAND conditions it has adopted with the actual meaning of the relevant Microsoft IPR Document -- the Microsoft Open Specification Promise ("MOSP"). MOSP actually grants no rights whatsoever and forces wary developers to negotiate separate agreements with Microsoft on Microsoft's terms.
The MOSP has the practical effect of eliminating free and open source software developers and other independent developers from the market for applications that implement WS-RM, 29 other WS specifications, as well as still other specifications. Many of the protocol specifications with which WS-RM incorporates by reference or must remain interoperable with are included in the MOSP list.
The MOSP: [i] grants no non-Microsoft developer rights whatsoever; [ii] omits mention of certain rights required by applicable OASIS rules to be granted; and [iii] even were such problems ignored, introduces interoperability break points by applying only to normative (non-optional) portions of the specification. For those reasons the Foundation has cast a "no" ballot on the latest draft WS-RM specification.
Microsoft's IPR commitment to the OASIS WS-RM Technical Committee ("TC") states that "Microsoft commits to provide licenses as required by the OASIS IPR Policy for compliant implementations of the WS-RM specification."
The Microsoft patent application cited on that page was published on March 6, 2006 and is reproduced here.
A. NO DEVELOPER RIGHTS GRANTED
However, the only applicable IPR document published by Microsoft that discloses its RAND conditions in regard to WS-RM -- the MOSP -- in fact grants no rights whatsoever, using the all too-familiar device of misleading weasel-words to convey the misimpression that it does grant rights.
The Foundation's work includes development of software tools to enable interoperability between Microsoft Office and applications supporting the OASIS/ISO OpenDocument specification, including applications establishing connectivity via Web Services protocols. Because of that work, the Foundation has had a front row seat in regard to the cognitive dissonance between Microsoft's public statements about the MOSP's meaning and what the MOSP actually says. The MOSP is Microsoft's RAND IPR document for another specification the Foundation deals with in its daily work, the Ecma 376 Office Open XML specification.
The fact that the MOSP actually conveys no rights whatsoever was explained in detail in the EOOXML Objections document published on Groklaw's Grokdoc wiki. The Foundation incorporates by reference that legal analysis of the MOSP as applicable to WS-RM and refers the reader there for a more detailed explanation.
The Foundation believes that Microsoft could easily comply with the narrow requirements of the applicable OASIS IPR policies providing it is willing to abandon the rights it presently and quite inappropriately reserves through its lawyers' machinations in the MOSP. (There is no question that Microsoft has been aware of the criticism of the MOSP in the Grokdoc EOOXML Objections document but has not since altered the MOSP accordingly; therefore, there is evidence that the MOSP's *continuing* conflict with well-established OASIS IPR rules is intentional.)
The WS-RM TC operates under the RF on RAND mode specified in OASIS IPR policies at section 10.2. . Striking all discussion of "Microsoft ecessary Claims" in the MOSP and substituting in their place the definition of "Essential Claims" in OASIS IPR Policy section 2.7 would remove nearly all incompatibilities of the MOSP with the minimum requirements of the RF on RAND IPR mode this TC operates under:
"Essential Claims - those claims in any patent or patent application in any jurisdiction in the world that would necessarily be infringed by an implementation of those portions of a particular OASIS Committee Specification or OASIS Standard created within the scope of the TC charter in effect at the time such specification was developed. A claim is necessarily infringed hereunder only when it is not possible to avoid infringing it because there is no non-infringing alternative for implementing the Normative Portions of that particular OASIS Committee Specification or OASIS Standard. Existence of a non-infringing alternative shall be judged based on the state of the art at the time the OASIS Specification is approved."
Notice that the OASIS definition uses the traditional "patent or patent application ... that would necessarily be infringed by an implementation" grammatical construct of patent licensing law rather than the rights-extinguishing MOSP "patents that are necessary to implement" construct. The OASIS construct is well understood in patent law; the Microsoft construct might as well read "apples that are necessary to implement" software. It bestows no rights.
The MOSP grants no rights whatsoever and for that reason violates OASIS IPR rules.
B. MOSP OMITS RIGHTS REQUIRED TO BE GRANTED
A more minor but still significant problem is that the MOSP does not encompass the full range of rights required to be granted by OASIS IPR Policy section 10.1.1 ("make, have made, use, market, import, offer to sell, and sell, and to otherwise directly or indirectly distribute"). The MOSP only mentions "making, using, selling, offering for sale, importing or distributing," omitting "have made," "market," and "indirectly distribute."
The rights thus excluded are important, encompassing: [i] all works for hire; [ii] all marketing of infringing software except to the extent that "offering for sale" might be understood as a synonym for "marketing;" and [iii] and indirect distribution of such products through, e.g., sub licensing schemes such as those commonly used by free and open source software developers.
The Foundation believes that the TC seriously errs if it does not insist that Microsoft grant the omitted rights.
C. INTEROPERABILITY BREAK POINTS
The Foundation is also concerned that the MOSP creates legal barriers to implementing applications' interoperability by denying patent rights to implement any non-normative (optional) features and even normative portions of the specification that are not described in detail and are merely referenced in the WS-RM specification. Even were the problem ignored of the MOSP not granting any rights whatsoever, the rights granted would extend to "only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification."
That is a straightforward violation of OASIS IPR policy. Under section 10.2.1, Microsoft may permissibly disclaim rights to implement non-normative features. ("Such license need not extend to features of a Licensed Product that are not required to comply with the Normative Portions of such specification.") But the company may not permissibly extend such an exclusion to encompass normative features, even if they are not described in detail and are merely referenced in the specification.
Microsoft's lawyers thereby exclude from any grant of rights in regard to WS-RM not only optional features, but also any other specifications or standards that are required to be implemented if they are not described in detail and are merely referenced in the WS-RM specification.
And the lawyers' client thereby reserves the right to break at will the interoperability of other developers' implementations by later asserting patent rights against any WS-RM implementation that is fully conformant.
But the related interoperability breakpoints do not necessarily end there. Like the OpenDocument 1.0 specification, WS-RM incorporates by reference the definitions of keywords to indicate requirement levels established by RFC 2119. The Foundation urges that at least one of those definitions be expressly set forth in the WS-RM specification rather than being merely incorporated by reference:
"MAY This word, or the adjective 'OPTIONAL', mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to *interoperate* with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to *interoperate* with another implementation which does not include the option (except, of course, for the feature the option provides.)"
(Emphasis added; punctuation errors in original.)
At present, the MOSP limitation of patent rights granted to "only the required portions of the Covered Specification that are described in detail and not merely referenced in such Specification" excludes patent rights that may be required to maintain interoperability with other implementing applications. This is so because the RFC 2119 definition of "MAY" that makes interoperability mandatory is not described in detail
and is merely incorporated by reference in the WS-RM specification; therefore, the interoperability features otherwise required by the definition of "MAY" are excluded from patent protection by the MOSP.
The Foundation's developers have learned that optional features are commonly used as interoperability breakpoints by Microsoft's developers, particularly those that permit standards to be embraced, extended, and extinguished through proprietary extensions armored by patent claims.
The mirror image of that issue is currently being writ large in the Europe, where Microsoft's principle defense to disclosure of the Windows and Windows Server communications protocols to FLOSS developers is the thicket of patents and patent applications with which it has surrounded those protocols. See e.g., Microsoft v. Commission, Case T-201/04 R, Order of the President of the Court of First Instance (22 December 2004), para. 122. ("In its application for interim measures, Microsoft states that certain of the communications protocols that the Commission requires it to provide are covered by patents or patent applications and that it intends to file, before June 2005, a large number of patent applications covering various aspects of the Windows Client PC and server operating systems covering the communications protocols referred to in the Decision")
The Foundation believes that under the circumstances, WS-RM should not be approved unless the RFC 2119 definition of "MAY" is set forth explicitly in the text of the WS-RM specification. Much of the Foundation's interoperability work is aimed at bridging the gap between client side office suites and Web 2.0; that work will entail reliance on the Web Services specifications. The Foundation does not wish its work or the work of other FOSS and independent developers to be held back by a patent thicket inappropriately surrounding Web Service communications protocols.
D. AUTHORITY TO INSIST ON CHANGES IN MOSP
The TC members have ample authority for insisting that Microsoft revise its Open Specification Promise to remove its incompatibilities not only with OASIS IPR rules but also with principles of openness and the goal of interoperability.
The TC operates under the RF on RAND provisions found in section 10.2 of the OASIS IPR rules. Under subsection 10.2.2, TC members are authorized to insist on terms more generous than the minimum requirements established by the rules:
"With TC's operating under the RF on RAND Terms IPR Mode, license terms that are fair, reasonable, and non-discriminatory beyond those specifically mentioned in Section 10.2.1 may also be included, and such additional RAND terms are left to the Licensees and Obligated Parties involved."
The Foundation believes that the Microsoft Open Specification Promise should be recognized for what it is, only one of many Microsoft attempts to thwart competition from independent and free and open source software developers by manipulation of communications protocols and file format standards, enforced by an IPR thicket. In this instance, Microsoft violated the minimum requirements of the OASIS IPR rules in order to do so.
For the reasons described in this document, the Foundation has objected to Microsoft's legal tactics by casting its ballot against approval of the latest WS-RM draft specification. The Foundation stands ready to withdraw its ballot should the issues addressed above be resolved to its satisfaction.
"Microsoft has a published patent application under United States Publication No. 20060047947 that contains one or more **claims which,** if allowed and issued, **may be essential to implement** the Web Services Reliable Messaging (WS-RM) Specification currently under development at OASIS. *Microsoft commits to provide licenses as required by the OASIS IPR Policy for compliant implementations of the WS-RM specification."*
Buck Martin "Marbux", Legal Director of the OpenDocument Foundation
Gary Edwards, President of the OpenDocument Foundation