The Updated OSP and Free Software Interoperability

Brendan Scott, August 08 – see further information at this post

Knock me down with a feather – apparently the OSP covers the GPL.

In order for specifications covered by the OSP to be implemented in the free software ecosystem, and therefore for such specifications to be claimed to be interoperable with free software, a number of requirements must be met.  One of those requirements is that free software implementations of the specifications must be permitted.   The FAQ for the OSP has recently been updated to address some aspects of free software implementations.  Apparently the new wording is as follows:

Q: I am a developer/distributor/user of software that is licensed under the GPL, does the Open Specification Promise apply to me?

A: Absolutely, yes. The OSP applies to developers, distributors, and users of Covered Implementations without regard to the development model that created such implementations, or the type of copyright licenses under which they are distributed, or the business model of distributors/implementers. The OSP provides the assurance that Microsoft will not assert its Necessary Claims against anyone who make, use, sell, offer for sale, import, or distribute any Covered Implementation under any type of development or distribution model, including the GPL. As stated in the OSP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft’s implementation of the same Covered Specification. This type of “suspension” clause is common industry practice.

Any statement from the authors of the OSP to the effect that it covers GPL implementations is a good thing.   Indeed, I called for something much like this in February  (actually, I asked for the addition of “A: yes” in the GPL question, but they’ve opted for “A: Absolutely, yes” instead).  However, given the history of this issue it is best to receive it with at least some caution.  Over an extended period during the passage of DIS 29500 through ISO the shepherds of DIS 29500 were repeatedly invited to make a statement about the OSP’s coverage of GPL implementations.   They repeatedly declined to do so, including an express statement of GPL ignorance in the OSP FAQ.   As recently as a month or so ago the Australian arm was bravely reiterating the ignorance line.

Now, apparently, it has always been exceedingly clear that the OSP covers GPL implementations.   Had this been conceded twelve, or even six months ago it would have saved a lot of people a lot of heartache.

Or would it?

It is certainly good to see this concession to the GPL in the FAQ as well as other indications that the OSP may become free software compatible.  We should ask whether this alone is sufficient or whether more would be required before covered specifications can be considered to be interoperable with free software.

One of the reasons that the GPL ignorance line was trotted out for so long might have been concern over the the SFLC’s criticism of the OSP.  To put it in simple terms, the OSP does not travel with the code.  So writing a (eg) GPL* implementation of an OSP covered specification in the expectation that the code may be re-used for other things (which is a cornerstone of interactions in the free software community) creates a problem.  That code becomes encumbered by a patent mine which arms itself when the code is (non-conformingly) reused.  At best, even with this addition to the FAQ, the OSP still fails to respect the freedom of free software implementations (whether GPL or otherwise) of covered specifications.**  It is unclear, for example, what effect the “no surrender of others’ freedom” clauses of the relevant GPLs would be in the event of a successful patent action against a non-conforming implementation.

Aside: Given the clauses in GPLv3 relating to patents and discriminatory patent licences (and the fact that many GPL v2 licences permit “GPL v 2 or later” licensing) it is an interesting question as to whether this endorsement of the use of the GPL will have broader impacts on the patents related to the covered specifications.

Who’s Really to Blame?

In one sense this is a problem created by a defective patent law, rather than the terms chosen by any one company.  In that sense, it would not be appropriate to criticise any particular company for granting a patent licence in terms similar to those used by other industry participants (at least, that is, if the other industry participants had expended the same amount of effort to threaten the open source ecosystem with patent liability).

Notes

* The GPL is used here only for convenience, the effect seems to be independent of the particular licence.

** There is a blog post by Richard Wilder (the link I was first given for this article has 2008/7/25 in the link, but the same article appears to be served for links with this replaced by x/y/z where x > 1000, and y and z < 100)  described by Sam Ramji as a “clarification of the OSP” which discusses partially conforming implementations.  It is not clear what the status of this post is in varying or affecting the interpretation of the OSP, but let’s assume it is a binding statement.  I am not sure I fully understand the context, but the focus of the post seems to be on implementations which are a subset of the full specification covered by the OSP.  While it mentions non conformance due to bugs it seems to indicate that if the bug-affected parts are therefore non-conforming then they will not be covered by the OSP (although the OSP coverage of the conforming part of the implementation will not be affected).  If this reading is correct, then presumably the same logic would apply to non-conforming parts which are due to a modification of code made in the exercise of a person’s freedoms.

IP Issues with OOXML (DIS 29500)

Who’s Afraid of the GPL?

Out of all the free and open source licences which are available, there are two which are disproportionately chosen by FOSS developers when licensing their software. Those two are the GPL and the LGPL. Of these, the GPL is disproportionately favoured over the LGPL.* If there are issues with GPL implementations then there are IP issues with OOXML. Any assurance that excludes implementation under these licences is just cause for the FOSS community to voice concern.

The FAQ on the OSP has this to say about the GPL:

Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?

A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can’t give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s).**

Imagine if you were standing next to someone’s land and there was a sign with the details of an open access promise (OAP), setting out when you are allowed to enter the land. It just so happens that the owner of the land is standing right beside you. You turn and say to them “So, this OAP, I’m here you can check me out, can I enter or not?”. They reply, “Well, I can’t really help you on that, you’ll have to read the OAP. It’s expressed in a simple and clear way – oh, and talk to your lawyer”.

If one thing is certain from that conversation it is that there are issues with you entering the land.

Similarly it is clear that there are issues with GPL implementations of DIS 29500. If there weren’t the answer would be phrased “A: Yes”. In fact, they still can. Microsoft can change the OSP right now by adding “and by the way any GPL implementation is permitted”. But they haven’t and I suspect they won’t.

If there are issues with GPL implementations then there are IP issues with OOXML. Microsoft implicitly concedes there are issues with GPL implementations.

Notes

* These figures are based on data from Sourceforge and relate to the numbers of projects licensed, without being weighted by popularity or maturity of the project.

** This FAQ indicates that those writing the FAQ believe that the OSP clearly permits implementation by some developers but not others based on the licence chosen by the developer. This raises the question of whether or not the OSP is really “non discriminatory” in effect.

DIS29500: BRM Process Unfair for SMEs?

The Issue

The fact that ECMA dispositions on National Body comments are only being made available through a password protected website has been widely reported (one example of many). The BRM convenor notes that this is due to the confidential nature of National Body comments (scroll down to the heading ECMA secrecy). While I had been aware of this before it has only occurred to me this week (while preparing for an informal working group meeting on DIS29500 arranged by Standards Australia – I am an OSIA representative) how difficult this makes it for small organisations to participate sensibly.

The reason is that, during the first phase leading up to the vote, it was easy to leverage off those parts of the specification that other people had commented on publicly. This, in effect, meant that everyone could take the benefit of everyone else’s work. Small organisations could therefore identify relevant issues from those identified by others. Not only did it allow taking the benefit of others’ work it also permitted the incremental improvement of it.

BRM Process Makes Review Much Harder

The BRM process radically changes that dynamic. Now the documents are confidential and, if they are confidential it is hard to comment on them publicly. As such each organisation which is pariticipating in a National Body consultation process is on its own.  With each prevented from interacting with others – collaboration is, in effect, banned. Each is left to trawl through the large number of dispositions to try to make what sense it can out of them. Without seeing other people’s views on the various dispositions it is very difficult to know which are significant and why (and which are insignificant and why not) – or even which dispositions relate to important issues identified in the lead up to the initial vote. The comparatively short time between the availability of the dispositions and the BRM (about 6 weeks or so) compounds this difficulty.

Of course, this gets back to the size of the document. A document one tenth of the size would probably be manageable under this process – even by a small organisation although it wouldn’t necessarily be pleasant. DIS29500 simply inspires despair. Presumably National Bodies will also be in a similar situation. Unless they have a substantial team that they can devote to the process how can they hope to adequately parse the dispositions – and any regressions that they create?

Is this Process Unfair to SMEs?

This creates the additional complication of whether a National Body, if it is required to take into account the interests of small and medium businesses and/or consumers, can reasonably fulfill that obligation under this process (for example, in Australia, the Productivity Commission’s November 2006 Research Report on Standard Setting and Laboratory Accreditation recommended that Standards Australia should “improve the balance of interests represented on technical committees by… increasing the participation of small business,…and other community interests“). If SMEs cannot parse the disposition in the time available, they cannot adequately understand its consequences and cannot therefore adequately represent their own interests to their National Body.