Skip to content

OpenXML and patents - Part 1

What happens if one vendor has Intellectual Property Rights (IPR) relating to a draft standard? How does that impact on the standards process? Should a standard be approved if compliance would require a licence from the vendor?

In the case of ISO/IEC there is an agreed Common Patent Policy which requires that the patent holder of any known patent must be “willing to negotiate licenses with other parties on a nondiscriminatory basis on reasonable terms and conditions”. Otherwise the standard shall not include “provisions depending on the patent”. This is elaborated further in a .pdf file. It is envisaged that the reasonable terms may include a royalty. It is also envisaged that negotiations may be necessary in each case and that these will take place on a normal bilateral basis, without involving ISO/IEC.

IPR also includes copyright. But it is assumed that if one vendor has existing code implementing the standard, other vendors have no right to copy that code. They are expected (reasonably enough) to write their own code.

In practice, however, the major vendors have gone beyond the ISO/IEC requirements in the case of software. There has been a gradual development over a period of years, so that IBM, MS and Sun have all adopted the policy of a “covenant not to sue”. This has the (substantial) advantages for those who wish to use the standard in question that no royalties are required and no negotiations are required.

IBM has adopted a standard wording in its Interoperability Specifications Pledge which covers all the (many) cases where it promises not to sue. MS has likewise adopted a standard wording in its Open Specification Promise. It is possible that Sun has done the same, but I have not yet found it. The wording that covers its patents related to ODF is in its OpenDocument Patent Statement on the Oasis site.

It is clear that the three companies have studied each other’s promises carefully and they are closely similar, although not identical. This is acknowledged explicitly in Jason Matusow (from MS)’s blog:

… there is a history to the concepts that tracks back to IBM and SUN first. Both of them had released a Covenant Not To Sue for specifications before MS released its OSP. In fact, we read their language very carefully as we approached the drafting of the OSP. The whole point here is to create an environment where a specification may be implemented by anyone, no matter what development model or source code license they may choose. This can happen in such a way that the patents necessary for implementation are a) available for use at no charge and in no conflict with various licensing models, and b) are retained by the rights holder so they may be used in other ways potentially for revenue-generating purposes. The OSP, or CNS, or ISP - all amount to the same conceptual approach which is the idea of enabling implementations while still respecting IP rights … In general, this is a really positive thing.

I entirely agree with Jason that this is positive.

In the context of OpenXML there has been a good deal of discussion of the differences. There seem to be two main differences: (1) the extent to which the promises cover future changes in the standards in the ordinary course of maintenance; and (2) the extent to which the promises cover non-mandatory parts of the standards.

This article is already fairly long and it is now fairly late, so I will defer discussion of these two points until tomorrow!

So how did BSI vote?

The short answer is that it has not voted yet and the decision on how it will vote has not yet been made.

The proceedings of BSI committees are confidential. Since I was a member of the ad hoc technical committee on OpenXML, and was allowed to attend the meetings of that committee and (as an observer) its parent committee on 24 July by virtue of that membership, I am bound by that confidentiality requirement.

The reason for the confidentiality is to allow a “fuller and franker” discussion and exchange of views. I happen to think that reason is outweighed by the importance of public confidence. The public is always sceptical about secret meetings, which is why our courts and parliamentary proceedings are held in public. In my view, it would be much better if the public and press were allowed in to BSI meetings and if participants were free to blog about them. But that view does not release me from the confidentiality obligation.

So I have to content myself with a few procedural comments.

First, BSI committees do not vote. They proceed by “consensus”. I am not sure exactly what that means. I have not read the relevant BSI manual, but I suspect it does not define the term further. Nonetheless, there must be a good deal of lore and precedent on it, with which unfortunately I am not familiar.

Second, the normal procedure involves three BSI committees. The ad hoc committee makes recommendations (if consensus can be achieved) to its parent, IST/41 and that in turn makes recommendations to its parent ICT/-/1. [I think I have finally got that right, with some help! Not only are all the slashes and dashes important, but the S changes to C as you go up to “eye see tea slash dash slash one”!]

ICT/-/1 is due to meet and take its decision on 10 August. IST/41 did not complete its deliberations on 24 July and is due to complete its work in a conference call on Thursday 2 August.

In most cases ICT/-/1 just rubber-stamps the recommendation it receives from the relevant committee (IST/41 in this case). But it need not do so. In particular, if the relevant committee underneath it is unable to reach a consensus, ICT/-/1 does not need to abstain in the JTC1 vote. Indeed, it can go further and vote the opposite way to the recommendation.

The workings of ICT/-/1 are somewhat mysterious. I am clear that it has on it the chairman of IST/41 (or his nominee) and the chairmen of some (or all?) comparable committees in other standards areas, as well as various full-time BSI employees. My understanding is also that MS is not represented on it, although non-members have historically sometimes been invited to attend as observers.

The date of 10 August was probably chosen (I am guessing) to allow time for further consideration in the event that the issues proved too contentious to resolve at a single meeting. There is also the practical point that if the vote was “No with comments” (which is perhaps the most likely outcome as discussed in several previous articles), the comments would have to be put into the standard, approved JTC1 format. Since the number of comments could be large (the BSI Wiki on the standard, which is in the public domain, has over 600 individual comments), and many are not currently in the approved format, this could be a substantial piece of work.

OpenXML - How should the BSI vote? - Part 2

In Part 1, we got as far as noting that the vote should clearly be “No with comments”. MS representatives may try to push “Yes with comments”, but that really amounts to an unconditional “Yes” and should be resisted. So the main issue is what comments should be included and what BSI should require (in the way of meeting them) before it changes its vote to Yes in the inevitable Ballot Resolution Meeting (BRM). In particular, should it require that VML be replaced with SVG, and the MS-variant by MathML before the draft is approved, or is some undertaking about future revision sufficient?

Even more fundamental is the question of whether it is acceptable to have two ISO/IEC standards in the same space. If BSI gives as its “technical reasons to be stated” that the draft standard is in contradiction with the existing ISO/IEC ODF standard, then it is in effect voting an unconditional No, because there is no way the draft can be amended to meet that comment.

MS has claimed repeatedly that the two standards are not in the same space. It claims that OpenXML covers a different area because it is better suited to representing the “legacy documents” - the billions of existing documents saved in earlier MS file formats (mainly binary file formats).

At the first meeting of the BSI technical committee, IST/41/-/1 on 10 May 2007, I asked the MS representatives for evidence to support this claim. If the claim is true, it should be possible to produce a large (preferably randomly chosen) pile of legacy documents which are demonstrably better represented when converted to OpenXML by Office 2007, than when converted to ODF by OpenOffice, or by Office 2007 with one of the “converters”. Moreover, it should be possible to examine at least some of these documents and to see, by reference to the standards, that this is not a function of poor current implementations, but an inherent feature of the standards.

Not a single document has so far been produced. I repeated the request (several times) at the NCC meeting on 4 July 2007 and many times since by email to Jerry Fishenden and Stephen McGibbon (both MS).

When I finally spoke to Stephen for 45 minutes yesterday (by phone), it appeared that MS now takes a rather different line. It believes that in the IT area it is acceptable to have two standards in the same space. The argument appeared to be that otherwise a vendor would have to ensure that its specification became the standard first, to shut out the competition. That would mean that standards were inevitably half-baked, because there would be no time to get them right in the rush to be first. To avoid this absurdity, it is necessary to allow multiple standards.

I look forward to unpicking this argument in detail, but that will have to wait for another day. Suffice to say for the moment that it casts a revealing light on MS’ attitude to the standards process, and that it is wrong! Agreeing a single standard is every bit as fundamental to progress and the common good in Information Technology as it is in other areas.

There are two other issues which the more senior BSI committees might want to consider. One is whether it should be pushing further on the contradiction it raised in the initial 30-day period. The point is that the outcome of the ballot is a matter of how the majority votes, but a contradiction should sink the draft even if raised by only a single National Body. BSI and 11 other National Bodies raised such a contradiction during the 30-day period, but were apparently ignored by the JTC1 Secretariat without following the procedure laid down in the JTC1 Directives.

Finally, there is the question of whether the MS OSP is sufficient. It seems similar to the comparable undertakings by IBM and Sun, but is regarded by some as unacceptable.

OpenXML - How should the BSI vote? - Part 1

This morning sees the final meeting of IST/41/-/1, the ad hoc technical committee formed to carry out a technical review of the OpenXML standard and make recommendations to IST/41. This afternoon, IST/41 meets to consider the technical committee’s report and maybe make a recommendation to IST/-/1, which is the body that actually decides how BSI should vote. Well, subject to some other coordinating committee (IST/- ?) which takes into account the views of other parts of the BSI and may have the power to overrule IST/-/1. According to the convenor (or maybe chairman) of IST/41 there have been no changes in the membership of IST/41 or IST/-/1 this year, so if MS or its enemies have been packing UK committees they were prescient enough to do so well in advance!

So which way should the UK vote? Well, in formal terms that is easy. There are 3 possible votes: Yes, No with comments, or abstain. Abstaining is silly, because you are effectively denying yourself a vote. Voting Yes is also wrong, as explained in the previous article.

Why? Well surely everyone, from the most ardent MS-supporter to the most ardent MS-hater would agree that the standard would benefit from correction of a large number of the minor errors identified by the technical committee, the BSI should surely vote No with comments. That way it puts pressure on the Ballot Resolution Meeting (BRM) to address those errors.

Equally, of course, since it is not possible to vote an unconditional No, if BSI wants to achieve that effect it needs to vote “No with comments” and refuse to change its vote at the BRM.

So the real issue boils down to what comments to include. There are basically four types:

(A) umpteen minor errors in the existing standard (some trivial, some less so);
(B) using SVG instead of VML;
(C) using MathML, instead of a non-standard MS variant;
(D) the fact that the standard is in contradiction with the existing ISO/IEC standard for ODF.

It is hard to see why (A) should not be included. Equally, given reasonable cooperation by Ecma and MS, it is hard to see why amending the standard to take account of them would take a particularly long time. In principle, it could even be done within the month allowed by the JTC1 Directives for the Project Editor to do his work.

(B) and (C) are harder. First, of course, there is a point of principle. MS takes the line that since SVG and MathML are not actually ISO/IEC standards they can be ignored. Others take the view that they are widely accepted international standards (both promulgated by W3C), so it is still wrong for OpenXML not to make use of them. MS’s second line of defence is that SVG and MathML are not adequate for Office 2007. The snag there is that they do not appear to have produced any evidence in support of that contention and a bare assertion is not enough.

Suppose IST/41 or IST/-/1 wanted to include SVG and MathML in the comments. Would that amount to an unconditional No vote? In other words, would it be feasible for the BRM to approve the standard subject to it being changed to use SVG and MathML? Well probably not, unless Ecma and MS really pulled a finger out. But it would be possible for the BRM to approve the standard without requiring SVG and MathML, but with some sort of undertaking that the next revision of the standard should use them. So IST/41 and IST/-/1 may want to consider what kind of undertaking in that direction - if any - they would find acceptable.

Finally, we come to (D). That is probably the most contentious issue. The BSI has already put a marker up by “raising a contradiction” on these grounds during the initial 30=-day period. It could now repeat it as part of its “technical reasons to be stated” (to use the words of 9.6 of the JTC1 Directives). Or it could decide to give up on the point.

Since this article is already long, I will deal with this issue in more detail in Part 2 (and also with some other key issues for the two BSI committees).

OpenXML letter ballot - what does “Yes with comments” mean?

I guess I need to go into this again, since MS is pushing hard for the US INCITS Executive Committee to vote that way.

MS is clever. In war, it is always a good idea to get your opponents onto the wrong battleground. With great skill, MS just engineered a battle in the Executive Committee about whether the vote should be (A) Yes with 96 comments or (B) Yes with 400+ comments. It then “lost” the battle when the Executive Committee put (B) out for a formal vote.

To repeat, just read 9.6 of the JTC1 Directives. You can only signify “Approval”, or “Disapproval … for technical reasons to be stated”, or abstain. But it is true that by implication any National Body can submit any technical comments it wants provided it does so by the end of the letter ballot period (2 September 2007). It is probably also true that the Ballot Resolution Meeting (BRM) is then able to discuss these comments. But, of course, you have still voted an unconditional Yes. The JTC1 Directives are so hopelessly drafted that it is not clear whether you can change your vote to No at the BRM. But that is beside the point, because, of course, your own national rules will almost certainly stop you changing your vote, so if the US goes down this route it will have been tricked by MS into voting an unconditional Yes.

Wake up, Executive Committee! If you actually care about those 400+ comments, you should vote “No with comments”, because then there is the threat that you will not change your vote to Yes until they have been adequately dealt with. MS appears to be putting forward some nonsense about if too many people vote “No with comments”, then the draft will simply be thrown out without a BRM. FALSE. Again, read the JTC1 Directives. It is almost inconceivable that there will not be a BRM. The only way that can happen (at least in compliance with the Directives) is if NO ONE votes “No with comments”.