Prelim Minutes of OASIS WS-RX Teleconference

June 7, 2007

Start Time:4:00 PM Eastern Daylight Time

Pqul acted as chair.

Textual Conventions

Ų Action Item

Motion

§ Resolution

1 Roll Call

From Kavi:

meeting is quorate

Tom Rutt agreed to take minutes.

2 Agenda Approval

Agenda

1) Roll Call

2) Review and approval of the agenda

3) Approval of the May 17th 2007 meeting minutes

Preliminary here:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200705/msg00019.html

4) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

5) Dealing with the No vote in the WSRM 1.1 OASIS standard vote

6) Next meeting

7) Any other business

3 Approval of the 5/17 Minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/24303/MinutesWSRX-051707-b.htm

Bob F moved to approve 5/17 minutes, Tom R seconded.

§ No objections, minutes of 5/17 approved.

4 AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

#0132: Sanjay to update the public home page to add links to the documents out for standard vote

Owner: Sanjay Patil

Status: Still Open

5 Dealing with the No vote in the WSRM 1.1 OASIS standard vote

Company:

The OpenDocument Foundation, Inc.*

Vote:

Comment:

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.

Introduction

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. < http://www.microsoft.com/interop/osp/default.mspx>. Many of the protocol specifications with which WS-RM incorporates by reference or must remain interoperable with are included in the MOSP list.

I. DISCUSSION

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") was found at . There, the company 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 at < http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20060047947.PGNR.&OS=DN/20060047947RS=DN/20060047947 >. Its claims appear to read on at least major portions if not all of the WS-RM specification. The Foundation is not aware of any published study of the Microsoft patent application as to its validity under the more exacting standards for determining obviousness of an invention established by the U.S. Supreme Court on April 30, 2007 in the case of KSR International v. Teleflex. . For that reason the Foundation does not not address the validity of Microsoft's patent claims, instead assuming for the sake of this discussion only that they are valid.

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 mis impression 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. < http://www.grokdoc.net/index.php/EOOXML_objections#Patent_rights_to_implement_the_Ecma_376_specification_have_not_been_granted>. 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 Necessary 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. < http://www.ietf.org/rfc/rfc2119.txt>. 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") < http://curia.europa.eu/jurisp/cgi-bin/gettext.pl?where=〈=en&num=79958777T1904+R0201_2&doc=T&ouvert=T&seance=ORD >.

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."

II. CONCLUSION

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.

Footnotes

"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."*

Submitted by:

Buck Martin "Marbux", Legal Director of the OpenDocument Foundation

Gary Edwards, President of the OpenDocument Foundation

Email from Jeff M: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200706/msg00008.html

hi,

I assume from this somewhat cryptic email, that the TC will soon

be taking a special majority vote on whether to "override" the NO

comment and forge ahead.

Oracle has looked at the no comment in some detail.

From our analysis we find ourselves in agreement that relying upon

the Microsoft OSP is not suitable for complying with the requirements

of the OASIS IPR policy. The OASIS IPR Policy is stronger with

respect to:

specification coverage - the obligation is for the entire

specification, not just the mandatory parts;

defensive suspension;

re-distribution requirements;

and possibly some other points as well

BUT we believe that this is NOT relevant to this discussion and our

ultimate vote.

Under the OASIS IPR policy, which all members of the TC are legally

bound to by the OASIS membership agreement, once the 60 day

participation requirement is met, TC members are legally obligated to

grant licenses (or a suitable covenant not to sue/non-assert) to

implementers of the approved specification.

In this case Microsoft have said they will do that twice, once by

becoming and maintaining TC membership, and second in their IPR

declaration. We assume that all the TC member companies will do the

right thing when the time comes for implementers to seek licenses for

implementation of the WS-RX TC's specifications.

So from Oracle's perspective, the only issue that could arise is if

Microsoft were to state that they were relying on the OSP as the

basis for compliance.

cheers,

jeff

Chris F moved to initiate a TC vote to approve the document despite the single no vote, seconded by Bob F.

Mary McRae clarified that this would have to be a special TC majority vote issued by OASIS staff.

No objection , motion to initiate TC vote to approve wsrm Specs despite single no vote.

6 Next meeting

Agreed to meet every 4 weeks, starting July 12.

7 Any other business

Ian Jones moved, seconded by Doug D to give special thanks to Mary McRae for her help in progressing the standard.

No objection, agreed to thank Mary for help in progressing standard.

Meeting adjoined at 4:18 PM EDT.