New legislative means to foster software interoperability within the European Union? A survey of the measures envisaged by the European Commission in the Digital Agenda
| Autor | Begoña González Otero |
| Páginas | 379-392 |
Page 380
In the framework of the Digital Agenda, the European Commission published last June 2013 the results of a research on the possibility of introducing new measures that would facilitate access to software interoperability. This research of the Commission was released in the form of a Staff Working Document 1. Although the Commission concluded that the adoption of new legislative measures was unfeasible, an analysis of its study could be very much instructive to explore future tools to foster software interoperability.
In this article, the current legal tools will be analysed as well as the new regulatory options that have been considered by the Commission in its Staff Working Document. All in all, this paper will show that some of the proposals contained in this Working Document bring about greater uncertainty about at what the cost is for the Commission when trying to foster licensing of software interoperable information. For a second time it seems the Commission is focusing on compulsory licensing. The impact of copyright on encouraging both licensing and access to interoperable information has been underestimated and the importance of pursuing EU ICT standard reform has not been taken into consideration.
The survey of this Working Document has been structured thereby: firstly, what software interoperability means is explored in practice and what the interoperability problem in the ICT sector is. Afterwards, the paper examines the measures proposed in the EC Working Document, and finally the paper suggests some recommendations and considerations aimed at achieving more motivation-, innovation- and competition-therefore enhancing ex-ante disclosure of software interoperable information.
The first problem to define software interoperability is that there seems to be no general agreement on what it is. Neither the extensive review of definitions in technology, business, policy and legal literature, nor case studies that reveal an acceptably uniform definition of interoperability. On one end of the spectrum, there are some definitions that only focus on technological aspects, while broader frameworks on the other end distinguish and very broadly define interoperability at various levels, including, for instance, legal, organisational and political levels. An apparent conclusion is that interoperability is a very context-specific concept. However, when it comes to software interoperability, all definitions pivot around the same idea: «the ability of two pieces of soft-
Page 381
ware to exchange information and mutually use the information that has been exchanged» 2.
From a practical perspective, what is particularly visible is the role that software interoperability plays in the Information Society when it fails. And it is very easy to find examples in our everyday life, such as an attempt to transfer a video file obtained from a popular online store to a media player manufactured by a competitor, formatting hassle associate to data upload to a cloud service for sharing with other providers, or changing file-formats from one software version to the next.
In addition to this, over the last few years software interoperability has not been regarded as a phenomenon that should be studied and developed as a rigorous mathematical and scientifically-lawful phenomenon. The current means of dealing with software interoperability is much the same as the way mechanical problems were handled prior to Newton: ad-hoc trial-and-error constructions that were completely local to the present problem, and with no sense that each problem is an example of a set of globally-valid laws that are expressible in mathematical equations that directly reveal the real structure of the problem and the means of solving it 3. The word «interoperability» is generally being abused and even though we share the opinion of some scholars about interoperability, it is not an all-or-nothing concept 4, in fact, from a strictly software perspective, interoperability is not so hard to define.
It is common nowadays to read that software interoperability and software compatibility are synonymous terms 5. Also, any software interoperability failure can be solved through a compatibility solution. Although the second statement is true, its main consequence leads us to an «intraoperability» framework and not to an interoperability one.
In plain English: software compatibility means that we could make two software products that mutually exchange and use information, work together, but without knowing why or how. Software interoperability allows two pieces of software to work together as they do with any two others (because we know why and how).
In a compatibility or intraoperability situation, one piece of software is somehow central and dominant, either by market share, attitude or acquiescence.
Connectivity is supported by protocols and data formats that favour the
Page 382
central software, and the provider often prescribes those. The goal is to absorb all-important data and process it into the central software ecosystem, thus, it is in this sense the prefix «intra» is used 6. In this situation, to solve an interoperability failure, we may need special licensing to use the protocols or formats, and the central vendor may even try to standardise the specifications with strange rules stating that one cannot break compatibility with their products. The licensing might even prevent the use of the formats, protocols, or even a user interface from competitors or creators of open source software. It may be in the immediate economic interest of the other players to participate, but they do so with the tacit agreement that they are agreeing to play in an asymmetric environment where the primary advantages go to the one in the centre.
Consequently, some market players provide a high level of intraoperability by allowing users to transfer content from one device to another without restriction; other competitors create and operate in a closed environment that is tightly controlled by digital rights management and low levels of interoperability 7.
For software interoperability to work, the key factor is open standards. Open standards do not favour any software provider or developer; they only allow for two pieces of software to work together as they do with any other two. From a market perspective, open standards do not impede that one of the software providers holds a dominant position but this dominant position has been achieved by abusing an asymmetrical intraoperable situation.
The problem of creating robust and high-quality software open standard, one that meets the needs of vendors and customers, users and implementers, public and private sectors, now and over time, is complex and context-dependent. Due to the peculiarities of the ICT sector itself, there are any numbers of reasons why a particular open standard for software may succeed or fail in the market, and meeting the open standards requirements is no guarantee that the standard will magically succeed on that fact alone. In addition to this, open standards initiatives are purely a voluntary effort, and anecdotal evidence suggests that companies with patent portfolios might easily interfere or even block such initiatives 8. Furthermore, standard-setting processes are normally complex, timeconsuming and relatively expensive when compared to unilateral or bilateral approaches; arguably, their cost efficiency is comparatively low 9.
As will be explained in the next point, any given level of interoperability is likely to be the result of a complex interplay between different factors. However, we should not overlook the fact that software is functional work. This means a
Page 383
program may succeed in the market because the application or service is faster, more reliable, more secure, and more scalable, has a better user interface, or more generally, provides a better quality of service. It should not succeed because a provider abuses the word «interoperability» and convinces others that they are on a level playing field.
It is generally accepted that higher levels of interoperability helps to achieve economic growth through innovation, competition and trade 10. Several theoretical models of innovation support this statement 11. From an empirical perspective, cloud computing, bar codes, identity management systems, the internet or web services are just a few examples of how high levels of interoperability can benefit.
On the other side of the coin, high levels of interoperability bring on high levels of standardisation, and the presence of too many industrial standards in a market sector that are capable of pulling over innovation because of the lack of plural and diverse competitive tenders 12.
From an economic perspective, it should not be forgotten that switching costs in the ICT sector are the general rule, not the exception, and this is a twoedged sword: software companies have large incentives to innovate and to be the first to market when by achieving strong network effects, they are competing for the entire market and not just for a share of it 13. When the new software technology developed by a company becomes standard as a result of exploitation of strong network effects rather than for its real value for the society, together with the refusal to allow interoperability of its technology to other market players, that is, when taking advantage of a mismatch, can the reward given to the market player through the standard considered to be excessive? 14.
As a result, the ICT industry is on an evolution continuum of essential noninteroperability to...
Para continuar leyendo
Solicita tu prueba