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.

RAND: Not So Reasonable?

Microsoft's case against Motorola brings into the spotlight some politically correct jargon hiding unpleasant truths about standards

Article comments

Fair, Reasonable, Non-Discriminatory - surely that all has to be good stuff?  RAND sounds so good, and it's been showing up in all sorts of news lately. It's a key part in the negotiation of licenses for patents that apply to standards, and it stands for "Reasonable And Non-Discriminatory", excellent words that it's hard to criticise. Sometimes it shows up as FRAND, with "Fair" in front making it sound even better, or as RAND-z, with the Z indicating that whatever the license terms are they will have a zero pounds price ticket attached.

RAND appears in the rules and procedures of most standards organisations and actually does a great job in most of them. It's far better than the alternative, which is for patent holders to be able to either license their patents at whatever price each victim will pay, or to make the standard almost impossible to implement by anyone they don't want to be able to by selectively withholding a license. You can understand why a standards group would want to mandate RAND, FRAND or RAND-z, given the alternatives.

Of course, there is the obvious question of why any standards body would allow something to become a standard in the first place if one of the companies contributing to it holds a patent on a technique essential to implementing it. Many of us think that software standards in particular should be no-patent-zones. The presence of a RAND-z terms requirement in the usually-used rules of all relevant software standards organisations back us up. Unlike the telecoms industry, for which patent royalties on standards are a way of life, software standards are usually created today under a requirement that participants don't charge implementors.

Not So Fast...

That all sounds so good. But just like Glyn, I have a problem with RAND terms. Not because it's impossible to make them work for open source software. The best case for open source is when it implements open standards, ensuring your supplier has no lock-in hold on you beyond their impressive implementation and stunning service. There are plenty of examples of standards that have been implemented as open source, most under terms that can be shoehorned into the "RAND" definition.  No, my problem with RAND is that it doesn't exclude terms that knowingly discriminate against open source implementations.  If the only restriction on the games corporations play is RAND, there are still plenty of games that can be played that disadvantage open source implementation. Even with FRAND.

This is not theoretical. When Microsoft offered to license its patents on Sender ID for e-mail back in 2005, it offered them under RAND terms that most companies were willing to live with, most notably without requiring payment for the patent licence. But they required each user of the patent to register with them in order to gain that licence, erecting an immediate barrier to any open source project where there was no single entity to negotiate and hold a licence once for all.

When RAND terms are required (be they FRAND, RAND-Z or plain RAND), they indicate a desire to hold in reserve the option of controlling the relationship with the end user, introducing different terms depending on the competitive and market context. This scope for additional restrictions and for variability dependent on the field of use is what makes any form of RAND a red flag to open source developers.

RAND terms provide some protections against the abuse of patents in standards and are not a bad thing per se. As standards bodies get updated we'll see the requirement that a standard be implementable in open source become a condition of standardisation. Until then, the presence of a RAND requirement does nothing alone to guarantee open source implementation will be possible and should be seen as a warning flag provoking further questions and additional explanation s and definitions to ensure software freedoms remain available for implementors.


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
* *