Part I: Is decompilation of software legal under the Indian Copyright Act

In discussions with a few of my colleagues in software development related to mobile applications for Android, Windows, and iOS platforms, a question arose whether studying an existing application (already developed and available for a device) and using the existing application as a study tool is legal under the Indian Copyright Act?  At first glance the relevant provision (Section 52) under the Indian Copyright Act prescribes that studying software is legal.    

However, there are many practical issues that come up while analyzing the statute: As developers know, one cannot study software without first decompiling it.  Decompilation, ‘inter-operability’, are words that are not defined in the Act.  Decompilation may be equated to reverse engineering of a product – whether software or hardware.

This post analyzes Section 52 of the statute and in particular sub-sections 52(ab) and (ac), and find whether reverse engineering / decompilation of software applications is legal.  The answer to the question is not exactly clear – For Indian, maybe it is  - given  the way in which other jurisdictions have applied the similar statutes.  This post is divided into two parts.  Part I deals with the background information as relates to the development of decompilation / reverse engineering laws in US and Europe. Part II deals with the application of these laws to the Indian context.  Long post follows.

Because European law on copyright protection of computer programs is based on the counterpart American experience, American jurisprudence is discussed first.

REVERSE ENGINEERING IN US:

Under American law, until recently, there were no explicit provisions about decompilation or reverse engineering. The basic copyright law, that has been amended from time-to-time just provides fair use exceptions and courts are left free to interpret fair use.

In 2010, the Library of Congress with the US Register of Copyrights, provided six additional classes, that would not be considered infringement. See link.  Relevant to the issue of reverse engineering are the classes:

“..(2) Computer programs that enable wireless telephone handsets to execute software applications, where circumvention is accomplished for the sole purpose of enabling interoperability of such applications, when they have been lawfully obtained, with computer programs on the telephone handset.

...Emphasis added.

Case law sets out guidelines about reverse engineering.  And it was under the provisions of section 107 (fair use) that reverse engineering was addressed. 

The first case to be taken up by US Courts on the issue of reverse engineering was: Sega Enterprises Ltd. v. Accolade, Inc.: In Sega, Sega manufactured a video game console under a brand name Genesis.  The console contained a lock-out device (microchip) which looked for a particular code sequence in a game cartridge. This code sequence was provided only on Sega manufactured cartridges and no other.  Cartridges manufactured by other manufacturer did not have this code sequence, and could not function with the Sega console. 

Accolado, a game maker, also provided games on cartridges.  To be able to use a game cartridge from Accolado with the Genesis console, Accolade disassembled the Genesis console and found the chip containing the code reader, and found out the specific code sequence which Sega put in their cartridges.  This made it possible for Accolade to manufacture cartridges compatible with the Genesis console.  During the process of reverse engineering Accolado made several copies of Sega’s micro code and thereby infringing Sega’s copyright.

Sega suited for this infringement of their copyright to the specific microcode system and Accolado claimed fair use.  The District court in the Northern District of California found for Sega, that an infringement had taken place and it “could not be seen as a fair use because of the commercial nature of the reverse engineering.”  The Court of Appeal found otherwise and reversed the district court.  Decompilation was an infringement of Sega’s copyright but was found to be fair use. The court stated that if "disassembly provides the only means of access to those elements of the code not protected by copyright and the copier has a legitimate reason for seeking such access" is a fair use of the copyrighted work.

The court stated that reverse engineering is a fair use if the purpose is to achieve compatibility between an original (i.e. not copied from another) computer program, and a device for using this program.

The second case taken up by US Courts about reverse engineering also involved video game consoles, and was Atari Games corp. v. Nintendo of America, Inc.  In Atari, the consoles were manufactured by Nintendo.  However, Nintendo also had a patent on the security lock-out device. 

Atari had tried to reverse engineer the microchip but failed.  However, Atari obtained the information related to the microchip from the US Copyright Office (Library of Congress), claiming they needed this information in a litigation with Nintendo.

Atari thereafter created a program that emulated the Nintendo lock-out microchip, and this made it possible for Atari’s game cartridges to be used on Nintendo consoles.  The district court specifically ruled that Atari had, when creating the compatible program used more than necessary to get compatibility.

Nintendo filed for copyright and patent infringement and was successful at the district court − Atari’s claim for fair use was not accepted.  The Court of Appeal for the Federal Circuit (CAFC) came to the same conclusion and ruled, “reverse engineering was fair use only when the original product had been purchased legally.”  Getting the information from the US Copyright Office on false grounds destroyed any possibility for Atari to successfully claim fair use.  However, before these questions were tested the case was settled.

This case showed that copying a program to understand and copy unprotected underlying ideas would have been probably been alright if Atari had achieved information legally. 

In a third case, in Vault Corp. v. Quaid Software Ltd., the court decided that a Louisiana Software License Enforcement Act clause permitting a copyright holder to prohibit software decompilation or disassembly was preempted by the Copyright Act, and was therefore unenforceable.

REVERSE ENGINEERING IN Europe:

In EU copyright protection of computer programs is an outcome of computer program Directive.  See link.

The concept of reverse engineering was not unique to EU law. Before it, Art. 15 of the EC semiconductor chip protection Directive permitted reverse engineering of the layout of a semiconductor microchip.  This semiconductor related directive was similar to that of the US Semiconductor Chip Act of 1980 where provisions relating to decompilation were explicitly provided.

The computer programs Directive (hereafter Directive) contains two different provisions relating access to interface information. Article 5(3) deals with reverse analysis techniques other than decompilation, (also known as black box method).  Article 6 deals with decompilation methods themselves.  

Black Box Method (or passive monitoring method):

An engineer starting to develop a product with a particular standard may start work from published documentation about the interface information with that standard.  Usually because source code is not published, and available documentation is often incomplete or out dated, it is necessary to conduct reverse analysis to ascertain the interface information required to provide an interoperable product.

Generally, this information may be learned from "black box" reverse engineering  techniques. These techniques merely involve monitoring the activity of an existing product and are passive in nature – i.e. there is no active monitoring of do not involve translation of the analyzed program’s object code into the original source code.  Examples of information that may be obtained through black box techniques are test runs, line traces, storage data dumps and screen rendering.

Article 5(3) of the Directive provides

3. The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the right­holder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.  Emphasis added.

There are multiple aspects to this article in the Directive: First the person invoking the Article must have a right to use a copy of a computer program.  Hence this is the first hurdle that is passed by legitimate software licensees or owners (no pirates please).

Most developers who intend to develop interoperable products would be licensed users of the original product for which the new product is being developed.  As an example, consider various tools created by different third party developers for Adobe™ Photoshop™ software.   All such developers are usually licensed users for the Photoshop™ software.  Hence it is permissible for them to analyze a copy legitimately.

Second, Article 5(3) permits a developer to observe study or test the functioning of the program.  This is what a developer does when conducting black box analysis.

Third and most importantly, Article 5(3) permits the developer to determine the "ideas and principles" underlying any element of the computer program. This includes determining interface specifications which being the rules and methods by which a program interacts with other products, constitutes "ideas and principles".

Fourth, Article 5(3) permits the developer to observe, study and test the functioning of the program while "loading, displaying, running, transmitting or storing" the program.

Finally, Article 5(3) provides that for the analysis to be allowed, one must be "entitled to do" the underlying operation involved.  Accordingly, this is tied to the first part in the article, and is a second tier protection against use of this article illegitimately to expand permitted use of a program.

Decompilation:

In some cases techniques permitted by Article 5(3) do not yield enough interface information required. It then becomes necessary to decompile a program –i.e. active monitoring is required.  Article 6 of computer program Directive provides the required freedom for decompilation.

Article 6 of the Directive:

Decompilation

1. The authorisation of the rightholder shall not be required where reproduction of the code and translation of its form within the meaning of points (a) and (b) of Article 4(1) are indispensable to obtain the information necessary to achieve the interoperability of an independently created computer program with other programs, provided that the following conditions are met:

(a) those acts are performed by the licensee or by another person having a right to use a copy of a program, or on their behalf by a person authorised to do so;

(b) the information necessary to achieve interoperability has not previously been readily available to the persons referred to in point (a); and

(c) those acts are confined to the parts of the original program which are necessary in order to achieve interoperability.

2. The provisions of paragraph 1 shall not permit the information obtained through its application:

(a) to be used for goals other than to achieve the interoper­ability of the independently created computer program;

(b) to be given to others, except when necessary for the inter­operability of the independently created computer program; or

(c) to be used for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright.

From Article 6, it seems that decompilation of a program may not be done solely to research its underlying ideas unrelated to interoperability and then implement those ideas in a program that competes with the decompiled program.

The word indispensable has been used in Article 6.  This word suggests that it is not a mere wish but rather is required (grammatical construct: Air is required for breathing). 

In practice, because decompilation requires great sophistication, time and expense and will not be conducted lightly: accordingly if a developer decompiles software then the reasons for decompilation would play a great role, most probably in the developer’s favor.  This then becomes an economic standard for indispensability.  * Hence the usage of reports, and the initial pilot study to confirm data theft – are economically justified and decompilation is indispensable.

Under Article 6(a), the act of decompilation is done by a legitimate user.  Compare this provision to the Atari case discussed above – where Atari lost on both grounds and fair use exception under US law was not available to it.

Under Article 6(b), necessary interface information must not have been previously been readily available to the developer.  This provision should be interpreted according to the the economic hardship theory – i.e. economically justified and indispensable.

Under Article 6(c), decompilation must be confined to the parts of a program that are necessary to ensure interoperability.   This seems to be a grey area: it is not entirely clear how only a specific part of a program can be decompiled, leaving the rest untouched.  In software, either a program is decompiled or not – there are no mid-level choices available. In addition, software code is not written as a text book that has a page number to start and end with.  Software is written in parts – where one part may invoke another and vice-versa. 

Article 6, paragraph 2 limits the scope of Article 6 – and accordingly limits what may be done with the decompilation.  The limitation is with regard to interoperability : information gained through decompilation may be used only to achieve the interoperability of the independently created program.

Article 5(3) therefore, is very different from Article 6, and has no such restriction.

Article 6, paragraph (2)(c) provides that information obtained through decompilation may not be used for the development production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright. * Here it may be argued that an employee is restricted from decompiling a program created for his employer’s purpose, AND cannot use a decompiled program to create a competing program as that of his employer.