UK: The New European Interoperability Framework: Opening Competition To Both Proprietary And OS Software Solutions

The European Commission adopted on 16 December 2010 the long awaited revised version of its vision for creating interoperable, pan-European public services in the form of its Communication "Towards interoperability for European Public Services"¹. This latest communication is the second stage in the Commission's plan for creating such services and forms part of its wider ISA Programme and Digital Agenda. The first version of the Commission's Interoperability Communication and Framework on which version 2 is based was adopted in 2004².

As well as setting out the historical and political context for the revised framework, the Commission's recent communication establishes a revised agenda for creating interoperability through the new European Interoperability Strategy (EIS) and European Interoperability Framework (EIF v2). It is the EIF v2 which contains the substantive guidance on how public administrations in Europe should work together in creating interoperable services and provides the blue print for a new era of public IT and technology provision.

The wording finally adopted by the Commission in a short but heavily contested paragraph of the EIF, tucked away at the back of the document, marks a shift in the Commission's understanding of open standards in the IT sector. It involves the recognition of an important technical and legal principle in the tendering for public IT and technology contracts, namely that an 'open' specification or standard can and sometimes should contain IP, provided that it is licensed on FRAND³ terms. This principle underpins the need for those procuring in this field to ensure that all available options for the provision of services, both proprietary and open source alike, are evaluated and given equl opportunity to participate in the process.

The basic aim of EI

Broadly speaking, the EIS's agreed vision is that by 2015, interoperability will have:

"significantly fostered European public service delivery through;

• appropriate governance, organisation and processes in line with European Union policies and objectives; and
• trusted information exchange enabled by commonly agreed, cohesive and coordinated interoperability initiatives, development of interoperability frameworks and agreements and interoperability standards and rules".

The EIS sets the direction and priorities for European public service collaboration to achieve interoperability and groups activities under three headings:

• trusted information exchange;
• interoperability architecture;
• assessment of ICT implications of new EU legislation.

The General Principles of the EIF v 2

Having set out its agenda and strategy in the EIS, the EIF elaborates in greater detail some of the mechanisms by which public organisations will collaborate to provide joint delivery of services. It specifies common aspects of collaborative programmes such as the need to agree common vocabulary, concepts, principles, policies, guidelines, recommendations, standards, specifications and practices. The guidance it provides to European public administrations is based on a number of key elements which include:

• 12 underlying principles summarising the expectations of public administrations, businesses and citizens regarding the delivery of services;
• the establishment of a conceptual model for public services structuring the design of public services and highlighting when and where interoperability is necessary; and
• the identification of four levels of interoperability: legal, organisational, semantic and technical.
• the definition of interoperability agreements based on standards and open platforms;

It is in the last of these key elements, the technical aspects of interoperability agreements in which a crucial principle for the creation of a fair, open and competitive process has been debated and largely resolved.

Interoperability Agreements based on Open Standards and Platforms

For software providers, the definition of interoperability agreements based on standards and open platforms has a significant impact on their ability to participate in the considerable opportunities for public service tendering that are heralded by this initiative. Moreover, not only will it be an opportunity for the supply of technology for the initial contracts that create the basic platforms and structures to establish interoperable services, but the network effects that are likely to arise from being involved in such major pan-European public projects will be significant with all the wider benefits that this implies.

It is not surprising, therefore, that the guidelines which define how technical specifications are to be drawn up and selected by public bodies have been heavily scrutinised to ensure that they do not exclude or discriminate against certain types of software provider.

It is Section 5 of the EIF v2 that sets out the Commission's position on the role of interoperability agreements in creating pan-European services; interoperability agreements serve to formalise the cooperation arrangements between organisations at a legal, administrative, organisational, semantic and technical level.

On a technical level, it is inevitable that more than one specification may be able to provide the basis for the cooperation agreement and therefore the criteria by which authorities should decide which specification to use is defined, based on the broad principles of transparency, fairness and non-discrimination. Elaborating on these principles, the Commission sets out a methodology which includes the need to assess relevant formalised specifications which are:

• tailored to the specific interoperability needs of the public administration concerned; and
• based on objective criteria primarily related to functional interoperability needs.

When there is a choice of various relevant formalised specifications, selection should be determined on the basis of:

• quality of implementation;
• market support;
• potential for resusability;
• openness;

It is the last of these criterion, "openness", that has been at the heart of an important debate and generated a degree of controversy within the software community as proponents of FLOSS (Free, Libre Open Source Software) have historically claimed the term 'open' as their own. In many cases, they equate 'open' with lack of license fees or royalties and in the standards context, they suggest that an "open standard" must not have any patent royalties associated with it because they claim that patent royalties are incompatible with FLOSS licenses. There was a very active public debate about this issue and EIF v2 has resolved it.

Paragraph 5.2.1 of the EIF v2 rejects that assertion in its contextual definition of the meaning of 'open specification' which accommodates both proprietary and open source software implementations. It provides as follows:

"If the openness principle is applied in full:

• all stakeholders have the same possibility of contributing to the development of the specification and public review is part of the decision-making process;
• the specification is available for everybody to study; and
• intellectual property rights related to the specification are licensed on FRAND(FN1) terms or on a royalty free basis in a way that allows implementation in both proprietary and open source software (FN2).

FN1: FRAND: Fair, reasonable and non-discriminatory. FN2: This fosters competition since providers working under various business models may compete to deliver products, technologies and services based on such specifications."

From this it is clear that FRAND based patent license is not considered incompatible with implementation of standards in open source software, a position which accords with EU law in other fields (such as EU competition law) and is the recognised basis upon which IP is incorporated in standards where detailed IP policies have been elaborated (such as the ETSI IPR policy). Moreover, the Commission itself recognises this need for consistency at an earlier stage in the document where it states in the Communication⁴ that the EIF must be compatible with other EU programmes and policies:

"The EIS and the EIF will be maintained under the ISA Programme and kept in line with the result of other Digital Agenda actions on interoperability and standards such as the ones on the reform of the rules on implementation of ICT standards in Europe to allow the use of certain ICT fora and consortia standards, on issuing guidelines on essential intellectual property rights and licensing conditions in standard-setting, including for ex-ante disclosure, on providing guidance on the link between ICT standardisation and public procurement to help public authorities to use standards to promote efficiency and reduce lock-in."

The second footnote is also an important point. The Commission has been careful to recognise the need for specifications not to unfairly exclude different types of business models⁵. This accords with the general principles of public procurement policy, since to exclude or discriminate against large sectors of potential suppliers at the point of the tender specification would not only weaken competition, but would limit the choice of the public administration, potentially tying it, unnecessarily, to one particular model which might not, in all circumstances, be the best option. The exclusion of FRAND licensing and the insistence on royalty free standards would weaken the position of those companies that rely on a software/IP licensing model and provide an unfair advantage to those companies who have business models that would benefit from not paying IPR royalties. Recognising FRAND, however, not only opens up competition from proprietary providers but also permits any open source solution that does not use a FLOSS licence which prohibits the distributor from accepting a FRAND patent license, of which there are many, such as BSD, Apache and the European Public License. Even some upstream third party patent licenses with a royalty have been deemed compatible with the GNU General Public License, the one FLOSS license often pointed out as having the most tension with FRAND⁶.

The new wording of this section of the EIF represents a major shift from the definition of openness in EIF v1 which came down clearly against the recognition of IP rights in standards and stated that for a standard to be open it needed to comply with the following four characteristics:

"1) The open standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.

2) The open standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.

3) The intellectual property - i.e. patents possibly present - of (parts of) the open standard is made irrevocably available on a royalty free basis.

4) There are no constraints on the re-use of the standard."

The new definition of open specification or standard in EIF v2 demonstrates that treatment of IP in standards in the software sector is coming into line with other sectors of the economy where the need to protect the investment and innovation embodied in IPR is recognised and balanced against the need for open, fair and transparent standards, available to all. Neither side of the equation is given free rein to promote their own business models or solutions to the exclusion of the other and, just as competition authorities have had to strike that balance, so too will the public administrations involved in procurement.

Footnotes

1. Brussels 16.12.2010 (COM 92010 744) Final

2. http://ec.europa.eu/idabc/servlets/Docd552.pdf?id=19529

3. FRAND: Fair, reasonable and non discriminatory.

4. Paragraph 3.1

5. Common business models in the ICT industry include (1) a software and IPR licensing based model, (2) a services or subscription based model, (3) a hardware based model and (4) an advertising based model, with the last three business models relying most heavily on the use of FLOSS in their product offerings.

6. One of the most widely publicized examples where a company reconciled the GPL with the licensing of third party patents involved the settlement of the Firestar v. Red Hat case, involving claims of infringement relating to Red Hat's JBOSS issue-to-rest/). With great fan-fare, Red Hat announced that it had settled the case and acquired a patent license from Firestar that was fully compatible with the GPL, and Eben Moglen of the Software Freedom Law Center gave his endorsement of the settlement, saying "we hope to see more settlements of this kind" (see http://www.redhat.com/about/news/prarchive/2008/patent.html). The terms of the license make it clear that Red Hat paid a royalty of some sort, although the precise details were redacted from the agreement when it was made public (see http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf).

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.