Blogs

RSS FeedBlogs
RSS FeedSubscribe to this blog
About Author
Glyn Moody

Glyn Moody's look at all levels of the enterprise open source stack. The blog will look at the organisations that are embracing open source, old and new alike (start-ups welcome), and the communities of users and developers that have formed around them (or not, as the case may be).

How Microsoft Fought True Open Standards III

Article comments

In my first two posts about Microsoft's lobbying against true open standards, I concentrated on a document sent to the Cabinet Office in May 2011. Here, I'd like to look at another, sent in October 2011 (available in both html and pdf formats.)

The document has three main sections. The first is headed:

The revised definition would preclude the use of practically all standards that governments (and private sector, including citizens) currently use because no standards are “made irrevocably available without restriction on a royalty free basis.”

Here's the nub of the argument:

As we noted in our comments to PPN 3/11, it is extremely rare for SSOs to require that participants license essential patent claims on a royalty free basis. Aside from the W3C and certain OASIS Technical Committees, the vast majority of bodies that create ICT standards operate under patent policies that allow participants to license their essential patent claims on Fair Reasonable and Non Discriminatory terms (FRAND), including a royalty.

At a stroke, Microsoft dismisses perhaps the two most relevant standards bodies, confirming that it is trying to lock the UK policy into an older, pre-Internet FRAND approach. The whole point is that one of the reasons the digital world has flowered in such an extraordinary fashion recently is because its standards have been RF; excluding W3C is tantamount to excluding the future.

Microsoft goes on:

Accordingly, standards created by the IETF, IEEE, ISO/IEC, CEN/CENELEC and ETSI to name just a few, would all be disqualified from consideration by the open standard definition contained in PPN 3/11 as well as the revised definition.

In fact, that wasn't true for PPN 3/11 or the revised definition, and certainly isn't true for the latest proposals as outlined in the Open Standards consultation. Here's why.

The "Proposed open standards specification policy" states:

Government bodies must consider open standards for software interoperability, data and document formats and in procurement specifications should require solutions that comply with open standards, unless there are clear, documented business reasons why this is inappropriate.

Note "unless there are clear, documented business reasons why this is inappropriate". One clear reason would be that there is no comparable RF standard that can be used. In those circumstances, obviously other standards, that may be FRAND-licensed, will be used. It's hard to understand why Microsoft pretends there isn't this huge loophole that would allow FRAND standards - not least because the proposed open standards specification policy says it again, several times:

When specifying IT requirements for software interoperability, data and document formats, government departments should request that open standards adhering to the UK Government definition are adopted, unless there are clear business reasons why this is inappropriate

and

Standards for software interoperability, data and document formats that do not comply with the UK Government definition of an open standard may be considered for use in government IT procurement specifications

How much clearer could it be?

Microsoft's repeated insistence that the procurement policy will preclude commonly-used standards because they are FRAND-licensed is just nonsense. But its October document does raise one new point:

While it might be possible to say that all patent holders who participated in the development of the standard at the SSO had agreed to make their patents available on a royalty free basis, there is no guarantee that a patent holder not bound by the SSO’s policies will not seek royalties

the revised definition requires that “any patents essential for implementing the standard” must be made freely available. No matter what the patent policy at a standards body, it can never reach non-participants or provide any assurance with regard to “any patents.”

That's perfectly true. There is no way to control what patent trolls may try to do with patents that they claim read on an otherwise open standard. But that's also true for FRAND-licensed standards: trolls may equally make claims there. So although patent trolls may be a problem, they are equally a problem for RF and FRAND-licensed standards, and thus are not a factor in deciding which to choose.

This brings us to the second, and in many way, key argument of Microsoft's October document:

The revised definition is based on an incorrect assumption that current licensing practices for patents necessary to implement standards somehow discriminates or disadvantages developers of Free and Open Source Software.

It then goes on to expand on this as follows:

Proponents of Free and Open Source Software (FOSS) have long made unsupported claims that patents on standards disadvantage FOSS developers and as a result the rules governing licensing of such patents (which are historically based on so-called “fair reasonable and nondiscriminatory” or FRAND terms) need to be modified. The primary claim made is that per unit royalties imposed by some patent holders are inconsistent with the tenets of FOSS licensing and thus preclude FOSS developers from implementing the standard. FOSS advocates maintain that FOSS is an important competitor to “proprietary” software and that policy-makers should therefore intervene to level the playing field for FOSS, by effectively eliminating patent protection in the standards context. We believe that these claims are wrong, and there are numerous instances where distributors of FOSS products have agreed to pay patent royalties. Distributors of FOSS products have created this claim of incompatibility in an attempt to obtain innovative technology for no cost.

Leaving aside that last ridiculous claim, let's examine what evidence Microsoft presents that "there are numerous instances where distributors of FOSS products have agreed to pay patent royalties".

There are hundreds of FOSS projects in the marketplace implementing hundreds if not thousands of standards, so we have to ask “is this a real problem?” and “are there concrete examples where a company was unable (due to FOSS licensing constraints) to implement a standard in a FOSS product because it was unable to comply with the royalty requirement related to essential claims?”

Well, there may indeed be "hundreds of FOSS projects in the marketplace implementing hundreds if not thousands of standards", but what is glossed over here is that those standards are nearly all RF - things like Internet standards from the W3C. In the free software world, it is simply taken for granted that projects can't implement standards that require payments or impose restrictions; the few that do try, proceed without worrying about licensing at all, presumably hoping that companies won't be bothered hunting down minor infringements of this kind.

Moreover, it is striking that among these "thousands of standards" that Microsoft claims free software routinely implements, it can only name two instances of companies that have paid for FRAND licences:

Even vendors of GPL licensed products can take FRAND licenses- as evidenced by Canonical’s decision to take a patent license from MPEG-LA for the H.264/AVC codec for its Linux-based Ubuntu operating system. One of the most widely publicized patent licenses related to an open source product, the license that Red Hat took from Firestar to settle infringement claims, also included the payment of a royalty of an undisclosed amount by Red Hat to Firestar.

There are two crucial points here. The first is that Microsoft is again espousing what I termed the Fairy Godmother solution. That is, it assumes that companies demanding FRAND licensing will always be prepared to offer lump-sum licensing (as with Red Hat - the Canonical example given above is actually based on OEM hardware sales, and has nothing to do with free software that can be shared), and that there will always be a Fairy Godmother that will magically appear to pay whatever the licensor demands.

It's easy to see why this is unacceptable. If FRAND licensing were permitted for open standards, there is no guarantee that a lump sum deal would be offered or that a Fairy Godmother would appear, which would mean that open source projects would be locked out of implementing those standards.

Indeed, if such a FRAND policy were in place, some companies might see it as a perfect way to shut out open source implementations by refusing to offer lump sum licensing - which is why we need RF, to prevent that happening.

The other crucial point is that Microsoft is confusing companies that base their business on open source - like Red Hat - and open source projects. While the former might have the resources to enter into licensing agreements, the latter almost certainly won't, not least because the informal nature of open source means that the project might not even exist in any legal sense, and so there would be no way that a licence could be granted to it.

A FRAND-based standards policy would not only severely damage one of the most vibrant parts of the computing ecosystem - open source projects - but also the companies that are founded on them (just think of Google, Facebook, Twitter etc.) This is precisely the area that the coalition government has said that it wishes to foster here in the UK.

Even if those companies were able (and willing) to act as Fairy Godmothers to open source projects that they have built upon, once their businesses become big enough, they won't ever have the opportunity to do that if projects are forced to avoid those very standards because of the FRAND licensing they have no way of paying for. RF-licensed standards are the only way to avoid this problem.

How Microsoft Fought True Open Standards I

How Microsoft Fought True Open Standards ii

How Microsoft Fought True Open Standards III

How Microsoft Fought True Open Standards IV

Follow me @glynmoody on Twitter or identi.ca, and on Google+

Share:

Comments

Send to a friend

Email this article to a friend or colleague:


PLEASE NOTE: Your name is used only to let the recipient know who sent the story, and in case of transmission error. Both your name and the recipient's name and address will not be used for any other purpose.


We use cookies to provide you with a better experience. If you continue to use this site, we'll assume you're happy with this. Alternatively, click here to find out how to manage these cookies

hide cookie message

ComputerworldUK Knowledge Vault

ComputerworldUK
Share
x
Open