Skip to content

Clarification from MS - and time to eat some humble pie?

Stephen McGibbon of MS points out, tactfully, (in a comment to an earlier article here) that I have not read the MS Open Specification Promise (OSP) carefully enough. At the end it has the words:

… this Promise also applies to the required elements of optional portions of such specifications.

So, just to be clear, let us go through this again. The OSP takes the form of a promise not to sue where an implementation of OpenXML requires the use of a MS patent and that patent is used without permission. This approach is currently the state of the art. It is used by MS, IBM and maybe others. It has several advantages for third parties:

(1) the OSP applies to a long list of specifications, not just OpenXML, so people only have to get used to one wording;

(2) no consultation with MS is required, the promise applies automatically (and under most systems of law is legally enforceable when a third party acts in reliance on it);

(3) it is royalty-free (whereas ISO/IEC, for example, only require reasonable royalties negotiated in a non-discriminatory way).

I have discussed in an earlier article the issue, which many have raised, that it does not apply to future versions of the standard. My conclusion is that whilst it would be good if MS was prepared to make this extension, I can understand its reluctance, and as far as I know no one else has done it (certainly the IBM and Sun promises on ODF do not appear to do so).

So the remaining question is whether the OSP actually covers all relevant patents. The doubt, which I raised yesterday and the day before, is whether it covers any patents needed for the many “optional” parts of the standard.

Starting at the beginning, the OSP is:

… not to assert any Microsoft Necessary Claim against you … [in relation to] any implementation to the extent it conforms to [a specification in the list, which includes Ecma 376, the current version of OpenXML] … ‘Microsoft Necessary Claims’ are those [patent claims] … necessary to implement only the required portions of [Ecma 376] that are described in detail and not merely referenced in [Ecma 376] … this Promise also applies to the required elements of optional portions of … [Ecma 376].

Despite its inordinate length, Ecma 376 does have several elements which are not “described in detail” but “merely referenced”, typically legacy features. So that is certainly a problem.

But leaving that aside for a moment, the critical wording is that coverage extends to:

those [patent claims] necessary to implement only the required portions of [Ecma 376] … this Promise also applies to the required elements of optional portions of … [Ecma 376]

Certainly I deserve some humble pie (perhaps someone could supply it, I am not sure I have ever seen it, I believe it is made from deer). But whereas I was earlier fairly clear what the wording meant and that it did not cover enough, now I am just mystified. What on earth does it mean?

“only the required portions” plus the “required elements of the optional portions”

Evidently, it is envisaged that the “portions” of a specification can be classified as “required” or “optional”. But the optional portions can be further subdivided, so that they contain some “required elements”. Unfortunately, it is certainly a possible view, as discussed here and here that essentially everything in Ecma 376 is optional, so if this right, the OSP still covers no patents relating to it.

Do not get confused between “necessary” and “required” (which is easy to do)! The OSP only covers patent claims which are “necessary” for implementing the specification. That is perfectly reasonable. So that is not what “required” is on about. It is a property of the specification not of any related patents.

But the clear implication of Stephen McGibbon’s comment is that MS was not simply intending to exclude all optional parts of OpenXML from the OSP. So what on earth was it intending to do? And there is still the problem left aside above about legacy features not fully described.

So, unless I am still missing something or being stupid (more pie), I come back to my earlier conclusion that it is completely unclear whether or not the OSP is sufficient or not, and the National Bodies need to insist as a matter of urgency that MS clarify the position.

2007 08 02 Do u love MS? Comments (7) Permalink

A small point …

I must have spent hundreds of hours in “drafting meetings” with high-powered (ie expensive) lawyers in investment bank meeting rooms. One thing I learnt was that such people tended to argue equally strongly for minutiae and for major deal-breaking points. Of course, that was correct. We were typically arguing about “prospectuses” and other public domain documents and it was important to get them right. Quite apart from legal issues, pride was also at stake. No one wanted a document to go out with a flaw, however minor.

I mention all that because of the word “only” in this critical extract from the MS OSP:

those claims … that are necessary to implement only the required portions of [OpenXML]

Why is “only” there? It certainly reads oddly. A clumsy writer might have used it thinking that it just reinforced “necessary”. But the OSP was clearly drafted by, or in conjunction with, lawyers, probably expensive lawyers, and they are careful with words.

Suppose OpenXML has a “required” feature X and another feature Y which is not “required”, and that a MS patent P is necessary to implement each of these two features. If you deleted the word “only”, then the OSP would cover P, because it was necessary for X, a required feature. But, as drafted, the OSP does not cover P, because it is not only necessary for X, but also for Y, which is not a required feature!

Either MS is devious, or its lawyers had an off-day. I am inclined to think the latter, but in any case we urgently need clarification from MS.

2007 08 01 Do u love MS? Comments (3) Permalink

Open XML and patents - Part 3

Rob Weir has an interesting article about “optional” parts of OpenXML.

Here I want to deal with a rather different point from most of those that Rob is making, namely the bearing that this has on MS’s OSP.

In OpenXML and patents - Part 1 and Part 2, I discussed whether MS’s Open Specification Promise (OSP) was (1) compliant with ISO/IEC requirements, and (2) compliant with best practice in this area, which I took to be what IBM has done.

My conclusion was that although there are differences between IBM, Sun and MS, they all seem to have adopted a broadly similar approach which goes some way beyond the ISO/IEC requirements. In other words, MS is compliant with best practice.

However, there was one important caveat which resulted from two exclusions in the wording of the MS OSP. One of these (inclusion by reference) need not concern us here. The other was that the OSP does not apply to those parts of the standard which are not “necessary”. I had not researched as carefully as I would like which those parts were, so I simply said that this was an important issue which needed to be clarified. Clearly, if significant parts of the standard are excluded from the OSP, then far from being compliant with best practice, it is not even compliant with the ISO/IEC requirements.

Rob’s basic assertion is: “Everything in OOXML is optional. This should be repeated until it sinks in. Everything in OOXML is optional.” If that is correct, then it would seem to follow that nothing is necessary and hence that the OSP is completely vacuous in relation to OpenXML and totally fails even to meet the ISO/IEC requirements.

Is this reasoning correct? Well, I don’t know.

We need to look carefully at some wording. Like most standards, OpenXML distinguishes between normative and informative parts. Roughly speaking the operative parts of the standard are the normative parts, whilst the informative parts are there to help you understand the normative parts. So that is not the distinction we are looking for, but it tells us that we can confine our attention to normative parts. Part 1 of this massive standard is relatively short (a mere 163 pages) and sets out “fundamentals”. Clause 2 (normative) explains “conformance”. A “conforming document” must meet various criteria (clause 2.4), but can (unsurprisingly) be almost arbitrarily short and empty of content. A “conforming application” “shall not reject any conforming documents of the type expected by that application … [and] shall be able to produce conforming documents”.

Developers are obviously interested in “conforming applications”, and the things that are necessary for a “conforming application” would seem to be the things that are “necessary” in the OSP language.

At first sight, essentially nothing positive is required of a conforming application. It must be able to produce conforming documents and it must not “reject” anything. A sufficiently empty document could certainly be made free of patent infringements, and if displaying nothing counts as “not rejecting” a document when it is opened, then an application could certainly do that without infringing any patents.

I wonder, however, whether a court would take that line. Suppose the application was intended to be a full-fledged document suite, so that it “expected” to be able to open any document, surely failing to do so in a useful way would count as “rejecting” the document. So if implementing the specification in the standard sufficiently to be able to open and properly display a complex document required use of MS patents, then surely these patents would be (in the words of the OSP) “necessary to implement only the required portions of [OpenXML]”? The fact is that I don’t know!

So I think I end up more or less where I got to a few days ago: it is completely unclear whether or not the OSP is sufficient or not, and the National Bodies need to insist as a matter of urgency that MS clarify the position.

2007 07 31 Do u love MS? Comments (4) Permalink

Points for National Bodies (NBs) on OpenXML

1. A vote in the current letter ballot (ending Friday 31 August, unless you want to work weekends) has just two effects:

(A) it gives you a ticket to the Ballot Resolution Meeting (BRM);

(B) any comments (formally, “technical reasons”) you append to a No vote get pooled with other NB comments, and the comment pool essentially forms the agenda for the BRM.

2. It is irrelevant whether there is a majority for or against OpenXML (or a split vote) in the letter ballot. There will still be a BRM. [Yes, there are some precedents for not holding a BRM, but it is almost inconceivable that there will not be one in this case.]

3. There are only two kinds of vote: Yes (formally, approve), and No with comments (formally, disapprove with technical reasons). Many people who should know better get this wrong. Look at the JTC1 Directives! [Yes, it is arguable that if you append unique comments (not made by any NB voting no) to a yes vote, they may be accepted as part of the BRM comment pool, but it is not certain. In any case, by voting yes you are signalling clearly that you do not really care about the comments.]

4. Prior to the BRM the comments from all National Bodies will be sorted, “deduped” (duplicates removed), and non-technical comments junked. It is hard to tell at this stage, but it is likely that this process will give somewhere in the range 400 - 1,000 comments. It could take the BRM a substantial amount of time to work through these comments. Much will depend on how the meeting is organized and chaired. It seems unlikely that the BRM will start before February or March 2008. It could have dozens of meetings, spread over many months (formally, these may count as the same meeting with adjournments). In any case, attending the BRM could be a substantial commitment of time. The real votes will take place at the BRM, so to participate you have to find representatives able to commit the time (and remember to vote Yes or No in the letter ballot, voting “abstain” doesn’t count);

5. You can vote however you please at the BRM, without regard to your letter ballot vote - although you may attract some adverse publicity if your votes are flagrantly inconsistent;

6. The BRM is fundamentally a negotiation. That means you have to approach it as a professional negotiator. Technical types are often purists. They say objections X and Y are inconsistent, so I can only put one forward in my “No with comments”. This is completely wrong. A comment is effectively a suggested amendment. A good negotiator often puts forward inconsistent amendments, or amendments he cares little about. One thing is certain, you are not going to get everything you want. Putting forward at the start only the things you regard as absolutely essential is bad negotiating! You need chips you do not value that you can trade for chips you do value.

7. A “no with comments” vote in the letter ballot is effectively a “conditional yes” vote. You are signalling that if you can be adequately accommodated on the comments, then your vote will switch to yes. But suppose you want to vote an “unconditional no”? Then you should put forward “technical reasons” which are in practice impossible to accommodate - for example, that the standard is incompatible with the existing ISO/IEC standard in the area (ODF). Of course, you might decide, after the BRM had agreed to substantial changes to the standard, that although this comment was still valid, you wanted to vote Yes. You are entitled to do so, and no one is likely to complain too much. After all, compatibility with ODF is a matter for your (technical) judgment. On the other hand, whereas no one can stop you voting yes in the letter ballot and then voting a solid no at the BRM irrespective of what changes are proposed, that course is likely to attract criticism. Indeed it might garner ill-will from other NBs that you wish to work with in the future on other matters.

2007 07 30 Do u love MS? Comments (4) Permalink

OpenXML and patents - Part 2

In Part 1, we sketched out the background and identified two criticisms of MS’s Open Specification Promise (OSP). The first was that it does not cover future revisions of the standard.

There is obviously a difficulty about a covenant not to sue covering future changes, because no one knows what they might be. The general concept of the covenant not to sue is that the patent rights are not completely given up, but may be maintained and yield royalties or block rivals in other areas apart from the standard in question. It is possible that future revisions of the standard might radically extend it, perhaps against the wishes of the vendor, into an area where the vendor was enjoying a significant royalty stream which it did not wish to forego.

As far as I can see, IBM and MS both restrict their covenants to the existing standard, although IBM makes clear in the associated FAQs that it would normally extend it to future revisions. MS has been repeatedly attacked by the Open Source community for its failure to cover all future revisions of OpenXML upfront.

On the other hand, Sun has sought to cover future revisions of ODF by extending the covenant to: “any subsequent version thereof (”OpenDocument Implementation”) in which development Sun participates to the point of incurring an obligation, as defined by the rules of OASIS, to grant (or commit to grant) patent licenses or make equivalent non-assertion covenants”. This has also been attacked in a pro-MS blog on the basis that “if Sun does not like the development of ODF it can hold up the development of the standard until there is certainty that it does not violate any of Sun’s patents. This is quite a big deal …”. I am not sure I quite follow the reasons why it is a big deal, but I can see that it suffers from similar problems to the IBM/MS approach.

I cannot get too excited about this debate. ISO/IEC require that licences to any necessary patents must as a minimum be made available on non-discriminatory terms, and MS has clearly opted for the covenant not to sue approach, so in practice either MS would extend its OSP to cover the revision, or the revision would have to be redrafted to avoid the relevant patent claims. It would be nice if MS took the view that an intergovernmental body like JTC1 was not going to absurdly over-extend a future revision of OpenXML simply to deprive MS of the benefit of its patent claims, and hence agreed upfront that the OSP covered all future revisions. But IBM and Sun have not yet gone much further than MS, so I cannot see why MS should be singled out for criticism on this point.

The second point of criticism (see, for example, Grokdoc) is that in the OSP the patent claims covered are those “that are necessary to implement only the required portions of [OpenXML] that are described in detail and not merely referenced”. The wording is infelicitous, but there appear to be two exclusions:

(A) patent claims necessary for parts of OpenXML that are not “required” parts; and
(B) patent claims necessary for parts of OpenXML that are merely referenced, not described in detail.

It is not clear to me what MS was trying to achieve by these exclusions, but they present a serious problem in the context of OpenXML because large parts of the standard are apparently optional and there are numerous references to material outside the standard itself. Accordingly, it is completely unclear at first sight, what effect these exclusions have.

The Common Guidelines (.pdf) which contain ISO/IEC’s minimal requirements on patent issues require “any party participating in the work” to “draw … attention to any known patent or to any known pending patent application, either their own or of other organizations”. There is the usual problem of poor ISO/IEC/JTC1 drafting, but this requirement clearly places an obligation on MS to disclose all relevant patent claims. As far as I know it has not done so, presumably on the basis that the OSP makes it unnecessary for anyone to negotiate a licence as envisaged by the Common Guidelines.

However, this basis falls apart if it is unclear whether the OSP does have this effect. So it seems fairly clear that MS must:

(1) remove these exclusions from the OSP; or
(2) clarify which patent claims are covered and which are not, so that it is clear how it has complied with the ISO/IEC requirements.

(2) may well lead national bodies to look carefully at which parts of the standard are “required” and which are not. In many cases there are alternative ways of representing the format of a document, one of which is meant to accommodate “legacy documents”. Suppose that implementation of these alternatives is not “required” parts by the standard (which appears to be the case), then they are apparently not covered by the OSP. So if they are covered by MS patent claims (which seems likely in at least some cases), then the only vendor who can implement them is MS or anyone whom MS chooses to favour with a licence.

However, the whole rationale for having this standard in addition to ODF is, according to MS, the way in which it allows legacy documents to be represented. So these “non-required” parts of the standard are actually absolutely fundamental, and it would be absurd, and quite contrary to ISO/IEC policy, to have a standard which only a single vendor (and its favoured associates) could implement (because of patent constraints).

2007 07 29 Do u love MS? Comments (9) Permalink