Decompilation for interoperability
It is well-established that under the EU Software Directive (Directive 2009/24/EC on the legal protection of computer programs), the lawful acquirer of a copy of a computer program is entitled to decompile it for the sake of achieving interoperability with another piece of software. We can define decompilation as a process where the object code of a computer program is transformed into a form of source code. It has to be noted that this source code that is obtained as a result of the decompilation differs from the initial source code of the program.
Article 6 of the Software Directive establishes several conditions for such permitted decompilation. First, the decompilation right should only apply when there is no other way to achieve interoperability with the second program. This would be the case, for example, if the code of the API of the second program is not freely available and the software vendor refuses to provide it upon request. Second, the right can be applied only by someone who is developing an independent program. Third, that person should also be a lawful user of the second program that is to be decompiled. Fourth, the decompilation should only cover those parts of the second program that are necessary to achieve interoperability. Finally, the information obtained through the decompilation should not be used for goals other than achieving interoperability. It should not be shared with third parties and it should not be used for developing a substantially similar program, as this would constitute a copyright infringement. Finally, any restrictions imposed through a licensing agreement by a software vendor on this decompilation right, as established under Article 6, shall be null and void.
A question then arises if there are any other hypotheses under the Software Directive that would allow the lawful acquirer of a piece of software to decompile it without the consent of the rightholder. One lawsuit which started in Belgium and ultimately reached the Court of Justice of the European Union (CJEU, the Court) delineates such second hypothesis for lawful decompilation. The particular legal ground justifying reverse engineering in that case is error correction.
The Belgian dispute
The case at hand (C-13/20 Top System SA v Belgian State) involved a dispute between a software company – Top System, and SELOR which is a Belgian public institution tasked with selecting and preparing the staff for the public authorities. Top System had developed a customized application for eRecruiting at the request of SELOR. At the same time, the application also contained some components that were part of the proprietary Top System Framework (TSF) solution. SELOR and Top System concluded a licensing agreement and a service agreement (for installation, configuration and data migration) for the respective applications. However, during 2008 the parties exchanged communication in view of certain persisting problems that were affecting the eRecruiting application. SELOR then proceeded by decompiling the licensed software without the involvement of Top System.
Subsequently, Top Systems brought an action against SELOR alleging that they had decompiled the proprietary software in question without an authorization and this constituted a copyright infringement. SELOR admitted that it had decompiled a portion of the TSF solution that was incorporated into the eRecruiting application, in order to disable an error-causing function. Further, SELOR claimed that it was allowed to perform such decompilation under Article 5 (1) of the EU Software Directive – i.e. for the sake of error correction.
Subsequently, two questions were addressed by the Brussels Court of Appeal to the CJEU. First, whether the provision of Article 5 (1) of the Directive allows the lawful purchaser of a computer program to decompile that program where such decompilation is necessary to enable that person to correct errors in the software. And second, whether the above-mentioned conditions under Article 6 of the Directive need to be also satisfied for such decompilation.
It has to be noted that from a temporal perspective the facts of the case at hand are subject to the first version of the Software Directive – Council Directive 91/250/EEC of 14 May 1991 on the legal protection of computer programs. This Directive was repealed and replaced with effect from 24 May 2009 by Directive 2009/24/EC. Nevertheless, the relevant provisions that are subject to our analysis have not been amended.
Decompilation for error correction
In answering the posed questions, the CJEU first analyzed which specific acts are involved in the process of decompilation. It postulated that decompilation inevitably involves both the translation and alteration of the respective program and also its reproduction. The “translation” in question is the transformation in form from object code into source code. Additionally, the code is also altered because the so derived source code as a result of the decompilation differs from the initial source code of the program. Finally, as a result of the translation in form, the program is also inevitably reproduced since the different expressions (source code and object code) still refer to the same computer program.
The acts of reproduction, alteration and translation of the computer program are all exclusive prerogatives of the copyright holder. As per Article 4 of the EU Software Directive, only the rightholder can perform or authorize the performance of those acts. At the same time, Article 5 (1) of the Directive provides an exception to the restricted acts. In particular, Article 5 (1) establishes that in the absence of any specific licensing provisions, the above-mentioned acts shall not require authorization from the rightholder when they are necessary for the use of the computer program by the lawful acquirer in accordance with its intended purpose, including for error correction. Based on this analysis, the CJEU proceeded to answer the first question by stating that the lawful purchaser of a computer program is entitled to decompile that program in order to correct errors affecting its operation, without the consent of the rightholder. The rationale of the CJEU was that despite of the fact that decompilation per se is not explicitly mentioned in Articles 4 and 5, its constituent actions – reproduction, alteration and translation are all covered in those mentioned provisions.
As for the second question, the position of the CJEU was that the exceptions in Article 5 (1) and Article 6 have distinctly different purpose and scope and as such the conditions under Article 6, which we outlined above, shall not apply in view of the exception in Article 5 (1). The purpose under Article 6 is achieving interoperability with other software. In turn, the rationale under Article 5 (1) is the continued use of the program in accordance with its intended purpose.
After answering the second question, the Court proceeded to list the conditions that need to be satisfied in order for the lawful user of the software to be able to perform decompilation for error correction without the consent of the rightholder.
First, the CJEU clarifies the concept of an “error”. In the view of the Court, in the field of computing, an error is a defect that impacts a computer program and causes its malfunctioning. Additionally, such defect must prevent the use of the program in accordance with its intended purpose.
Second, the Court postulates that the decompilation has to be necessary for the error correction. In other words, if the error can be rectified without modification of the source code or if the source code has already been provided to the purchaser, then the decompilation would not be regarded as necessary and would not be allowed without consent from the rightholder.
Third, the correction of errors by the lawful purchaser must be subject to the established contractual conditions, if any. In other words, if there are specific contract provisions that prescribe a procedure for error correction they should be followed by the parties. The CJEU gives the example here that the parties can mutually agree that it will be the rightholder who will have to provide maintenance services, including error correction, for the software in question. At the same time, the Court postulates that the rightholder would not be allowed to contractually prohibit the possibility for the lawful purchaser to decompile the software for the sake of error correction. The CJEU bases this conclusion on the text of Recital 17 of the EU Software Directive which reads that “the acts of loading and running necessary for the use of a copy of a program which has been lawfully acquired, and the act of correction of its errors, may not be prohibited by contract.”
Fourth, the results of the decompilation (i.e. the obtained form of source code) cannot be used for any other purpose than error correction. Any potential use for other purposes would constitute a copyright infringement.
Criticism of the CJEU decision
It must be stated that the conclusion of the CJEU on the third point above is questionable and actually has no legal basis in the provisions of the Software Directive. The imposed ban on the rightholder to contractually prohibit the lawful purchaser from decompiling the software refers to the text of Recital 17 of the Directive. At the same time, it is clear that the recitals of a directive do not have legislative force and further, they cannot be used to produce a legal effect that is contrary to that of the actual provisions of the directive. This is the case with the provision of Article 5 (1) which explicitly points out that the acts constituting decompilation for error correction would not require consent from the rightholder, subject to the absence of specific contractual provisions.
Moreover, it has to be noted that the Software Directive explicitly enumerates the cases where potential contractual provisions that contradict its positions would be null and void. Article 9 of the Directive reads that “[a]ny contractual provisions contrary to Article 6 or to the exceptions provided for in Article 5 (2) and (3) shall be null and void”. Obviously, the hypothesis for error correction under Article 5 (1) is not mentioned here, unlike the other two paragraphs from Article 5.
This portion of the decision by the CJEU would inevitably result in a certain shift in the balance between the parties to a software licensing agreement. Under these circumstances, it would be a sensible move for software vendors to introduce contractual conditions for potential error correction in their templates. This would at least guarantee that the licensee would have to comply with some formal requirements when decompiling for error correction. The aim of those requirements could be to reduce the risk of source code leaks or sharing with third parties which may turn out to be competitors of the software vendor. A potential mitigation would also be to require the licensee to always first contact the licensor for error correction and only if it does not succeed in remedying the situation, then the licensee to proceed with potential decompilation. Such a move would be logically reasonable since it is the software vendor who is best positioned to maintain the software.
Another useful step for both parties would be to introduce a clear definition of software “errors” in the contract. It would be in the interest of both licensors and licensees to avoid ambiguity in that area. A robust definition might reduce the risk of disputes between the parties and provide clarity at the outset for the applicability of the right to decompile for error correction. In particular, defects that do not prevent the use of the software in accordance with its intended purpose shall not give rise to the decompilation right.
You must be logged in to post a comment.