4. Decompilation in the EU
4.1. Vertical and horizontal interoperability
I already hinted at the fact that the “interoperability” that the Software Directive wants to facilitate encompasses both direct (or vertical) and indirect (or horizontal) interoperability. In this paragraph I discuss this issue and my interpretation in greater detail.
First of all, my reading is backed by the literal text of the Directive. Indeed, article 6 limits the rightholder’s exclusive powers, when that is necessary “to achieve the interoperability of an independently created computer program with other programs”, that is “with other programs” in general and not just “with the decompiled program”. Notice also that the text talks about a single program (that could be decompiled) and a single rightholder (the permission of which is not necessary), hence it is not easy to argue that the plural “other programs” always refers to the decompiled ones. Additionally, this punctual literal element is confirmed in the Preamble, where recital 21 clearly talks about “reproduction of the code and translation of its form […] indispensable to obtain the necessary information to achieve the interoperability of an independently created program with other programs [plural]”. Moreover, and despite the fact that some commentators interpreted the very same legal text, suggesting that article 6 actually allows only vertical interoperability,176 the reading I propose is strongly backed by the general reading of the Directive, proposed
by the Commission (and confirmed by the Court of First Instance) in the recent Microsoft Case.177
In its Microsoft Decision, the Commission explicitly referred to the concept of interoperability “as defined in the Software Directive”, and then explicitly included elements of horizontal interoperability in this understanding of interoperability. For instance, at recital 277—279 the Commission criticized Microsoft’s limited disclosures because “[t]hese disclosures […] have been strictly limited […] to client-to-server communication”, while “the Windows domain architecture involves client-server and server-server interconnections and interactions that are closely interrelated.” In other words, in order to achieve a satisfying level of interoperability, the Commission wanted Microsoft’s competitors to be able to interact at any level of the software architecture, not only connecting to some Microsoft operating systems, but also being able to potentially substitute them. To be sure, in my opinion no duty to actively favor interoperability directly follows from the Software Directive,178 but – if interoperability means what the Commission is describing in
the Microsoft Decision – then there is no doubt that both vertical and horizontal interoperability are allowed under article 6 of the Software Directive.
Of course, I have to stress that the actual broadness of the concept of interoperability in the Software Directive is now widely debated. While some commentators argue that the Commission is stretching the concept in an unprecedented (an probably dangerous) way,179 other scholars are even trying to read in the
Directive a general obligation (not limited to dominant firms) to allow interoperability (not only to let other firms decompile).180 The verdict of the Court of First Instance on the Microsoft case (delivered the 17th of
the visually-impaired person also bought an original copy of the book and if he acts according to several additional restrictions, including the fact that this Braille copy may not be reproduced or sold without the right-owner’s permission. But what is relevant here is that the blind person of this example, having read the Braille version of the book, is not restricted in any way (whit respect to what would happen with an ordinary reader) in the uses that he/she can do of the ideas and methods learned reading the book. And this freedom is not altered by the fact that he/she needed to take advantage of a fair use or other copyright exception in order to access these ideas. Now, imagine that this person decided to write a ferocious and well-founded critique of the book, with the effect of almost annihilating its sales. Logically speaking, the critique may be a consequence of the possibility of reading the book, and this possibility has been granted through a fair use. Nevertheless, this market destructive “indirect effect” of the fair use allowing the person to read the book in the first place would never be taken into account by a judge evaluating the fairness of realizing a Braille version of the book.
176 See, in particular, HART, Interoperability Information.
177 I refer to the Microsoft IV case: Case COMP/C-3/37.792 Microsoft, that led to the Commission Decision of 24.03.2004 relating to a proceeding under Article 82 of the EC Treaty. The European CFI delivered its judgement on Microsoft’s Appeal on the 17th of
September 2007, substantially confirming the approach of the Commission.
178 This is – at least – my opinion and the opinion of the majority of the literature of which I am aware, but see D. Caterino
(footnote 180) for a broader reading of the relationship between the Software Directive and an actual duty to allow interoperability.
179 See, for instance, Robert. J. Hart, “Interoperability Information and the Microsoft Decision”, EIPR, Vol. 28, Issue 7, July
2006.
180 See DANIELA CATERINO, Software e rifiuto di licenza del codice sorgente, Annali Italiani di Diritto d'Autore, 388 (2004). The author
stresses that the notion of interoperability adopted by the European Legislator is very broad, but she also aliments the ambiguity that a “disclosure of source code” is necessary to have interoperability; technically this is not true: even if a full disclosure of the source code is surely sufficient to achieve interoperability, it is not necessary [but I concede that a partial disclosure of source code – or a burdensome decompilation work – may be needed, if API specifications are not up to date or if there are bugs in the original implementation]. The article is also making clear that mere right to perform reverse engineering and to implement anew a set of APIs is not sufficient to solve any problem: “E’ evidente che in siffatte condizioni la coazione al rispetto del mero obbligo di pati, contemplato dalla
September 2007) seems to fully upheld the approach of the Commission and does so without the need to attach two different meanings to the concept of “interoperability” in the context of the Software Directive and of EU competition law. If – as it seems now reasonable to assume – the understanding of the Commission is correct, article 6 of the Software Directive undoubtedly (even if implicitly) allows competitors to reverse engineer a software program to achieve any kind of interoperability, including – for instance – to (indirectly) achieve interoperability with the software which are interoperable with the decompiled one. In other words, article 6.3 cannot be read in a way preventing horizontal interoperability. Notice that a general favor of the European legislator for interoperability, could also be recognized in the Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonization of certain aspects of copyright and related rights in the information society.181
The fact that horizontal interoperability is allowed by the Directive may also be a significant argument in deciding whether the Directive permits the disclosure of the source code of open source software realized also thanks to decompilation.
4.1.1. Does article 6 allow the disclosure of source code?
The economic sustainability of such an open model as the open source one was surely unexpected at the time of the drafting of the Software Directive. Indeed, for the majority of commentators, the success of the open source model of software development was actually more than questionable until a few years ago (or still is!). Hence, the drafter of article 6 of the Software Directive could not have reasonably taken into account the possibility that an undertaking could reverse engineer an existing platform, for instance to achieve vertical interoperability, and then “give away” for free some of the interoperability information incidentally collected during the process, even if this information was not directly useful to him. Obviously, it was easier to envisage the case in which the reverse engineers wanted to sell the obtained information, but the legislator probably thought that – as a matter of fairness – the subject entitled to receive this kind of payment was always the creator, hence the prohibition concerning disclosure of information not needed to ensure interoperability with the independently created program.
The typical scenario in a setting in which there is competition among commercial (closed) platforms is one in which the late comer could try to attract more direct and indirect network effects than the incumbent, and that could lead the late comer to release more interoperability information than the incumbent. However, there are no reasons to assume that a commercial late comer would disclose dramatically more information than the incumbent. Hence, at the time of drafting the Directive, the legislator (and probably also some of the groups lobbying in Brussels) probably thought that the rule embedded in article 6.2.b would have maintained secret a significant part of the information collected through decompilation. Indeed, given the significant investment needed to decompile existing software, who would renounce to almost the entirety of the competitive advantage coming from the fact of being the first reverse engineer? Even in the case of horizontal interoperability and decompilation of an existing software platform, the late comer would not be likely to disclose much more than the incumbent would: in fact, duopolistic competition with the incumbent looks (almost by definition) more lucrative than eliminating any barrier to entry in the market, increasing competition. However, open source projects do release their entire source code, because their commitment to openness is very strong, doing so is a precondition to get support from the community of developers and
direttiva (divieto di impedire od ostacolare le attività di black box analysis e reverse engineering) non è sufficiente a garantire la perfetta conoscenza delle interfacce, ovvero il corretto funzionamento del programma; pertanto, entro questi limiti concettuali deve a mio avviso ritenersi che il titolare del diritto sia destinatario di un vero e proprio obbligo di facere; cui corrisponde, sul piano antitrust, la possibilità per le autorità comunitarie di imporre al titolare del diritto non solo la rimozione di tali misure ed ostacoli, ma altresì un comportamento positivo dell’impresa dominante, un vero e proprio obbligo di disclosure.” What is blurred in this article is the distinction between the obligations of a firm holding a dominant position and the
general obligations of an undertaking active in the software market: the “obligation to do” – obbligo di facere – requested by the EU Commission to dominant undertakings seems to be disproportionably extended to any software house.
181 Recital 54 reads: “Important progress has been made in the international standardisation of technical systems of identification
of works and protected subject-matter in digital format. In an increasingly networked environment, differences between technological measures could lead to an incompatibility of systems within the Community. Compatibility and interoperability of the different systems should be encouraged. It would be highly desirable to encourage the development of global systems.” For additional comments and to better contextualize this statement in the general interoperability debate, see MIKKO VÄLIMÄKI,
testers and – in any case – that is a required condition in order to (so to speak) “free ride” on the contributions of the majority of open source projects, released under copyleft licenses such as the GPL.182
A first question to be answered concerns the compatibility of any open source approach with the restrictions of article 6.2.b. It looks undisputable that the information needed to allow interoperability with the independently created program might be disclosed, even if this information has been originally obtained by reverse engineering another piece of software. However, does this mean that any kind of comments – potentially concerning the interoperability requirements of the decompiled software – can be disclosed? Whatever answer we provide, we risk having a paradox.
On the one hand, if publishing the source code of the interoperable software is legitimate and if – as I argued – horizontal interoperability is a legitimate goal (as the vertical one), then the restrictions of article 6.2.b concerning the disclosure of the obtained information can be easily avoided by the open source world. In fact, any open source project may claim to be working on a competing platform sharing all the APIs and the communication protocols of – say – Microsoft Windows. Having done that, the publication of any result concerning the APIs and CPs of Windows becomes licit, at least as long as a tentative implementation of these APIs is available on the new operating system (in order to couple the disclosure with an “independently created program”). Actually, since the structure of APIs and CPs is frequently disclosed to potential producers of complementary products even before their final and perfectly working implementation in the code (in order to allow them to design the architecture of their future interoperable programs), there are several arguments in favor of allowing even the disclosure of interface specifications that will be implemented, well before their actual implementation. Indeed (as observed by Giannelli)183 there is nothing in
the Directive that strictly dictates the timing of the various activities of decompilation, reimplementation and disclosure (even if all the stated conditions must be respected). Hence, if an early disclosure of specifications – with respect to full working implementation – is commonplace in a given industry, there are no reasons to impede it in case of specification information obtained through reverse engineering (because deciding otherwise would impose a significant and unjustified competitive burden on the late comer). That seems to be essentially confirmed by the comments of the Commission to the Sweden implementation of the Directive184:
The Swedish implementation is only defective in that the phrase “independently created program” is missing from the transposition of Article 6 (1). It would appear, however, that this omission has a significant effect. The missing element was provided in the Directive to ensure that any decompilation of a target program does not occur before the independently created program exists (even if only in preparatory design material form).
Despite the fact that the Commission stresses the need for the existence of an “independently created program”, it also seems to allow for its existence only at the stage of preparatory design material. And there is also evidence that the final design of the program could take into account the information acquired through decompilation, as it would be necessary for an operating systems aiming at being horizontally interoperable with a decompiled competitor.
On the other hand, if the reimplementation of discovered interface specifications was not allowed in an open source model, then article 6.2.b would exclude a significant part of the software world from the benefits of decompilation. In fact, open source systems are not only significant competitors of existing incumbents in terms of market shares.185 What is more important is that open source projects are frequently the most
credible threats of precisely those incumbents that look steadily established as market dominants. I will come back to this point in § 7. If uncertainty is significant only for open source projects, should we really care?. For example, if there is a credible alternative to Microsoft Windows and Microsoft Office for IBM-compatible (or “wintel”) personal computers it is only because of the existence of open source projects, like Open Office.186
182 In fact, copyleft licenses require derivative works (and/or works embedding the licensed one) to be licensed under the same
license (and to publish their source code): this is the so-called viral clause of the license.
183 GIANVITO GIANNELLI, in Commentario Breve alle Leggi su Proprietà Intellettuale e Concorrenza, (Luigi Carlo Ubertazzi ed.,
2007).
184 COM/2000/0199, Report from the Commission to the Council, the European Parliament and the Economic and Social
Committee on the implementation and effects of Directive 91/250/EEC on the legal protection of computer programs.
185 Quote the market shares of Linux, Firefox, but – in particular – Apache, MySQL and PHP.
186 OpenOffice derives from the proprietary office suite StarOffice, realized by the German company StarDivision. In 1999 Sun
Microsystems purchased the source code of StarOffice and started distributing it as a freeware product. However, after about a year, Sun Microsystems announced that it was going to make the source code of its office suite available under the open source
The paradox I mentioned above derives from the fact that article 6.2.b risks being either irrelevant for open source projects (if horizontal interoperability is legitimate and the publication of source code and of any associate documentation is completely free) or unable to attain its intended results in terms of real possibilities of achieving interoperability (if horizontal interoperability is not allowed or if it cannot be achieved by open source projects). At the end of the day, article 6.2.b may be liable of generating just the paradoxical result of protecting precisely the quasi-monopolistic incumbents that sometimes dominate the less dynamic software markets.
Notice that article 6.2.b is not a problematic norm only as far as the analyzed polar cases are concerned. Intermediate “nuanced” cases are not helpful either. For instance, assume that the correct interpretation of the norm would be that publication of the source code is allowed, but only as long as the contained comments are not “too revealing” of discovered interoperability information that is not strictly needed to achieve actual and immediate interoperability with the independent program. Interpretations of this kind would generate significant uncertainty and – if coupled with aggressive communication strategies on the incumbent’s part – also FUD (I will come back in the third paper on some measures to reduce strategic creation of FUD by incumbents). And the effect would either be to create some minor problems to open source projects fighting dominant incumbents (which look already more than strong enough in software markets) or to be almost irrelevant, but still capable of creating some uncertainty and potential litigations.
To summarize, it must be doubted that publishing the source code of software obtained (also) through decompilation may be incompatible with the Software Directive. In general, the publication of the Source Code will be exempted by article 6.2.b. However, some notes and comments attached to the source code may not be freely publishable, if they explain more about the decompiled software than what is needed to interoperate with the independently created open source program. Moreover, some doubts may exist concerning the possibility of disclosing interoperability information which has been obtained through reverse engineering and transformed into API and CP specifications, but which has not yet been concretely implemented in the independently realized software.
4.2. “The movement is everything, the ultimate aim is nothing”
Despite the existence of some different opinions among scholars, issues concerning the publication of source code are not likely to be the most relevant obstacles, which the limitations existing in article 6 could pose to open source projects. Problems that are much more relevant could concern the decentralized and informal process of information exchange that precedes the writing of actual source code. This is why I used, as a title for this paragraph, Eduard Bernstein’s quote about the importance of the “movement” above the “aim”. Indeed, what characterizes open source projects is not only the disclosure of the source code of the final product, but the community-based effort during the realization of the project, which is constantly ongoing and which is connoted by an intense sharing of opinions, drafts and information in general. Moreover, the relationships among various contributors are typically far from being formal and access to various pieces of information is necessarily quite free and uncontrolled.