Blogs

RSS FeedBlogs
RSS FeedSubscribe to this blog
About Author
Simon Phipps

With a focus on open source and digital rights, Simon is a director of the UK's Open Rights Group and president of the Open Source Initiative. He is also managing director of UK consulting firm Meshed Insights Ltd.

Why RAND Is Bad For Open Source

Here's an easy guide to the core issue in the UK Government's Open Standards Consultation so you can participate more easily. Please do - your country needs you!

Article comments

By now, you're hopefully aware that there's a consultation in progress by the UK government on certain key aspects of their procurement strategy. Specifically, lobbying has re-opened the question of how "open standards" should be defined by the government for procurement purposes. The emergence of this zombie issue appears to be related once again to office productivity documents - yes, the OOXML vs ODF issue isn't over.

While this appeared to be settled following earlier work by the Cabinet Office, Glyn Moody has uncovered evidence that shows first how Microsoft, the BSA and associated companies have argued that it is unfair to their proprietary software business to require mandatory standards to be free from patent encumbrances placed by the authors of the standards, and second that this opposition appears to only applies to cases where the standards in question disadvantage proprietary interests.

Issue Backgrounder

A key issue is that of whether a definition of "open standards" can justifiably exclude those which include features that can only be implemented under a patent license. This is dressed up in sweet-sounding words, explaining that the mandatory licenses in question must be on "Reasonable And Non-Discriminatory" (RAND) terms -- sometimes with an even sweeter "F" in front for "fair" -- but it remains clear that those reopening the issue want to be free to tax users of standards they have contributed to or, in some cases, devised.

The term used to describe the alternative is "Royalty Free" (RF) - although I prefer the expression "Restriction Free" in recognition of the fact that patent licensing terms that don't charge money can still include other terms that are a problem for competitors outside the cozy standards system, with its super-intelligent, super-pedantic insiders.

This all sounds pretty academic until you read a tell-tale line from one of the documents Glyn's Freedom of Information request uncovered. Document 12 on that site (PDF) includes a detailed assertion by Microsoft that (F)RAND terms do not inhibit open source implementation of standards.

The fact this argument is included at all reveals the real issue at stake here. Microsoft and its companions don't want to let real open source solutions push them out of government procurement any more than they already have, damaging their large lock-in profit. The Cabinet Office is threatening to level the playing field so they can. The forces of monopoly are pushing back.

The Problem With RAND

The apologists for the forces of monopoly are keen to make complicated, detailed points about all the issues involved. They've been pointing out how many standards we use daily include royalty-bearing elements; but most of these are standards for hardware or telephony where the context is different. They have been pointing out how many organisations permit (F)RAND terms, while overlooking the trend towards RF terms in most software standards activities. And so on; there are many, many of these arguments to wade through and the details are so dizzying that a skilled standards professional can usually persuade you black is a kind of white.

The point, however, is that most open source software is created by communities of software developers without shared affiliation. As such, there is often either no entity capable or entitled to collectively negotiate terms, or if an entity exists it has no means by which to engage on a typical commercial basis.

For example, such an entity has no control over uses of the software by others, since open source licenses give everyone a right to use the software so licensed for any purpose without restriction. Consequently it is unable to estimate volumes, commit users to terms or otherwise estimate metrics upon which to base a fee. Since no collective terms can be negotiated in the general case, responsibility for patent licensing then falls to individuals downstream of the community. It's the associated uncertainty that creates an inequity.

While some RAND-licensed standards have been implemented in open source communities, that does not mean there's no problem. Developers usually avoid technologies where there is licensing uncertainty (both for copyrights and patents). This is especially evident in communities without commercial controlling parties, such as Apache and Debian.

The presence of RAND terms at best chills developer enthusiasm and at worst inhibits engagement, as for example it did in the case of Sender ID at IETF. As Välimäki and Oksanen say, RAND policy allows patent holders to decide whether they want to discourage the use of open source. Leaving that capability in the hands of some (usually well-resourced) suppliers seems unwise.

Is there a way open source communities can live with RAND terms? Well, it turns out RF is not an alternative to RAND, but rather a subset where all restrictions are set to zero. So, yes, open source communities can tolerate RAND terms on patents in standards when those reasonable, non-discriminatory terms mean any individual, community or legal entity can implement the standard freely and fully without the requirement for a relationship with any other individual, community or legal entity. Any other arrangement leaves scope for patent-holders to discriminate against open source.

Non-Assert

The consultation also proposes that, as an alternative to RF patent licensing, patent holders could instead promise not to assert their patents against open source implementations. But I think that apparently enlightened approach is a mistake that discriminates against an unexpected target. There are sufficient grey areas on what could be included and excluded that uncertainty about the "safety" of a standard for open source implementation would remain.

Remember, software under many open source licenses can be embedded in proprietary solutions (as companies like IBM, Microsoft, Apple and Oracle all commonly do). Only a firm, clear RF policy will give certainty that there can be no issues. Indeed, it's possible that permitting non-assertion discriminates against large, legally-sensitive corporations such as those named.

Please Participate

After all those explanations, my conclusion is not in fact to ask you to take any particular position. It is just a plea to participate, preferably now (but certainly before May 3rd). The meshed society of the internet age is one where the voice of everyone with an interest should be heard, and in this case it can. As Linda Humphries from the Cabinet Office says in her blog post:

Finally, please don’t be daunted, we know the questions are tough. That’s why we need your help to get the answers right. You don’t have to respond to all the questions, if there is just one you have a case study for, or if you feel strongly about a particular topic but only have time to answer a couple of the questions, we’d still love to hear from you.


It's important for as many people as possible to express their views. Do please go to the Consultation web site and complete as many of the questions as you can - you can take the three sections in different sittings. Your country needs you!


Follow Simon as @webmink on Twitter and Identi.Ca and also on Google+

Enhanced by Zemanta

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