Open Standards and Open Source

by Rowan Wilson on 11 March 2013

Introduction

Free and open source software has succeeded through its innovative licensing model and its collaborative development methods. Together these allow people who share a problem to also share a solution, and to improve that solution through their combined effort. Of course, free and open source software does not have a monopoly on this kind of technological collaboration. Since well before free and open source software existed, technologists have been creating standards that allow their products and services to work together, to benefit both themselves and their customers. Increasingly these days, these standards themselves are defined collaboratively within the technology industry, and the techniques they contain made available under licence to collaborators and competitors alike. Like free and open source software, these collaborative standards are often also described as ‘open’.

In the past the worlds of standards and software were more distinct; technological interoperability relied heavily on physical factors like the diameters of bolts and the shape of connectors. However as technology has become increasingly computerised, more and more standards, and the techniques they contain, are embodied in software alone. Open standards and open source sound like a perfect fit, but are they?

Copyright and Patent Rights

To consider this question, we should begin by noting that there are two main varieties of rights that are relevant here: copyright and patent rights. As the author of some software, you have the same right over it that a poet has over their poem – copyright. Copyright gives you the exclusive right to control the making and distributions of copies of your particular work. On the other hand, as the inventor of a technique that might be used in a standard – for example an innovative way of compressing video data – you will likely apply for patent protection, which if granted will give you the right to control the making and distribution of any work that uses your technique.

Clearly therefore patent rights extend far further than copyright, and as a result they are harder to obtain. Copyright occurs automatically as soon as a work exists outside the author’s head, and protects just that work itself, not the ideas behind it. Another program could be written to do the same job using the same technique but with different code and it would not infringe on the original author’s copyright. If the author wanted to protect the technique itself they would need to apply for a patent, and in doing so pay various fees and show that the technique is useful and new. Some readers may wish to point out here that – unlike in the US - it is not possible to patent software in Europe. Indeed according to the European Convention of the Grant of European Patents 1973, this is strictly true. However the non-patentable status of software in Europe has been in practice gradually eroded over the intervening years, as pressure to fall into line with the US has caused European national patent bodies to grant protection for what are essentially software patents. OSS Watch has a document on this phenomenon. In relation to free and open source software in particular, it is also worth noting that because, by its nature, it can be shared across national boundaries freely, the notional absence of software patents in a given territory is little protection against unwitting infringement somewhere.

Collaboration and Licensing

So as a software author, you (or your employer) automatically gain copyright over the work you create, and may be able to also gain patent rights over its techniques if they are useful and new. If you choose to license that software out under a free or open source licence, you will primarily be granting rights under copyright - rights to copy, modify and distribute the program itself. Depending on the licence you choose, you may also be licensing your patent rights, if any. ‘Openness’ in the sense of open source here refers to the open offer of rights to anyone who chooses to take them, as defined by the Open Source Initiative’s Open Source Definition or the Free Software Foundation’s Free Software Definition. It is also often extended to refer to the open development model that the open licensing model allows, which permits unmediated collaboration between all interested parties.

While standards will tend to primarily comprise patent rights, as opposed to copyright, ‘openness’ in relation to standards has a similar general profile to that of free and open source software. Historically there has not been a single precise definition of ‘openness’ in standards that has pleased everyone, and the various bodies set up to create standards have taken somewhat differing approaches to what openness implies. These are largely driven by the business needs of the technology companies that are responsible for the innovations on which the standards are based. In general though, there is the same focus on the twin themes of collaboration and licensing. An open standard, it is generally agreed, will need some kind of collaborative governance process that allows all interested parties to have a voice without the risk of one party forcing decisions that will damage other parties’ interests. It will also need a model of licensing of the essential patents to all interested parties that does not give an unfair advantage to anyone. This second criterion gives us the acronyms FRAND and RAND (Fair, Reasonable and Non-Discriminatory) as convenient ways of describing the terms under which patents in open standards must be licensed. What do these terms mean specifically? Unfortunately, like the term ‘open standard’ itself, (F)RAND is something of an indefinite term. Indeed a recent lengthy court battle between Apple and Nokia hinges on exactly how we should interpret the words ‘fair’ and ‘reasonable’ here. Suffice it to say that a range of models are encompassed by the phrase, from a waiving of all intellectual property rights in the standard, through a promise to avoid asserting those rights against implementers, to a ‘patent pool’ approach where a flat fee is collected from implementers and shared between all who contribute patents to the standard.

How Do They Work Together?

Given that we are dealing with two distinct notions of ‘openness’ here, just how easily can we implement open standards in open source software while abiding by all the relevant conditions? To examine this question let’s look at a fictional example:

Barry wants to take a piece of open source software and extend it to implement an open standard. When he has done that, Barry wants to supply the software to his customers under an open source licence, while being sure that he has all the necessary rights to do so.

Now if Barry had written the entire piece of software himself, and did not want to make it available under an open source licence, he would have a relatively simple task: he would need to arrange for a licence to the standard for each copy of the software he intended to supply. If the licence to the standard was available without a royalty being payable, he might be able to get away with just notifying the body that administers the standard of his intention. If the licence to the standard was in the form of a so-called ‘non- assert’ (essentially a promise from the patent owners to not enforce their rights against implementers of the standard) then he might not even have to do that. In the most onerous case he might need to both inform the standard body and negotiate a licence fee for each copy he wished to supply.

As well as ensuring that he has the necessary rights to implement the standard, in some cases Barry will need to satisfy the standard setting body that his implementation is truly conformant. For example, he may need to have the software certified as compliant by a third party testing agency or register with the standards organisation as a supplier before being able to display an official badge or ribbon on his site indicating compliance. These requirements apply whether the implementation is closed or open source.

However, the fact that Barry wishes to reuse and extend an existing open source project introduces a couple of additional potential complications. These are covered in the sections below.

Does My Open Source Licence Allow It?

Firstly Barry will need to establish if the free or open source software licence covering the code he wants to reuse actually allows him to distribute an adapted version of the code in combination with a patent licence covering the standard. Most do, but the GNU General Public License (GPL) family of licences specifically forbid it in most cases. Examining exactly how this condition operates is beyond the scope of this document, but luckily there is a paper in the journal International Free and Open Source Software Law Review which examines the question in some detail. Put briefly, the GPL family of licences stipulates that you cannot distribute the software they cover if you have to pay someone a patent fee (or indeed any other kind of per-copy fee) to do so. The rationale for this is that it discourages a patent holder from making intellectual property claims against distributors of GPL- licensed software; should they succeed in showing that the distributor needs to pay you a fee, the distributor would have to shut up shop anyway, leaving the patent holder with no ongoing revenue stream from them. This would be less problematic if it were not for another feature of the GPL family of licences: copyleft. This stipulation states that – in order to build upon GPL-licensed software – you must agree that your resulting software will be covered as a whole by the same GPL licence¹. In combination these two conditions mean that if you adapt a piece of GPL-licensed software to implement a standard that requires a royalty payment, you cannot distribute it. A significant proportion of free and open source software is covered by one of the GPL family of licences, and a significant proportion of open standards require some kind of royalty payment. Therefore we can see that, for a significant subset of open standards implemented in free or open source software, there is a real licence compatibility issue. However it should be noted that where a standard is royalty-free or covered by a ‘non-assert’, implementation in adapted GPL- licensed code is likely to be possible. Where in doubt, Barry would do well to ask the owners of the software he is adapting whether they think his plan accords with their licensing intentions.

Does It Break My Development Model?

If Barry succeeds in finding free or open source software code that does not forbid adaptation to cover royalty-bearing standards, he may still face an issue with the open development of his code. Free and open source licensing allows anyone to adapt software that it covers without consulting the owners directly. This lowers the barrier to collaboration considerably. One can simply download the code and start hacking. If the code in question requires additional steps to use or distribute, this adds to the burden of becoming a developer. Depending on the licence associated with the standard, a developer may need to inform the standards body, pay a fee, or negotiate a licence. It is also possible that the original developer may be restrained from even providing the code to the new developer before they have obtained permission from the standard owner.

A further complication is that the permissions associated with standards are often granted on condition that the licensee is actually implementing that standard. This preserves the ability of the patent owner to license out their patent on their own terms for other uses. So while a licence may cover a particular piece of free or open source code that implements the standard, if someone were to adapt the code to some other purpose, while retaining the patented process, they may find themselves outside the boundaries of the original permission. This is a particular problem with ‘non-asserts’, in that they can be easily assumed, because they appear to be a general promise directed at all implementers, to be just as broad and flexible as free or open source licences, while in reality they often cover only limited fields of use. In addition, as mentioned above, formal compliance may need to be tested on a program by program basis, meaning adapted code automatically lose its compliance certification until restested.

While, for any given version of a piece of software, these issues can usually be addressed through contact with the standards body, they have the effect of placing obstacles on the way of genuinely free and open development. If Barry is hoping to attract collaborative effort to his project, he will need to make very clear what potential collaborators need to do in order to safely use and distribute the code and their adaptations.

Shouldn’t We Just Avoid Standards Then?

Given these complications, it is tempting to say that we should just avoid implementing standards in free or open source software. While this would simplify some aspects of an open developer’s life, there are good reasons to reject this approach.

Firstly, refusing to engage with standards does not guarantee you will not end up infringing the associated patents. Software patents are a real problem whether one seeks deliberately to implement them or not. It could be argued that awareness of the standard at least allows a developer to engineer around the protected solution.

Secondly, while we have focused on what can go wrong, there are plenty of standards out there (such as those published by the W3C) which have royalty free licences associated that are compatible with all forms of free and open source software licensing. Intelligent analysis of the available standards can often result in an unproblematic solution. Ignoring the problem is less likely to produce that outcome.

Thirdly, standards are a route to interoperability, which is a highly attractive objective. In both the public and private sector, money is wasted every day on painstakingly converting data from one IT system for use in another. In many ways free and open source software, with its low cost of acquisition and widespread distribution, is ideal for addressing these issues and providing ‘glue’ to link disparate systems together. However if standards implementation is closed off for free and open source software, this opportunity is severely diminished.

A Role In The Public Sector

Taking up that third point, it should be noted that within the public sector, particularly in the UK, many serious problems have arisen over the years with lack of interoperability of IT systems. The National Health Service’s £12 billion National Programme for IT is often cited as an expensive project that has failed to deliver largely due to issues of failed interoperability and over-reliance on a small number of large suppliers and solutions. If such failures are to be avoided in the future, it seems an important policy objective to broaden the number of suppliers and solutions available, to increase competition, and to break up large IT objectives into more manageable sub-tasks. In doing this it is crucial that one does not thereby increase the interoperability problem – a very possible outcome if we adopt more small solutions and interoperability standards are not effectively identified and implemented. Broadening the market for solutions means accepting all suitable candidates, closed or open source. Therefore, it could be argued, public policy should attempt to level the playing field for providers of IT solutions, large or small, closed or open. As we have seen, certain kinds of licensing models associated with standards can be hard to integrate with free or open source licensing and development models. How, then, should we make sure we as tax payers are having our money spent in the most efficient, broadest market for IT solutions.

One possible approach is that taken by the UK government’s Cabinet Office in its Open Standards Principles policy document (pdf link). This policy seeks to mandate the use of royalty free open standards in government procurement of software related to “interoperability, data and document formats in government IT.” The policy explicitly states that it seeks to level the playing field “for open source and proprietary software providers competing for government IT contracts.” While the policy is targeted at Central Government, the Cabinet Office states that it will seek to promote the policy in the ‘wider public sector’, including presumably the Higher Education sector. Certainly, as this document seeks to show, the requirement for royalty free open standards in publicly funded software should have the effect of making it easier to use free and open source software for public sector IT. The resulting widening of choice in procurement should produce greater value for money, and if so, the Higher Education sector should seek to enjoy this benefit too.

Conclusion

Open standards are valuable, as is free and open source software. Although embodying the former in the latter is not a trivial matter, the benefits to interoperability and reusability are such that the effort is worthwhile. If you need advice on the interaction between open source code and open standards, OSS Watch can help.

The greater use of open standards and open source software in public sector IT seems likely to produce better value for money. Similarly, considering free and open source software alongside proprietary software in public procurement will widen choice and thereby improve value for money. Combining open standards with some kinds of free and open source software can be problematic, but sticking to standards which are royalty free can alleviate most of these problems.

OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.