Section 52 (1) (ab) of the Indian Copyright Act provides what is commonly referred to as the “decompilation” defence and exempts from infringement:
How effective is this “decompilation” defence under Indian copyright law? I ask because in one of my competition law classes a couple of days back, I spoke about the Sun vs Microsoft antitrust case in the EU. Sun alleged MS was leveraging its dominance in the market for PC OS (operating system) software to corner the server market as well—and since it was attempting to exclude competition on the server market by not making available interface information, the EC Commission found in favour of an antitrust abuse. And this was upheld by the CFI as well.
The hypothetical question that arose in this context was: could Sun have decomplied the MS OS and found this interface information to make its server software? One student who is quite conversant with IT and technology was quite categorical that you can never really learn much by “decompilation”–and that it was, in effect, a redundant defence under the copyright act? Is this true?
Given various Sega cases in the US, I’m a little hesitant in concluding that the decompilation defece is redundant. Yes, decompilation and finding the source code and/or interface information may be difficult (and impossible in all cases), but surely it must be possible in some cases?
Any techies or folks familiar with this issue who can throw some light on this issue?
If the interface for a software or the specifications for a protocol is not available, then it is definitely hard to make interoperable software.
Decompilation is definitely very useful if the task is narrow. For example, if you have to remove DRM checks or to understand some packers or to remove some checks, then you can decompile using a tool like IDA Pro.
However, making full fledged interoperable complex binary protocol by decompiling is definitely very hard.
Thanks very much Sushant,
Certainly a much more nuanced response than what I given to understand by my student. I note that you use the term “very hard” and not “impossible”. And I assume that as with all things technological, the difficulty would ease up over a period of time. Therefore, I take it that it is wrong to categorise the decompilation defence as redundant.
Dear Shamnad,
There are two statements there:
1) You can never really learn much by decompilation.
2) It is, in effect, a redundant defence.
While the first might be true to a certain extent (as you yourself note), the second is most definitely not so.
1) While decompilation to produce the original code is extremely difficult (due to the complexity of software code), decompilation can often provide a functionally equivalent code, especially in the hands of a good coder. Even if that isn’t so, it provides a useful clues to reverse engineering. (For the link between decompilation and reverse engineering, see this page. That website provides excellent information on decompilation).
2) Assuming the non-existence of anti-circumvention provisions, decompilation provisions are most definitely useful in Copyright law. It is what allows for a large chunk of interoperability. For instance, the specifications for Microsoft Office’s .doc, .ppt, .xls formats were not available openly (they are partially available since 2008). If the EULA were to prevail over the exception in the Indian Copyright Act, then any program that seeks to read or write .doc files without seeking permission from Microsoft would be in trouble in India.
Even Google Chrome developers seem to have reverse-engineered Windows.
Most DRM systems are proprietary, so they can’t be implemented as FLOSS software. Hence reverse engineered software like DeCSS (allowing DVDs to be played in GNU/Linux systems) and PlayFair (allowing Apple’s FairPlay-encoded songs to be played on GNU/Linux systems) are very much required for interoperability.
Decompilation can thus provide useful information. It is not redundant. Of course, it would be much better if the coder made the program available with the source code under a F/OSS licence.
– Pranesh
A couple of quick notes:
1. Reverse engineering is usually done by running the software (these days under a virtualized environment like VMware or XEN). Decompilation gives you higher level structure to understand what the code is doing.
2. Shamnad points out that over time decompilation will become perfect. But the problem is that it is not a one side game. The software can be obfuscated too using packers and encryptors that make decompilation hard. These techniques are already used by malware authors and I am sure by a number of legitimate software to make reverse engineering hard.
Off course if there is enough desire and time to do it, it will happen.
There is no law for making source code or the specs of a protocol or a format available. The only reason one has to make it available is because of anti-trust charges.
The question that stays in my hand is does the “possibility” of interoperability sufficient against anti-trust charges. Or it has to be better than that.
This is the first time I am looking at this issue. So I may be wrong.
Section 2(i) in The Monopolies And Restrictive Trade Practices Act, 1969 says
(i) ” monopolistic trade practice” means a trade practice which has, or is likely to have, the effect of,-
(i) 1[ maintaining the prices of goods or charges for the services] at an unreasonable level by limiting, reducing or otherwise controlling the production, supply or distribution of goods 2[ or the supply of any services or in any other manner,
(ii) unreasonably preventing or lessening competition in the production, supply or distribution of any goods or in the supply of any services,
(iii) limiting technical development or capital invest- ment to the common detriment or allowing the quality of any goods produced, supplied or distributed, or any service rendered, in India to deteriorate;
(iv) 3[ increasing unreasonably,– (a) the cost of production of any goods; or
(b) charges for the provision, or maintenance, of any services;
(v) increasing unreasonably,– (a) the prices at which goods are, or may be, sold or re- sold, or the charges at which the services are, or may be, provided; or
(b) the profits which are, or may be, derived by the production, supply or distribution (including the sale or purchase) of any goods or by the provision of any services;
(vi) preventing or lessening competition in the production, supply or distribution of any goods or in the provision or maintenance of any services by the adoption of unfair methods or unfair or deceptive practices;”]
So the bar for making specs available is in Section 2(i)(ii)
“unreasonably preventing or lessening competition in the production, supply or distribution of any goods or in the supply of any services,”
And I do not know how to interpret “unreasonably” in this issue. I would say hiding software interfaces or protocols are unreasonable. But my feeling do not matter much and it will depend on the court.
Another section here is
Section 2(o)
http://indiankanoon.org/doc/792962/
(o) ” restrictive trade practice” means a trade practice which has, or may have, the effect of preventing, distorting or restricting competition in any manner and in particular,-
(i) which tends to obstruct the flow of capital or resources into the stream of production, or
(ii) which tends to bring about manipulation of prices, or conditions of delivery or to affect the flow of supplies in the market relating to goods or services in such manner as to impose on the consumers unjustified costs or restrictions;
decompiling by definition means discovering the source code of a compiled software from an execuatable file (softwares use a compiler that compiles the source code to create the executable file). decompiler softwares are used to find out the source code, and definitely in some cases it is possible to find out the source code of a software. however, decompilers make only educated guesses from whatever data is available to it. as the maker of a software often would see decompilation as a future threat, he may take precautions against possible decompilation. they can do so by using various techniques, and they often resort to specialist softwares (for example, SourceGuard) that can hide the source code from decompilers. most of the effective softwares in this genre are available for a cost. Again, there are decompilers that can crack these softwares and find out the source code (for example, a software called SourceAgain can be used to counter SourceGuard). The point is, even if you know what method is being used to hide the source code, finding out the source code may prove difficult. the possibility of discovering the sourcecode will exponentially decrease if the technique used to hide the source code is unknown, and also if the source code is long. finding out bits of the source code may not be difficult at times, but finding out the entire source code of something like a OS or even a kernel would be much more difficult. i am not saying impossible only because i cant imagine how difficult (how difficult will also depends on how heavily the developer of the original software invests on hiding his source code).
a quick look at these webpages maybe useful:
http://www.javacoffeebreak.com/articles/decompilers_friend_or_foe.html
http://boomerang.sourceforge.net/