The definition of the legal status of APIs and CPs comes from a balancing exercise concerning incentives to innovate – on one side – and constraints to subsequent derivative and complementary innovation – on the other. Despite the possibility of addressing some of these problems ex post, using competition policy, I think that it is important to address this trade-off also in the initial stage consisting in the definition of intellectual property rights. In fact, as is has been made clear in the Magill and IMS-Health antitrust European cases, poorly defined intellectual property rights are likely to push competition policy in the direction of an excess of intervention or of the definition of blurred rules.322 At the same time, I think that a complete solution of
interoperability-related problems cannot completely rely on IP law and cannot prescind from the role of competition policy. Indeed, antitrust activity addresses the use of market power, which may be higher or lower depending on the configuration of intellectual property rights. Hence, if competition policy is very effective in addressing abuses likely to hinder innovation, then intellectual property rights can be broader and stronger. In addition, technological conditions can allow a combination of contracts and trade secret to complement or partially substitute IP rights: in these cases competition policy is the better candidate, at least in the short run, to recreate an appropriate balance between the incentives to innovate of the first comer and the possibility of subsequent innovation by other players. However – in certain fields – the social costs of
318 In this case – since interoperability is mandated and disclosure free – the barrier to entry represented by the cost of
decompilation is no more at work.
319 I am not aware of any two-sided model considering the cost of reverse engineering or other barriers to achieve
interoperability. My preliminary guess is that, for certain (low) costs of reverse engineering, intellectual property rights on APIs could be needed, to efficiently implement two-sided policies. However, I already explained why do not think that the real world has very low reverse engineering costs (at least for the moment; moreover, better techniques of decompilation would be balanced by more complex systems and “DRM-like” technological protections). In fact, when the cost of decompilation rises, it could become easier to have a sufficient buffer to put in place two-sided policies (this scenario is likely to be the relevant one for the real world). In these cases the problem would be: when should we mandate disclosure (and indirectly compatibility)? A clear cut answer to this second question is likely to be impossible, as demonstrated by several papers about compatibility in two-sided markets (ROCHET &
TIROLE, Platform Competition in Two-Sided Markets; ARMSTRONG, Competition in Two-Sided Markets). What is clear is that – not knowing
a definite general answer – one should be very careful.
320 Indeed, the interpretation of intellectual property proposed in the paper at hand – but also in the third paper of this
dissertation – is very far from implying that the cost of entering the market with a product which is complementary with that of the incumbent is zero. This cost depends not only on the cost of reverse engineering, but also on the cost of a new implementation. (Moreover, at least in the US, innovative interface specifications could, in principle, be patent protected.)
321 See FARRELL & WEISER, Modularity, Vertical Integration, and Open Access. 322 See also DREXL, IMS Health and Trinko.
using antitrust are prohibitive; there, a careful attribution of IP rights can be a more efficient instrument to balance incentives to innovate and the related costs.
In this setting, I think that the analysis performed in this paper allows for the drawing of at least some preliminary conclusions concerning the optimal scope of intellectual property law in the fields, which are crucial for interoperability.
First of all, it is clear to me that APIs and CPs implementations are protected by copyright, as any other piece of software. This is fine and economically sound: copyright protects first comers against complete free riding on their investments in writing source code.323 However, it also clear that this protection is relatively
thin: it certainly covers literal copying and mechanical modifications/translations, but it surely does not extend to ideas and methods. Hence, abstract interface specifications are not copyright protected, no more than the contents of a math book, even thought the book itself – as an interface specification document/manual – is protected against copying.
Moreover, in the majority of relevant cases – at least as far as the practice of the last years shows – interface specifications are usually not very “innovative” in themselves and their strategic value is mostly created by the decisions of users and producers of complementary goods. Hence, also patent law is not likely to represent a major obstacle to software interoperability. And that is even truer in Europe, where the law prevents the patenting of software “as such” and hence makes it quite difficult to claim patent protection for software tools that are aimed at allowing the exchange of data between pieces of software, and hence not likely to have a specific industrial application. That having been said, a patent-like protection for software interfaces could potentially disrupt the careful balancing between incentives to innovate and possibility of creating interoperable products as I described in this paper. Hence, legislators are advised to maintain copyright and trade secret as the main tools used to protect software innovation, thus avoiding recurring to patent in a significant way. (Actually, my suggestion is to avoid software patents completely, but my analysis was admittedly focused on the field of software interfaces, so I cannot exclude that, in principle, software patents could be necessary to protect different kinds of software innovations.)
The crucial points of the paper, that represent its main contribution to the existing literature concerning interoperability, are the constant reference to the specification/implementation dichotomy and the clear distinction between an access phase and a reimplementation phase. I already discussed at large the consequences of the first distinction. But also the second distinction is critical, as only the access phase needs – in order to be insulated from copyright liability – to enjoy a precise copyright exception (statutorily provided or coming from fair use analysis), which is typically conditional on the absence of a significant negative impact of this access to the market for (or value of) the original program. In that way, one can avoid the necessity of recurring to fair use or other “rules of reasons”, which could be tempting for economists, but which could lead to excessive legal uncertainty. In fact, failing to distinguish between access to the interoperability specification and its reimplementation would require an extensive recourse to fair use and it would either suggest to discriminate between vertical and horizontal interoperability (ad suggested by Weiser) or to allow both vertical and horizontal interoperability, but adopting a blurred fair use analysis (as in the aforementioned case, Sega v. Connectix). Instead, the interpretation of copyright that I propose, not discriminating between horizontal and vertical access, is not only coherent with both the prevalent US case law and the EU legislation (as interpreted by the Commission), but it is also compatible with the sketched economic model of software markets I proposed in the General Introduction. In such a model, copyright is an appropriate tool to impede free riding on up-front sunk costs of first comers, but it also embeds appropriate correctives, devised in such a way not to increase development costs of late comers.
Certainly, from a static point of view it is inefficient to develop the implementation of the same specification twice, hence also the solution I propose entails inefficiencies. However, this small inefficiency – coupled with the other waste resulting from the need to perform software reverse engineering to achieve interoperability specifications – may prevent pure free riding from late comers, without allowing excessive and persistent market power into the hands of the first comer.324 Moreover, and luckily enough, the protection of
323 There are some decisions, like the Lexmark (387 F.3d 522) one, arguing that some pieces of software are not protected at all
because of a broad interpretation of merger and ‘scenes a faire’ doctrines: I think that this approach – even if yielding reasonable results in this case – is likely to set weak precedents, unclear legal standards and – despite the fact that the decision I quoted is clearly pro-interoperability, as my paper – it is likely to do more harm than good to interoperability in general.
324 Notice also that the actual existence of this inefficiency could be prevented by the licensing of interoperability information
by the original developer: hence, in several cases where a contractual solution is possible, reverse engineering may just be a threat, increasing the likelihood of a bargain among parties.
implementations and the possibility of free riding on specifications results also from basic standard copyright rules: in particular, the “originality” requirement and the idea/expression dichotomy. In fact, in March 1993, Prof. Miller argued on the Harvard Law Review325 that – more than fourteen years after their deliberation –
CONTU’s recommendations were still looking essentially correct and that the copyright regime was still flexible enough to address the various concerns about its aptitude to deal with computer programs. According to Miller:
“Several key points underlie this conclusion. First, CONTU’s reasoning accords with basic copyright law principles […]. Second, the copyright decisions spawned in the years since CONTU are yielding an increasingly sophisticated, coherent, and predictable software protection regime. Third, copyright principles are flexible enough that it is not necessary to fabricate an entirely different legal regime, sometimes referred to as sui generis protection, for effective regulation. […] Some ambiguity in the short term seems a small price to pay to assure the flexibility and discretion that our judges need to develop a sound software jurisprudence.”326
In fact, it seems to me that it is still meaningful to ask oneself if there’s “anything new since CONTU”. In the meantime, network of judicial decisions (in particular in the US) and scholarly articles adapted traditional copyright law to software. Already at the time of Miller’s article, it was evident that copyright’s flexibility and usefulness had played a significant role in allowing the development of the software industry. Today, however, there are even more reasons to think so. In fact, copyright – probably surpassing Miller’s expectations – demonstrated itself to be especially appropriate as a tool to protect software also because it allowed – with very low transaction costs – the development of the open source model of software development. In that model, some incentives to innovate are sacrificed in order to avoid the costs of secrecy and the cost of “developing around” existing code (risking to reinvent the wheel quite often and forgetting the opportunity of improving existing code, eliminating bugs and increasing its efficiency).
In other words, copyright and trade secret (as long as reverse engineering is free) provide an extraordinary pro-competitive environment for software innovation, being able to accommodate both the traditional model of software development – that has been crucial in transforming informatics into a daily productivity and entertainment tool for both firms and general customers – and the new and promising open source model. Legislators and scholars should be aware of that and – what is more important – should become aware of the reasons for which the current system is actually working. These reasons rely on copyright and on the circumscribed, but significant, possibility of free riding on technical ideas that it entails (positive externalities or technological spillovers, if you like). For the same reasons, policymakers should also avoid – if possible – to excessively disrupt the current system, as may happen by offering excessive protection to ideas and algorithms through software patents (especially if easily warranted) or through an excessive expansions of copyright toward the protection of ideas.
All that having been said, I think that the conclusions of this paper should derive more immediately from a well-designed copyright law. Hence, a clear-cut statement that interface specifications are never protected by copyright – not even as part of the internal structure/form of a software program – would be very useful in order to eliminate some residual legal uncertainty in software markets.