Apart from specific conditions being especially problematic for open source developers, there are several uses of software reverse engineering that aim at purposes, which I am tempted to label as “legitimate,” but which seem quite clearly to be outlawed by the Software Directive. According to technologists,188 the sensible
“goals” of decompilation could essentially be: achieving direct interoperability; achieving indirect interoperability; understanding why some bugs are arising; security purposes; verifying if a copyright violation is taking place. As already clarified, it would almost never be sensible to use reverse engineering to “copy” someone else’s software in a hidden way, at least unless some of the previous goals are also at stake. I also already discussed that direct (vertical) interoperability is surely a legitimate goal under article 6. Pursuing indirect (horizontal) interoperability is arguably allowed as well. Instead, security purposes and the monitoring of copyright violation are likely not legitimate reasons to perform decompilation under European law. The main issue that could be discussed further – even if, as I anticipated, the literature seems to exclude its legitimacy under the Software Directive – concerns error correction.
To clarify what I am discussing, it may be interesting to borrow the following example of error correction from Spoor:
187 Notice, however, that TinyKRNL developers very likely violated copyright law in distributing code obtained through dirty
reverse engineering and which was likely to be a derivative work of Microsoft’s code (even if some of the characteristics of this projects give them a decent chance of being awarded a fair use exception in the US). However, I would not see any economic reason – apart from a literal reading of article 6, paragraph 2, letter b – to consider their activity as illicit, in case they did share just independently written specifications, detailing the main results of their decompilation project of Microsoft Windows. Nor general copyright principles would mandate the illegality of a similar activity.
Some years ago, Tulip Computer, the largest PC-compatible manufacturer in the country and one of the largest in Europe, was one of the first to announce a 386, 16 Mhz PC. Towards the end of the development, the company was confronted with the problem that Lotus 1-2-3 would not access on this particular model; instead a screen message accused the user of using a non-authorized copy. Clearly this was a major problem, since a DOS PC on which Lotus 1-2-3 will not run simply cannot be marketed. Tulip suspected the Lotus 1-2-3 copy protection system to be responsible for the problem. According to Tulip, however, for the very reason that its copy protection system was involved, Lotus refused to provide information and merely suggested that the error was due to some mistake on Tulip’s side. Eventually, after decompiling the relevant piece of software, Tulip found that the copy protection system indeed caused the problem, as it was based on a carefully timed question-and-response procedure which did not function correctly because the system ran faster than the software anticipated. The problem was cured by an adaptation of Tulip’s own microcode, without any change in Lotus software.189
Assuming that Tulip legitimately owned a copy of Lotus software, one could ask whether article 5.1 allows decompilation to be performed for the purpose of error correction. I personally consider that this kind of decompilation should be allowed, since the acts referred to in paragraph 1 include “the permanent or temporary reproduction of a computer program” and its “translation, adaptation, arrangement and any other alteration” (hence, potentially also decompilation). And these activities may be performed “where they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction.” And making a legitimate copy of the software run on a legitimately acquire PC is surely a quite normal goal of a customer.190 To be sure, what article 5.1 clearly and undisputedly
means is that it is possible to install an acquired piece of software on the hard disk and to load it into RAM (in fact, these acts involve copying and would otherwise be forbidden despite being necessary to make use of the program). But the article seams to imply something more, with the working “including for error correction”. In fact, the words “including for error correction” seem to mean that error correction is typically among the “intended purposes” for which a program is acquired and, hence, that it is possible to legitimately “copy” and “transform” the program for this goal. Because of that, I submit that the interpretation allowing reverse engineering for error correction is not only coherent with intellectual property principles and possibly with consumer law,191 but even with the literal text of the Directive. However, I must stress again that the
majority of the literature192 does not agree with my interpretation, especially because decompilation is
considered a special case, completely dealt with in article 6.
To be honest, I also have to acknowledge that my suggested interpretation (i.e. that decompilation is allowed for the purpose of error correction) is quite weak also in the light of some of the implementations of the directive. Indeed, some countries recognized the ambiguity of this provision concerning “error correction” and decided to be more explicit in dealing with it (while others simply copied and pasted it into their national law, leaving ambiguity intact). For instance, under section 50C of the Copyright, Designs and Patents Act 1988 (c. 48) of the United Kingdom (implementing the Software Directive in UK):
(1) It is not an infringement of copyright for a lawful user of a copy of a computer program to copy or adapt it, provided that the copying or adapting (a) is necessary for his lawful use; and (b) is not prohibited under any term or condition of an agreement regulating the circumstances in which his use is lawful. (2) It may, in particular, be necessary for the lawful use of a computer program to copy it or adapt it for the purpose of correcting errors in it.
(3) This section does not apply to any copying or adapting permitted under section 50A or 50B.
And, since section 50A and 50B deal with reverse engineering (which is clearly defined in the UK implementation as “convert[ing] […] a computer program expressed in a low level language […] into a version expressed in a higher level language”), it is clear that – at least in the UK – the possibility of copying or adapting a piece of software for the purpose of error correction does not extend to decompilation. What kind of copying and adaptations could achieve the purpose of correcting (and not simply detecting) errors
189 SPOOR, Copyright Protection and Reverse Engineering, p. 1079.
190 Notice that I will not discuss this issue from the point of view of consumer law, apart from an hint in the next footnote but
this may be another interesting approach.
191 Preventing a customer from correcting defects in a good that has been sold to him would not be reasonable and no customer
would try to do so as long as the seller demonstrates to be willing to correct the bug itself, because of the prohibitive cost of this activity for a single customer – so, when sellers are reasonably available to correct errors themselves, there will be no unnecessary decompilation activity performed by users.
192 See, for instance, GUGLIELMETTI, in Analisi e decompilazione, p. 159: “non è […] consentito compiere atti di riproduzione o
without recurring to decompilation (and to a partial reimplementation and/or creation of a specific patch for the piece of software) is not completely clear to me,193 but – at least – the UK act is unambiguous. Talking
about other implementations of the Directive, only Portugal seems to have drafted its law in such a way that additional scope for a more extensive freedom to decompile (with respect to the one explicitly granted in the Software Directive) could be envisaged. In particular:
Article 6 (2) (a) has not been implemented. Contrary to the Directive it is therefore not ruled out that decompiling acts may be used for goals other than to achieve the interoperability of an independently created computer program. Finally, the implementation of the three steps test requirement is by no means fully compliant with the wording of Article 6 (3).194
To conclude, I have to admit that – whatever the correct interpretation of article 5.1 may be – this issue is by and large empirically irrelevant. In fact, “specific contractual provisions” may derogate the provision of article 5.1 (differently from what happens for the provisions of article 5.2, 5.3 and 6)195 and readers
accustomed to standard software end user license agreements know how systematically decompilation is forbidden, apart from the decompilation activities explicitly and imperatively allowed by the applicable law.