Reverse Engineering: When Can Users Lawfully Decompile Software?

Can a user of software who claims that it has faults, decompile it in order to correct the alleged errors? Or is the process of decompilation exclusively reserved for ascertaining interoperability of the software?

This question has been referred to the Court of Justice of the European Union by Belgium’s Court of Appeal. Here at Gerrish Legal, we have examined the current regime in relation to decompilation in Europe and the US. 

What is Decompilation?

Decompilation is a type of reverse engineering of software, namely, converting executable, computer-readable code (known as object code) into a human-readable code (thus recreating the source code through a higher-level programming language). This then allows for the code to be replicated, altered, or as some might say, be “tampered” with. 

In commercial software licence agreements, access to the source code in the eventuality of any defects or loss of operability can be a heavily negotiated part of the contract.

Whilst many service providers will want to protect their intellectual property and thus retain access to the source code as a default position, licensees are concerned with gaining access to the source code in the case where the service provider becomes insolvent or is no longer in business. In this case, licensees are left with software that does not function, and no means of rectifying the defects, without having to resort to reverse engineering. 

 The Dispute before the Court of Justice

The questions on interpretation of the EU articles on reverse engineering of source code and decompilation have been forwarded to the CJEU via the Article 267 TFEU mechanism on preliminary rulings. Article 267 TFEU gives the Court of Justice jurisdiction to deliver preliminary rulings on the validity and interpretation of EU law.

The Court of Justice will offer clarification on when decompilation can be carried out legally. The case in question comes from the Belgian Court of Appeal, involving a dispute between a software engineer and a State body. The software engineer discovered that the State had decompiled his code, confirmed by a judicial expert, and sent the decompiled sources to external clients. 

In its defence, the Belgian State entity pledges that the software had defects that needed to be fixed and thus, decompilation was necessary in order to address these flaws. The claimant not only disputes this on the ground that he was available if a defect needed to be fixed, but more fundamentally he argues that decompilation is only possible if the objective is to ensure interoperability, and not for the correction of defects. 

The European Stance so far

The EU has already tried to control the legal boundaries of reverse engineering through Directive 2009/24/EC on the legal protection of computer programs. Article 4 of the Directive sets out the exclusive rights of the author, including the rights to translation, adaptation, arrangement, any other transformation and reproduction of the program.  

Article 5 of the Directive provides exceptions to the exclusive rights above, talking of reverse engineering in general. Such rights are not subject to the authorisation of the author when these acts are necessary to enable the legitimate purchaser to use the computer program in a manner consistent with its intended purpose, including correcting errors.

There are a few conditions that must be satisfied here. Firstly, you must have acquired the program lawfully, i.e. through a licensing agreement and purchase. Secondly, the reverse engineering needs to occur whilst performing any acts that you are entitled to perform, such as loading, displaying, running, transmitting or storing the program. This phrase ensures appropriate limitation of the permitted acts. These appropriate limitations aren’t fully specified, but one limitation is decompilation as provided for in Article 6. Another possible limitation could derive from the wording of the licensing agreement itself. 

In response to general cases of reverse engineering, the Court of Justice has already ruled in a case referred by the UK (SAS Institute Inc. v World Programming Ltd) that copyright of a program cannot be infringed where the lawful acquirer of the licence merely studied, observed and/or tested the program in order to reproduce its functionality in a second program. Therefore, if your licensing agreement states that you aren’t allowed to reverse engineer a program, such a requirement is unenforceable according to EU law. However, the same does not apply to decompilation. 

More importantly for the Belgian case above, Article 6 of the Directive focuses on decompilation specifically and applies a blanket ban in the absence of express permission, except for the case where you need to achieve the interoperability of an independently created computer program. 

If such information is already available however, or if you are not the owner of a valid licence, then decompilation remains unlawful.

Therefore, such interoperability information should not be in the public domain if you want to decompile for this purpose. Many software engineers have been incentivised to document and disclose their products' interoperability as a result. 

It will be interesting to see how the Court of Justice responds to the case above – will they offer any further guidance on the gap between Article 5, which allows for reverse engineering if required for the proper functioning of software, and Article 6, which provides a stricter application of reverse engineering in cases of decompilation? One could argue that the EU law is clear on its stance and it would be unlikely that the CJEU would confirm that the interpretation of the Directive on decompilation is unclear or requires further guidance. 

The debate this produces is the right to correct errors whereby decompilation is the only option, versus the right to strictly limit the extremely intrusive operation of decompilation. 

So what is protected in practice?

This case shows the applicability of the “idea and expression dichotomy” concept. According to this concept, the aim of copyright laws is not to protect ideas, but the expressions of the ideas. 

The “idea” is protected through the “expression of the idea”, i.e. in the functionality of the source code. But only the source code is protected, not the idea itself. Indeed, as was stated in the SAS Institute Inc. v World Programming Ltd case:

…to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development…

Therefore, in line with this concept, low-level reverse engineering methods such as testing and observation are legal because they don’t threaten the work and intellectual property of software creators. Higher-level reverse engineering such as decompilation is illegal as it is a threat to the ideas and intellectual property of the software creators via recreating the source code, which is the protected element. However, decompilation for interoperability testing is legal and necessary to protect consumers and competition. 

Decompilation in the US

Similar to the EU, the US does allow for the decompilation of software for interoperability purposes (see: 17 U.S.C. § 1201 (2017) – Circumvention of Copyright Protection Systems - § 1201(f)(2)). But, the US exceptions can be said to be broader than the EU approach. 

Over the Atlantic, the copyright fair use principle has been successfully applied to cases of decompilation. In Sega Enterprises Ltd v Accolade, Inc (977 F.2d 1510 (9th Cir. 1992)) which created quite an uproar and is still a cause for concern for software manufacturers today, decompilation for the purposes of circumventing the software locking mechanism in Sega’s games consoles was lawfully permitted.

This stemmed from the reasoning that Accolade’s reverse engineering activity was for the purpose of accessing ideas (and not the expression of the idea) and such ideas are deemed unprotected by copyright law (even if such activity allows you to gain access to the source code, the means of expressing the idea). The fair use doctrine was applied, and this precedent continues to apply today, notably seen with the case of Sony Computer Entertainment, Inc v. Connectix Corporation (203 F.3d 596 (2000)) where the reverse engineering of the Playstation BIOS was deemed lawful under the fair use doctrine. Thus, in the US, the best way of lawfully protecting your software against decompilation, when it cannot be covered by copyright laws, is through patenting (where applicable) or trade secrets. 

Further exceptions to the prohibition of decompilation have been provided via the Digital Millenium Copyright Act for “lawfully authorized investigative, protective, information security, or intelligence activity” and through the contracts that you negotiate with licensors/licensees (see 17 U.S.C. § 1202 (2017) - Integrity of copyright management information - § 1202(d)).

What can you do to protect your interests in Europe?

The Article 6 prohibition set out in the Directive is said to be a reflection of the standard position in the software industry. This could be true as we have not seen much litigation arise from the decompilation right. However, this could also indicate that unlawful decompilation is either not conducted frequently or rather, goes largely undetected. 

  • As a user - If you have any doubts over whether you are allowed to decompile software as a user, it is best to be prudent and limit such activity to testing interoperability only.

  • As a software creator - ensure that any licensees are informed as to your and their rights in accessing the source code. Being readily available to fix any defects in the program and setting out well-defined SLAs and Customer Support commitments will avoid any scenarios whereby the licensee will try to gain access to the source code themselves via decompilation. Where possible, interoperability information should be made readily available to users.

If you have any questions in relation to licensing agreements, decompilation or protecting your source code, please do not hesitate to contact us

Article by Komal Shemar @ Gerrish Legal, February 2020 / Cover photo by Maxwell Nelson on Unsplash

Previous
Previous

Covid-19 & E-Commerce Contracts: A Force Majeure Event?

Next
Next

Client Case Study: Panion