Journal of Law, Information and Science
|
|
Home
| Databases
| WorldLII
| Search
| Feedback
Journal of Law, Information and Science |
|
CRISTINA CIFUENTES[1] AND ANNE FITZGERALD[2]
The Final Report on Computer Software Protection submitted by the Copyright Law Review Committee to the Australian Government in April 1995, includes recommendations on Reverse Engineering, Decompilation and Disassembly of computer programs. This paper comments upon the relevance of these recommendations to the computer science community, and considers the recommendations in the light of the EU Directive on the Legal Protection of Computer Software and recent US cases.
The Copyright Law Review Committee ("CLRC") recently released its Final Report on Computer Software Protection ("Final Report").[3] The CLRC is a specialist advisory body which was first established in 1983 to inquire into and report to the government on specific copyright issues referred to it from time to time. The report on Computer Software Protection is the last of the reports produced by the CLRC in its original constitution, under the chairmanship of Mr Justice Sheppard of the Federal Court. A new, five-member CLRC, chaired by Mr Peter Banki, was appointed in January 1995, with a wide-ranging reference to review and simplify the Copyright Act 1968.
The question of copyright protection for computer programs was referred to the CLRC for inquiry in October 1988. The Committee's terms of reference were:
Whether the Copyright Act 1968, as amended by the Copyright Amendment Act 1984, adequately and appropriately protects computer programs in human and machine readable forms, works created by or with the assistance of computer programs and works stored in computer memory.[4]
The terms of reference were subsequently extended to include importation of computer programs[5]and published edition copyright in relation to works stored in electronic databases.[6]
The CLRC's Draft Report on Computer Software Protection[7] ("Draft Report") was released for public comment in June 1993.[8] Following consideration of the submissions received in response to the Draft Report, the Committee published its Final Report in April 1995. In the Final Report, the CLRC makes recommendations on an extensive range of issues,[9] including the appropriate form of protection of computer programs,[10] definitions of "computer program"[11] and "reproduction",[12] the exclusive rights of the copyright owner[13] and the scope of exceptions to those rights,[14] protection of computer-generated material[15] and audiovisual works[16] and circumvention of program locks.[17] After considering the comments on its draft recommendations, in the Final Report the CLRC was persuaded to change its recommendations on a number of important matters: the definition of "reproduction",[18] ownership[19] and parallel importation of computer programs.[20] In the Final Report, the CLRC also revised its recommendations relating to computer-generated materials,[21] published edition copyright,[22] exceptions to the copyright owner's exclusive rights and the overlap between the Copyright Act 1968 and the Circuit Layouts Act 1989.[23]
The Final Report has been welcomed as a comprehensive and well-reasoned document which sets out a blueprint for amending the Copyright Act to ensure that computer software is adequately protected in Australia.[24] At the time of writing, the government has not yet issued an official response to the report, but is expected to do so by early 1996.[25] However, one aspect of the Final Report which has attracted considerable debate are the Committee's recommendations concerning exceptions to the copyright owner's exclusive rights which would, in specified situations, permit reverse engineering involving decompilation.[26] The introduction of limited decompilation rights is opposed by major hardware and software companies including IBM, Microsoft, Novell, Aspect and Computer Power. On the other hand, another alliance of companies known as the Supporters of Interoperable Systems in Australia (SISA),[27] whose members support open systems and interoperability of software, are in favour of the proposed reforms.[28]
This article examines the CLRC's recommendations on reverse engineering. Part 2 looks at the Committee's recommendation on the appropriate form of intellectual property protection for computer programs and the rights of the owners of software copyright. Part 3 discusses the meaning of the concept "reverse engineering" in the computer science community. Part 4 describes the processes of decompilation and disassembly. Part 5 reviews the CLRC's recommendations relating to reverse engineering, focusing on the proposed rights of decompilation for interoperability and error correction. Part 6 provides the conclusions. The paper is followed by Appendix 1: computing terminology defined by the CLRC in the "Glossary of Terms"[29], and Appendix 2: a sample decompilation of a C program.
The CLRC recommended that computer programs should continue to be protected under the Copyright Act as "literary works".[30] The Copyright Act 1968 was amended in 1984 to expressly provide protection for computer programs. The Copyright Amendment Act 1984 amended the definitions of "literary work" and "adaptation" and inserted new definitions for "computer program" and "material form".[31] The CLRC recommended that the current definition of "computer program" should be substituted with:
A "computer program" is a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result.[32]
The Committee recommended that the owner of copyright in a computer program should have the same exclusive rights as are provided for in s.31 of the Copyright Act[33] in relation to literary works.[34] The owner of copyright in a computer program would enjoy the full bundle of rights set out in s.31, including the right to control the reproduction of the computer program[35] and the right to make an adaptation of the work.[36] In addition to the rights set out in s.31, the CLRC recommended that the owner of copyright in a computer program should have the right to control commercial rental of the program.[37] A rental right for computer programs is also required by the GATT Agreement on Trade-Related Intellectual Property Rights (TRIPS).[38] This recommendation has already been implemented by the Copyright (World Trade Organization Amendments) Act 1994 which has amended the Copyright Act to provide a commercial rental right for computer programs, to take effect from 1 January 1996.[39]
According to the CLRC, the copyright owner's exclusive right to reproduce the computer program is exercised each time the program is used, since use of a computer program normally involves its reproduction in the computer's random access memory (RAM).[40] The CLRC recommended that a definition of "reproduction" should be included in the Copyright Act to clarify its meaning in relation to computer programs in source code and object code. Given the close relationship between source code and object code versions of a program, a majority of the Committee recommended that a deeming provision should be included to the effect that, in relation to a computer program, a reproduction includes but is not limited to:
(a) an object code version of the program that has been derived from the program in source code by compilation; and
(b) a source code version of the program that has been derived from the program in object code by decompilation.[41]
As computer programs can be translated relatively easily from one language to another (in either source code or object code), the Committee recommended that copyright owners should have the right to control the adaptation of their computer programs. To the extent that such activity does not constitute reproduction, the Committee regarded the adaptation right as an important supplement to the reproduction right.[42]
The Committee said that no change was required to the existing definitions of "adaptation" and "material form".[43] Section 10(1) defines "adaptation" as:
(ba) in relation to a literary work being a computer program – a version of the work (whether or not in the language, code or notation in which the work was originally expressed) not being a reproduction of the work.
If the Copyright Act were to be amended by inserting a deeming provision relating to reproduction, the Committee noted that the scope of the definition of adaptation would be narrowed to cover only different source code versions of programs written in source code, ie translations other than compilations or decompilations.[44]
Section 10(1) states that "material form"
in relation to a work or an adaptation of a work, includes any form (whether visible or not) of storage from which the work or adaptation, or a substantial part of the work or adaptation, can be reproduced.
The Committee noted that the definition of "material form" in s.10(1) is an inclusive, not exhaustive, definition which should be construed as including forms of storage where a work or an adaptation of a work exists in a form which would not normally be regarded as material, such as electronic and magnetic forms of storage, but which are amenable to reproduction.[45]
In reaching the conclusion that copyright was the "appropriate"[46] or "optimum"[47] form of protection for software, the CLRC also considered other possible means of protection. In response to its Draft Report, the Committee had received a number of submissions advocating the adoption of a special, or sui generis, form of protection for computer software.[48] While the Committee had leant towards the introduction of a copyright-style sui generis protection in its Draft Report,[49] it now saw the possibility of a new form of protection as being foreclosed by the signing of the GATT Agreement on Trade-Related Intellectual Property Rights (TRIPS).[50] Article 10(1) of TRIPS[51] requires computer programs, whether in source code or object code, to be protected as literary works under the Berne Convention (1971).
The role of the patent system in providing protection for software was discussed only briefly in the Final Report.[52] The CLRC's limited coverage of the role of patents in protecting software appears to stem from the fact that the Committee regarded patenting as an alternative, rather than an adjunct, to copyright protection. From submissions received, the Committee found there to be "very little, if any, support" for patent protection[53] and concluded that it did not "regard as adequate, or support, the development of patent or patent-type protection."[54] The Committee noted "in passing" that patent protection is available for computer software "in some cases", referring to the recent Federal Court decisions in IBM Corporation v Commissioner of Patents[55] and CCOM v Jiejing Pty Ltd.[56] In these cases, the Federal Court abandoned the Freeman-Walter-Abele test developed by the US courts to determine the patentability of computer programs and adopted a broader test based on well-established principles laid down by the High Court in National Research Development Corp. v Commissioner of Patents.[57] From these decisions, it is now clear that most forms of computer software inventions will be patentable, provided they satisfy the other statutory criteria, and the number of software patents granted is likely to increase substantially.
By too readily dismissing the relevance of patent protection, the CLRC missed the opportunity of carrying out a detailed examination of the respective roles of the copyright and patent systems in relation to computer software. Computer programs are essentially functional in nature. They contain text (code) which is protectable by copyright as well as ideas and functional elements which may, if sufficiently novel and inventive, be protected by patent law. But the most valuable feature of a computer program may be its behaviour, protection of which does not fit the existing copyright or patent paradigms. As a consequence, there have been renewed calls recently in the United States for the introduction of a special regime for the protection of software to operate alongside patents and copyright.[58] While such proposals have attracted much interest,[59] they are not likely to be given effect in the near future. The immediate problem to be addressed by the courts and parliament in Australia is how best to provide protection for computer programs within the bounds of the existing copyright and patent systems.
The meaning of the term reverse engineering has changed during the last decade. Whereas reverse engineering was previously concerned with the recovery of information from object code programs, it now stands for a more general type of recovery, design recovery. Due to the confusion over terminology used in this area, a taxonomy of reverse engineering and design recovery was formulated by Chikofsky in 1990.[60] Reverse engineering was defined as:
[T]he process of analyzing a subject system to identify the system's components and their interrelationships, and create representations of the system in another form or at a higher level of abstraction.
As this definition of reverse engineering makes clear, the process can start at any level of abstraction, whether it is in object code, assembler code, source code or even design models. Further, it does not involve any changes to the system but only examination of the system. "Reverse engineering" is now used as a generic term to cover several different types of computer programs including disassemblers, decompilers,[61] language translators[62] and CASE programs.[63]
In a preface entitled "Glossary of Terms", the CLRC defines the technical terms which it uses throughout the Final Report.[64] Figure 1 graphically represents the processes of compilation, decompilation and disassembly, based on the CLRC's definitions provided in the Glossary.
Figure 1: Compilation, Decompilation and Disassembly, according to the CLRC's definitions.
Based on the new definition of "computer program" proposed by the CLRC[65] and the definitions of "Machine code" and "Object code" in the Glossary, high level language code may be defined as:
The class of computer languages which allow programmers to represent a set of instructions in human readable form based on the syntactic and semantic rules of a computer language. Examples of high level languages are C, Pascal, C++ and Fortran.
In place of the definition in the Glossary, assembler code may then be defined as:
The class of computer languages which represent machine code by mnemonic instructions, ie, names which represent each machine code instruction. Assembler code is human readable.
And source code may be defined as:
The class of computer programs expressed in human readable form by programmers, ie, high level language code and assembler code.
As machine code is dependent on the machine (computer) that understands it, object code and assembler code are also machine dependent. High level language code, on the other hand, is machine independent. Figure 2 sets out a graphical representation which more closely accords with current usage of the terms “compilation”, “decompiliation” and “disassembly” in the computer science community.
Figure 2: Compilation, Decompilation and Disassembly, according to accepted industry usage.
The process of compilation converts a program written in high level language code to an equivalent program in assembler code or object code. This process is performed by a program known as a compiler.[66] The assembly process converts a program written in assembler code to an equivalent program in object code; this process is performed by a program known as an assembler.[67]
The assembly process can be reversed (or worked back) by a process known as disassembly, which converts a program in object code to an equivalent program in assembler code. In the same way, the compilation process can be reversed by a process known as decompilation, which converts a program in object code or assembler code to an equivalent program in high level language code. The former process is performed by a program known as a disassembler and the latter process by a decompiler.
Disassembly is an intermediate step in decompilation performed where it is necessary to represent the machine instructions in the object code program in an intermediate language that resembles assembler code.[68] Contrary to the definition in the Glossary to the Final Report, disassembly should not be regarded as a special case of decompilation.[69] In theory, if a program is written in a high level language such as C and a compiler is used to generate an object code program then, using a decompiler it is possible to convert this object code program into a high level language code version of the program. Figure 3 provides a sample C program which computes the numbers of Fibonacci. The high level code generated by decompilation could be in a different language to the initial C language used in this example; for example, Pascal or any other high level language.
#include <stdio.h>
int main()
{ int i, numtimes, number;
unsigned value, fib();
printf("Input number of iterations: ");
scanf ("%d", &numtimes);
for (i = 1; i <= numtimes; i++)
{
printf ("Input number: ");
scanf ("%d", &number);
value = fib(number);
printf("fibonacci(%d) = %u\n", number,value);
}
exit(0);
}
unsigned fib(x)
/* compute fibonacci number recursively */
int x;
{
if (x > 2)
return (fib(x - 1) + fib(x - 2));
else
return (1);
}
Figure 3: Fibonacci Program Written in the C Language
It has been theoretically proven that the disassembly or decompilation of object code is only partially computable[70] because of its equivalence to the halting problem[71]. Therefore, these process can only be partially automated. As a result, while a disassembler or decompiler can be written, it will not be able to correctly detranslate the object code into either assembler or high level language code for all object code programs without human intervention.
One of the authors[72] has developed a decompiler for the Intel 80286 architecture and the DOS operating system.[73] This research has shown that:
• not all programs can be successfully decompiled;
• only programs that use simple data types (as opposed to compound data types) can be decompiled without external user intervention;
• the detranslation of instructions is difficult when indexed or indirect jumps or calls are performed; and
• there is no way to differentiate between code initially written by the user and code included by the linker during the compilation process in statically-linked environments such as DOS.
Decompiling a program is not a straightforward task and, for most of today's complex programs, external user intervention will be required in order to produce a final high level language version of the program. While we might be concerned only with the code initially written by the programmer, the object code will have other routines, such as library routines, included during the compilation process. It is hard to distinguish between user-written routines and library routines, unless other programs are developed for this particular purpose. As a group of leading legal and computer experts have recently commented,
in the current state of the art, decompilation is a painstaking and time-consuming process.[74]
The Committee recommended that reverse engineering which involves decompilation should be prohibited, except to the extent that it is required for interoperability and error correction.[75] This recommendation would prohibit the analysis of object code programs by techniques such as decompilation and disassembly, except for the purposes of creating an interoperable program or hardware device and correction of errors.
In considering the extent of reverse engineering which should be allowed under the Copyright Act, the CLRC set out a number of purposes for reverse engineering: creation of clones, interoperability, porting, error correction and understanding the techniques used by the program's creator.[76] While recognising that reverse engineering may be carried out for other purposes, the CLRC confined its discussion to the purposes listed. However, there are several other important reasons for undertaking object code analysis, such as:
(1) Debugging of object code for security reasons: In order to detect a virus or worm program in an object code program, manual or automated detection needs to be done. In 1989, the Internet Worm attack infected thousands of computers throughout the world. A team of researchers and programmers at Cornell University manually analysed and debugged the infected programs in order to determine how to counteract the infection.[77]
(2) Verification of compiler-generated object code: This is a crucial issue in safety-critical systems, where the compiler is not trusted to generate correct code, and therefore a process of analysing the generated object code and detranslating it back to source code is required. This process has been used by Nuclear Electric plc (UK) to verify the correct translation of PL/M-86 source code into PROM programs.[78]
(3) Binary translation for the purposes of software migration (ie, porting at the object code level): Binary translation is the conversion of an object code program for a particular platform to another object code program on another platform. A platform is a machine (computer) and operating system pair. The most successful binary translator developed so far was that developed by Digital Corporation to migrate object code from the Vax running Open VMS and from MIPS running Ultrix, to the then new Alpha computer.[79]
(4) Simulation of computer programs: Enabling the running of an object code program on another machine that simulates all instructions from the previous machine, using a software program.
(5) Emulation of computer programs: This is the same as simulation, but is done at the microcode (hardware) level instead of the software level.
(6) Software maintenance of obsolete code: This involves the translation of an object code program written in an obsolete high level language to a high level language currently in use, particularly when the source code has been lost or does not exist.
In reaching its conclusions, the CLRC accepted the arguments put to it by major US software and computer companies that permitting reverse engineering by decompilation would make it relatively easy for competitors to produce clone programs, free riding on the efforts of the creator of the original program. In particular, the CLRC seemed to place a fair amount of weight on a presentation to the Committee by IBM in November 1990 during which the disassembly of a "relatively small program" was demonstrated.[80] The Committee accepted IBM's assertion that there are computer programs available which can very rapidly decompile other programs, making it possible to produce clone programs relatively easily.[81] The Committee also accepted IBM's concerns that once a program is decompiled into a high level language, a competitor wanting to produce a clone can easily manipulate the code derived from decompilation so as to hide any visual similarity to the original program while retaining the same functionality.[82]
However, decompilation is not such a simple exercise as the CLRC was led to believe on the basis of IBM's demonstration. There are various means of producing a second program which is functionally indistinguishable[83] from the first and which can be used as a substitute for it. At present, decompilation is the most difficult way to produce a program with behavioural equivalence and, further, it is practicable for only small amounts of code.[84] There are still no decompilers available on the market and the few disassemblers that are available have severe limitations. Any reverse engineering technique which is used to detranslate an object code program will involve user interaction and a lot of work, time and effort. As discussed in Part 4 above, the process is incomputable in general which means that fully automated disassemblers and decompilers will never be available. Also, today's programs are very complex and include a variety of services provided by the operating system, eg, graphical routines. The translation of these services is not straightforward, since a particular service may not be available in the operating system of another machine. As stated by the group of legal and computer software experts who recently presented the Manifesto Concerning the Legal Protection of Computer Programs,[85] reverse engineering by decompilation or disassembly
is currently a largely manual and very tedious process involving considerable effort to learn anything of value about a program of more than modest size. Given today's technology, programmers generally cannot hope to use decompilation as a means to achieve behavioural equivalence with only trivial effort.
The Committee recommended that decompilation of a computer program should be allowed where it is necessary to achieve the interoperability[86] of an independently created computer program or hardware device with other programs or hardware devices provided:
(a) decompilation is performed by the owner of a lawfully acquired copy of the program or another person having a right to use the copy or on their behalf by a person authorised to do so; and
(b) the information necessary to achieve interoperability has not previously been readily available; and
(c) the acts are confined to those necessary to achieve interoperability.
This recommendation is subject to the following limitations:
(i) the decompilation should only be used to achieve interoperability; and
(ii) the information obtained should only be given to others when necessary for the interoperability of the independently created computer program or hardware device.[87]
In the Final Report, the CLRC revised its draft recommendations relating to decompilation for error correction, recommending that:
(a) the Copyright Act be amended to provide that decompilation for error correction should not be an infringement of copyright where an error free version of the program cannot be obtained within a reasonable time at a normal commercial price; and
(b) decompilation for error correction be allowed to ensure the correct operation of a program with another program(s) or hardware device(s) provided:
(i) decompilation is performed by the owner of a lawfully acquired copy of the program or another person having a right to use the copy or on their behalf by a person authorised to so;
(ii) a version of the computer program free of the error has not previously been made available;
(iii) the acts are confined to those necessary to correct the error; and
(iv) a version of the program free of the error is not available within a reasonable time at a normal commercial price.
The following limitations would also apply:
(i) the decompilation should only be used to achieve error correction; and
(ii) the information obtained should only be given to others for the purpose of correcting errors.[88]
Both of these recommendations make it clear that decompilation should be limited to those acts necessary to achieve interoperability or to correct the error, as the case may be. However, given the nature of object code, it will often be difficult to determine which particular pieces of the code are relevant to the interoperability issue or contain the error. For example, interoperability-related instructions may be dispersed through the program code, linked by "jump" commands telling the computer to skip to a different portion of the code. This means that the acts of decompilation or disassembly may have to be performed on the entire object code program before determining what code is required to be analysed.[89]
The CLRC's recommendations on decompilation for interoperability are clearly heavily influenced by the European Union's 1991 Directive on the Legal Protection of Computer Programs ("the Directive").[90] Article 6 of the Directive[91] provides that decompilation is permissible if it is essential to achieve interoperability of an independently-created program with other programs and is confined to those parts of the original program which are necessary to achieve interoperability. "Interoperability" is defined as "the ability to exchange information and mutually to use the information which has been exchanged."[92] Decompilation must be done by a licensee or by someone with a right to use a copy of the program and the information required by decompilation must not be otherwise readily available. The information obtained cannot be used or given to others for purposes other than achieving interoperability of the independently created program. Nor can it be used to develop another program which is substantially similar in expression to the original program or for any other infringing act. The Directive expressly states that the reverse engineering clause cannot be excluded by contract and that any attempt to do so will be void.[93]
The issue of the reverse engineering of interfaces is directly addressed in Article 1(2) of the Directive, which specifically excludes the ideas and principles in interface specifications from copyright protection. Article 1(2) provides:
Protection in accordance with this Directive shall apply to the expression in any form of a computer program. Ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright under this Directive. [emphasis added]
The EU member states have adopted different approaches in implementing Article 6. In some cases, the text of Article 6 is reproduced exactly or with few changes[94] while several countries make minor changes to the wording of Articles 6(1) and 6(2).[95] Several countries have excluded Article 6(3) altogether from their implementing legislation.[96]
It is unclear whether Article 6 permits decompilation for the purpose of creating a competing program which can be used as a substitute for the original program rather than merely attaching to it. Some commentators take the view that the Directive permits the creation of a competing program, provided it is not substantially similar in expression.[97] Support for interpreting the Directive to allow decompilation for the purposes of creating a substitute program is also found in the Commission's communication to Parliament, which states:
Decompilation is permitted by Article 6 to the extent necessary to ensure the interoperability of an independently created computer program. Such a program may connect to the program subject to decompilation. Alternatively it may compete with the decompiled program and in such cases will not normally connect to it ... [98]
The CLRC's recommendation on decompilation for interoperability closely resembles Article 6 of the Directive, with one notable difference. The CLRC's proposal does not contain any equivalent to paragraph 2(c) of Article 6 which expressly prohibits the use of information obtained through decompilation in the development, production or marketing of a program of substantially similar expression or for any other act which infringes copyright.[99]
At the time the Directive was adopted in 1991 the leading US case, Whelan Assocs, Inc. v Jaslow Dental Lab., Inc., ("Whelan v Jaslow"),[100] had established an expansive scope of copyright protection for computer software. The United States and a number of leading American computer companies, including IBM, DEC and Apple, opposed the legalisation of reverse engineering and lobbied vigorously against the Directive.[101] The provision in the Directive permitting decompilation of existing programs to achieve interoperability represented a compromise between those opposed to any decompilation and those favouring decompilation to obtain access to any elements not protected by copyright.[102]
The same debate is currently being conducted in Australia between the opponents and supporters of the CLRC's recommendations on reverse engineering. Amendment of the Copyright Act as proposed by the CLRC is being opposed by a number of large computer software and hardware companies.[103] On the other hand, it is argued that the CLRC's recommendations are too narrow and that if the permissible scope of decompilation is restricted to cases of interoperability and error correction, protection will be given to functional aspects of computer programs which should not be protected by copyright law. If the limited decompilation right proposed by the CLRC were to be implemented in legislation it would, arguably, put Australian programmers and software companies at a disadvantage when compared with their counterparts in the United States, where a broader right to decompile has been recognised by the courts.[104]
Those in favour of permitting decompilation point out that for most copyright literary works, the unprotected ideas, information, methods and techniques which they contain are available to anyone merely by reading the work. There is no need to reproduce the work to obtain access to those elements which are not protected by copyright. For computer programs, though, the unprotectable elements can only be revealed by decompilation which necessarily involves copying. However, following the amendments to the Copyright Act in 1984 to provide protection for computer programs, it is an infringement of copyright to decompile an object code version of a program into a source code, human-readable form in order to access the underlying ideas or functional elements. Unless decompilation is permitted, the effect of copyright law is thus to confer trade secret protection on functional processes and systems embodied in computer programs.[105]
In the United States, a series of important decisions since 1992 have seen the courts narrow the scope of copyright protection for computer software, retreating from the high-water mark of protection established in Whelan v Jaslow. The potential for copyright law to extend de facto monopoly protection to the unprotectable elements of computer programs has been recognised in two recent appeal decisions. The leading US cases on the rights of a user to reverse engineer or decompile a computer program are the 1992 decisions of the Ninth and Federal circuit courts of appeal in Sega Enterprises Ltd v Accolade, Inc., ("Sega")[106] and Atari Games Corp. v Nintendo of America, Inc., ("Atari").[107] In these cases, the courts held that decompilation is a fair use of the copyright in a computer program when it is done for a legitimate purpose, such as to gain access to functional information eg, information necessary to develop an interoperable program or hardware device.
At issue in Sega was whether a person who is neither the copyright owner nor a licensee is permitted to decompile a copyrighted computer program in order to understand the ideas and functional elements underlying it. Sega, a leader in the home video entertainment market, manufactured a video entertainment console – the Genesis – and video game cartridges. It licensed the rights to create games compatible with the Genesis console to independent developers of video game programs under agreements which required Sega to be the exclusive manufacturer of the games developed by the licensee. The information needed to achieve interoperability was withheld from the licensees and supplied by Sega during manufacture. Sega then resold the completed games to the licensee for commercial distribution.
Accolade was an independent developer, manufacturer and marketer of computer entertainment software and wanted to produce games compatible with the Genesis console. Unwilling to hand over the manufacturing process to Sega, Accolade decompiled object code in Sega's video game programs into source code to discover the interface specifications for the Genesis console. In the process, Accolade's engineers made numerous copies of Sega's microcode. Information obtained about the requirements for a Genesis-compatible game was included in a development manual written by Accolade employees. The manual contained functional descriptions of the interface specifications but did not include any of Sega's code. Based on the information in the development manual, Accolade then produced its own programs for use with the Genesis console.
In response to Sega's claim that Accolade had infringed its exclusive rights by decompiling its copyrighted computer programs, Accolade argued that decompilation in order to understand ideas and functional concepts was a fair use permitted by s.107 of the US Copyright Act.[108] The Ninth Circuit conducted a detailed analysis of each of the four fair use factors in s.107, finding that the first, second and fourth weighed in favour of Accolade and the third favoured Sega, but "only slightly."
Looking at the first statutory factor,[109] the court held that Accolade's purpose in using Sega's code was "legitimate and essentially non-exploitative" and that the commercial aspect of its use was indirect and of minimal significance. Although Accolade's ultimate purpose of producing Genesis-compatible games was commercial, its intermediate purpose in using the copyrighted material was to discover the functional requirements for compatibility. Further, by identifying the functional elements required for compatibility with the Genesis console, Accolade produced a benefit for the public by increasing the number of video games available for use with Sega's machine.
The fact that the work in question was a computer program was relevant to the second statutory factor - "the nature of the copyrighted work" - as different copyright works attract varying levels of protection. The Ninth Circuit characterised computer programs as essentially utilitarian, containing "many logical, structural and display elements" which are required by the "function to be performed, by considerations of efficiency, or by external factors such as compatibility requirements and industry demands." In computer programs these unprotected ideas and functional elements contained in object code are not readily accessible to the human eye and can only be accessed by decompilation. The only means by which Accolade could gain an understanding of the functional requirements for compatibility was by decompilation. As Sega's video game programs contained unprotected aspects that could not be examined without copying, they were afforded a lower degree of protection than traditional literary works.
The only statutory factor which the court found to weigh even slightly in Sega's favour was "the amount and substantiality of the portion used in relation to the copyrighted work as a whole." Even though Accolade had made intermediate copies of entire Sega programs, the fact that the game cartridges which it produced contained only the interface portion of the code meant that this factor carried very little weight.
The court also found in favour of Accolade on the question of the effect of the use upon the potential market for or value of the copyrighted work. Accolade's decompilation had an indirect effect on the market for Genesis-compatible games in that it enabled Accolade to gain entry into the market without a licence from Sega. However, the nature of the video games market is such that users typically purchase multiple games. There was no basis for finding that Accolade's use had significantly affected the market for Sega's games, since consumers might well choose to purchase cartridges produced by both Sega and Accolade.
The Ninth Circuit concluded that while Accolade's intermediate copying of the object code was a prima facie infringement of Sega's exclusive rights, it came within the fair use exception. The unprotected aspects of Sega's programs could only be accessed by decompilation and Accolade had a legitimate interest in gaining access to them to ascertain how to make Genesis-compatible game cartridges. A key issue for the Ninth Circuit was the policy underlying the Copyright Act of encouraging the creation of original works by protecting expression but leaving ideas and functional elements in the public domain. Unlike other copyright works, computer programs are distributed to the public in object code form and there is no way of discerning those unprotected ideas and functional concepts apart from decompilation. The court was adamant that the owner of copyright in a computer program should not be able to obtain a de facto monopoly over the ideas and functional elements, thereby precluding public access and defeating the fundamental purpose of the Copyright Act. The court held that
where disassembly is the only way to gain access to the ideas and functional elements embodied in a copyrighted computer program and where there is a legitimate reason for seeking such access, disassembly is a fair use of the copyrighted work, as a matter of law.[110]
Using similar reasoning, the Federal Circuit in Atari Games Corp. v Nintendo of America, Inc.,[111] ("Atari") also concluded that "reverse engineering object code to discern the unprotectable ideas in a computer program is a fair use." Fair use, however, does not give the decompiler the right to go beyond what is necessary to obtain an understanding of the ideas and processes in the copyrighted work and to substantially reproduce the protected expression of the original program. The Federal Circuit commented that
Fair use to discern a work's ideas, however, does not justify extensive efforts to profit from replicating protected expression. ... [F]air use in intermediate copying does not extend to commercial exploitation of protected expression. The fair use reproductions of a computer program must not exceed what is necessary to understand the unprotected elements of the work ...[112]
The decision in Sega is widely accepted by most US commentators as correctly resolving the question of the reverse engineering of computer programs.[113] The approach of the Ninth and Federal circuits regarding decompilation is similar to that adopted in the EU Directive. However, the fair use analyses in Sega and Atari would apparently permit decompilation in a broader range of cases than would be approved under the EU Directive. Both the Directive and the fair use exception limit the right to decompile to situations where the information in the object code cannot be discerned in any other way. Further, the information obtained from decompilation cannot be used to substantially reproduce the expression of the original program but can only be used to create an independently authored program.
The main point of difference is the Directive's focus on interoperability. Article 6 limits decompilation to the parts of the original program which are required for interoperability and permits use of the information obtained only for the purpose of achieving interoperability of an independently created program. For this reason, most US commentators regard the Directive as establishing a distinctly narrower scope for permissible decompilation than the US fair use cases. Anthony Clapes describes the decompilation right accorded by Article 6 as "heavily circumscribed, [and] far more limited than the "fair use" privilege granted in Sega and [Atari]."[114] Likewise, Professors Huet and Ginsburg comment that:
the Federal and Ninth Circuits' approaches to decompilation appear more generous than the Directive's for they are not limited to acquisition and exploitation of information regarding program interfaces. Even though ... that limitation in the Directive does not seem to restrict much decompilation, it does confine that use to which the second-comer may put her knowledge of the source code. Under the Directive, the decompiler may not exploit information unrelated to "interoperability" between programs. By contrast, the Federal Circuit's analysis [in Atari] would permit the reverse engineer to use information pertaining to a variety of program elements that do not necessarily communicate with other programs. The Ninth Circuit [in Sega], staking a middle ground, did not explicitly limit the scope of its fair use analysis to the context of hardware/software compatibility, but emphasised that "[t]he need to disassemble object code arises, if at all, only in connection with operations systems, system interface procedures, and other programs that are not visible to the user when operating – and then only when no alternative means of gaining an understanding of those ideas and functional concepts exists." [115]
In the Final Report, the CLRC referred to Sega as relevant, not to the interpretation of the "fair dealing" provisions of s.40 of the Copyright Act, but as providing guidance as to how Australian law might be amended to deal with reverse engineering of software. The Committee cited Sega as authority for the broad principle that:
reverse engineering, including the decompilation of a program to determine its unprotected ideas and functional concepts [is] permissible as a "fair use" under s.107 of the US Copyright Act 1976.[116]
The Committee had considered whether the fair dealing exception in s.40 of the Copyright Act could be relied upon, as had the fair use defence in the US Copyright Act, to justify permissible reverse engineering.[117] After comparing the two, the Committee found the fair dealing provisions in s.40 to be much more limited in scope than the fair use provisions under US law.[118] In particular, as the courts would be likely to give the fair dealing exception for purposes of "research or study" a narrow interpretation, the CLRC concluded that s.40 was not a satisfactory vehicle for "marking out the extent of permissible reverse engineering."[119]
The Committee's preferred alternative was the enactment of specific provisions which would indicate the exact scope of permitted reverse engineering.[120] The CLRC's solution of prohibiting reverse engineering involving decompilation except for specified permitted purposes, is similar to the approach adopted in the EU Directive. Unfortunately, the CLRC did not go further and compare the effect of the limited decompilation exceptions which it recommended with the extent of decompilation permitted as a fair use under US law following Sega and Atari. As has been mentioned, a number of leading American commentators regard the decompilation rights under the EU Directive to be much more limited than the US fair use exception. The effect of the CLRC's recommendations on reverse engineering should be further investigated to ensure that they confer a level of protection commensurate with that available in the US post Sega and Atari.
The Committee recommended that decompilation to understand techniques should be governed by the fair dealing provisions of the Copyright Act, adding the qualification that the fair dealing provisions should only apply in respect of "non-commercial" activities.[121] Section 40(1) of the Copyright Act provides that:
A fair dealing with a literary ... work, or with an adaptation of a work, for the purposes of research or study does not constitute an infringement of the copyright in the work.
The CLRC relied upon the opinion of the Attorney-General's Department[122] that the meaning of "research or study" is to be narrowly construed. It is likely that the courts would interpret "study" as confined to study by individuals for their own purposes while "research" could be confined to research activities carried out in universities and by the CSIRO, with the aim of increasing knowledge in the community as a whole.[123] Combined with the additional requirement that the activities be non-commercial, any reverse engineering carried out by commercial software producers would fall outside the scope of the fair dealing provisions of the Copyright Act.
The use of the term "non-commercial" in this context is likely to cause uncertainty. Decompilation to understand ideas or techniques by university researchers may be regarded as non-commercial "study" or "research" which amounts to a fair dealing under s.40. However, the usefulness of the commercial/non-commercial distinction becomes increasingly questionable and difficult to apply as universities enter into research joint ventures or license their research results to commercial organisations.
As noted above, the CLRC considered that the reproduction of a computer program in the computer's RAM during normal operation may amount to an exercise of the copyright owner's exclusive reproduction right. In the absence of an express or implied licence from the copyright owner such reproduction of the computer program in RAM incidental to its normal use, could arguably constitute an infringement of copyright.[124] The Committee therefore recommended that the Copyright Act should be amended to provide that copyright in a computer program is not infringed by a person who copies that program where the making of that copy is reasonable or necessary for the normal use of the program.[125] The Committee did not see any need to define the words “reasonable” and “necessary” or the term “normal use”.
The Committee recommended that modifications of computer programs for the purposes of enhanced performance or porting[126] remain a matter of negotiation between the purchaser of the program and the copyright owner of the program.[127] The CLRC did not make any comments on what procedures should be available to a user when the copyright owner of a program does not want or is not able to create an enhanced version of or to port the program (either due to time or money constraints). There is also the possibility that the copyright owner has gone out of business, in which case there may not be anyone for the user to negotiate with.
With the advent of newer and faster machines, the computer industry is in need of software tools that aid in the porting of applications from one computer to another. These tools will require analysis of object code programs in order to translate them to another computer configuration. This translation can be done in two different ways: statically or dynamically. In the case of static translation, the binary translator program creates a new object code program for the new machine. This new file would constitute an adaptation of the original object code program and would fall within the copyright owner's exclusive rights. In the case of dynamic translation, the binary translator performs the translation "on the run" by interpretation of the object code program on the new machine. No new object code program is made, although the object code is reproduced in RAM in running the program. It is not clear whether running the program for this purpose can be regarded as copying which is reasonable or necessary for the normal use of the program and thus within the scope of the CLRC's recommended exception[128].
The CLRC recognised that computer programs are generally distributed in a form – object code – from which the underlying ideas and principles cannot readily be ascertained. Accordingly, some form of reverse engineering of the object code program will be necessary to determine the underlying ideas and principles.[129] In recommending that reverse engineering involving decompilation should be prohibited except where required for interoperability and error correction, the Committee accepted the concerns of the major software producers that to allow decompilation would enable competitors to clone their programs "with relative ease". Having decompiled the object code, competitors could relatively easily manipulate the code to hide any visual similarity to produce another program with the same functionality.[130] However, five years after IBM's demonstration[131] there are still no decompilers or disassemblers available in the market that will "very rapidly" decompile or disassemble an object code program to make "the task of cloning programs relatively easy"[132].
Unfortunately, the CLRC did not use the opportunity of reviewing copyright protection for computer software to carry out a more extensive examination of the appropriate scope of protection and the respective roles of the copyright and patent systems. Computer programs are essentially functional in nature. Copyright law is concerned with protecting the expression of ideas and plays a limited role in protecting function. In recent years, the US courts, recognising the functional nature of software, have retreated from the high-water mark of copyright protection which was established in Whelan v Jaslow.[133] Decisions such as Computer Associates v Altai, Sega v Accolade and Atari v Nintendo have established that copyright provides only "thin" protection for computer software. Accompanying this development has been a considerable expansion in the scope of patentability of computer software.[134]
In considering the CLRC's recommendations, the government should take note of these recent US developments which have limited copyright protection for the functional aspects of computer software. If the scope of copyright protection for software is too broad, only the current owners of interfaces will benefit, leaving small Australian software developers at a disadvantage in the global market.
A program written to perform a specific task for the user. It does not contribute to the effective functioning of the computer.
A type of programming language used to represent programs in machine code in a convenient and readable notation.
The process whereby a program written in a high level language is converted into equivalent instructions in machine code or object code.
The working back from the object code of a computer program to a version of the source code. This process may involve a substantial recreation or reproduction of the source code of the original program. Decompilation is achieved using a computer program called a decompiler.
The working back from object code to assembler code ie, a special case of decompilation. Disassembly is achieved using a computer program called a disassembler.
The description of the logical and physical interconnection and interaction which allows a hardware or computer program product to interact as intended with other hardware, computer program(s) or users.
The ability of computer systems to exchange information and mutually to use the information which has been exchanged.
The process whereby a source code program is translated "on the run" one instruction at a time into machine code or object code.
The class of computer languages which can be interpreted directly by computers (machines) without a translation process.
A very low level machine code used to write programs that define machine instructions to perform specific machine operational functions eg. moving or examining data.
The class of computer programs expressed in machine code which contain additional information necessary to ensure correct loading of the program.
Making the arrangements necessary so that a computer program that runs on one computer is able to run on a differently configured computer. This generally involves modification of the original program.
The study or analysis of a computer product (including a computer program) in order to reveal the underlying idea or principle on which it operates. This analysis may include an examination of relevant published documentation, study of the operation of the product and, in the case of computer programs, their decompilation. Studying the operation of a program would involve reproduction of the program in the same way as normal use.
The class of computer languages expressed in human readable form and which allow a human programmer to work with instructions rather than binary or hexadecimal numbers.
This section illustrates an example of the decompilation of a small C program, using the dcc decompiler developed by one of the authors. The sample program (see Figure 3) calculates the Fibonacci number of a given input number. Figure 4 illustrates part of the object code of this DOS program, expressed in hexadecimal notation. Figures 5 and 6 present the output of the disassembly process in assembler code. Figure 7 is the final C code generates by dcc. This C program can be compared with the original C program in Figure 3; the decompiled program is functionally equivalent to the original C program, although some differences are noticed. First of all, the recursive procedure proc_1() uses 2 local variables: one to copy a parameter, and another to hold the final result of the function. Second, there is no unsigned use of the identifiers in proc_1() to be able to know that the result is an unsigned integer rather than a signed integer. Finally, the main() procedure makes use of a while() loop rather than a for() loop; both constructs are functionally equivalent.
It is noted though that the similarities between the original (Figure 3) and the final (Figure 7) C code is due to the decompiler being able to determine library signatures for the printf() and scanf() functions. Without the matching of these functions, the final C code would have at least 10 more subroutines detailing the implementation of the printf() and scanf() functions, as implemented by the particular compiler used. In this case, this matching of library functions was possible due to the library signature module implemented in dcc; such module only matches library signatures for a limited number of compilers.
55 8B EC 83 EC 04 56 57 1E B8 94 00 50 9A
0E 00 3C 17 59 59 16 8D 46 FC 50 1E B8 B1 00 50
9A 07 00 F0 17 83 C4 08 BE 01 00 EB 3B 1E B8 B4
00 50 9A 0E 00 3C 17 59 59 16 8D 46 FE 50 1E B8
C3 00 50
9A 07 00 F0 17 83 C4 08 FF 76 FE 9A 7C
00 3B 16 59 8B F8 57 FF 76 FE 1E B8 C6 00 50 9A
0E 00 3C 17 83 C4 08 46 3B 76 FC 7E C0 33 C0 50
9A 0A 00 49 16 59 5F 5E 8B E5 5D CB 55 8B EC 56
8B 76 06 83 FE 02 7E 1E 8B C6 48 50 0E E8 EC FF
59 50 8B C6 05 FE FF 50 0E E8 E0 FF 59 8B D0 58
03 C2 EB 07 EB
05 B8 01 00 EB 00 5E 5D CB
Figure 4 – Machine Code (hexadecimal format)
proc_1 PROC FAR
000 00053C 55 PUSH bp
001 00053D 8BEC MOV bp, sp
002 00053F 56
PUSH si
003 000540 8B7606 MOV si, [bp+6]
004 000543 83FE02 CMP si, 2
005
000546 7E1E JLE L1
006 000548 8BC6 MOV ax, si
007 00054A 48 DEC ax
008 00054B 50 PUSH ax
009 00054C 0E PUSH cs
010 00054D E8ECFF CALL near ptr
proc_1
011 000550 59 POP cx
012 000551 50 PUSH ax
013 000552 8BC6 MOV
ax, si
014 000554 05FEFF ADD ax, 0FFFEh
015 000557 50 PUSH ax
016 000558 0E
PUSH cs
017 000559 E8E0FF CALL near ptr proc_1
018 00055C 59 POP cx
019 00055D
8BD0 MOV dx, ax
020 00055F 58 POP ax
021 000560 03C2 ADD ax, dx
023 00056B 5E L2: POP si
024 00056C 5D POP bp
025 00056D CB RETF
026 000566
B80100 L1: MOV ax, 1
027 000569 EB00 JMP L2
proc_1 ENDP
main PROC FAR
000 0004C2 55
PUSH bp
001 0004C3 8BEC MOV bp, sp
002 0004C5 83EC04 SUB sp, 4
003 0004C8
56 PUSH si
004 0004C9 57 PUSH di
005 0004CA 1E PUSH ds
006 0004CB
B89400 MOV ax, 94h
007 0004CE 50 PUSH ax
008 0004CF 9A0E004D01 CALL far ptr printf
009 0004D4 59 POP cx
010 0004D5 59 POP cx
011 0004D6 16 PUSH
ss
012 0004D7 8D46FC LEA ax, [bp-4]
013 0004DA 50 PUSH ax
014 0004DB 1E PUSH
ds
Figure 5 – Assembler Code
015 0004DC B8B100 MOV ax, 0B1h
016 0004DF 50 PUSH ax
017 0004E0 9A07000102 CALL far
ptr scanf
018 0004E5 83C408 ADD sp, 8
019 0004E8 BE0100 MOV si, 1
021 000528 3B76FC L3:
CMP si, [bp-4]
022 00052B 7EC0 JLE L4
023 00052D 33C0 XOR ax, ax
024 00052F
50 PUSH ax
025 000530 9A0A005A00 CALL far ptr exit
026 000535 59 POP cx
027 000536
5F POP di
028 000537 5E POP si
029 000538 8BE5 MOV sp, bp
030
00053A 5D POP bp
031 00053B CB RETF
032 0004ED 1E L4: PUSH ds
033 0004EE B8B400
MOV ax, 0B4h
034 0004F1 50 PUSH ax
035 0004F2 9A0E004D01 CALL far ptr printf
036 0004F7
59 POP cx
037 0004F8 59 POP cx
038 0004F9 16 PUSH ss
039 0004FA
8D46FE LEA ax, [bp-2]
040 0004FD 50 PUSH ax
041 0004FE 1E PUSH ds
042 0004FF B8C300 MOV ax, 0C3h
043 000502 50 PUSH ax
044 000503 9A07000102 CALL far
ptr scanf
045 000508 83C408 ADD sp, 8
046 00050B FF76FE PUSH word ptr [bp-2]
047 00050E 9A7C004C00
CALL far ptr proc_1
048 000513 59 POP cx
049 000514 8BF8 MOV di, ax
050 000516 57
PUSH di
051 000517 FF76FE PUSH word ptr [bp-2]
052 00051A 1E PUSH ds
053 00051B
B8C600 MOV ax, 0C6h
054 00051E 50 PUSH ax
055 00051F 9A0E004D01 CALL far ptr printf
056 000524 83C408 ADD sp, 8
057 000527 46 INC si
058 JMP
L3
main ENDP
Figure 6 – Assembler Code (continued)
/* Input file : fibo.exe
* File type : EXE
*/
int proc_1 (int arg0)
/* Takes 2 bytes of parameters.
* High-level language
prologue code.
* C calling convention.
*/
{
int loc1;
int loc2; /* ax */
loc1 = arg0;
if (loc1 > 2) {
loc2
= (proc_1 ((loc1 - 1)) +
proc_1 ((loc1 + -2)));
}
else {
loc2 = 1;
}
return (loc2);
}
void main ()
/* Takes no parameters.
* High-level language prologue code.
*/
{
int loc1;
int loc2;
int loc3;
int loc4;
printf ("Input number of iterations: ");
scanf ("%d", &loc1);
loc3 = 1;
while ((loc3 <= loc1)) { printf ("Input number: "); scanf ("%d", &loc2); loc4 = proc_1 (loc2); printf ("fibonacci(%d) = %u\n", loc2, loc4); loc3 = (loc3 + 1); } /* end of while */ exit (0); }
Figure 7 – Final C Program
[1] BComp(Hons)(QUT), Ph.D(QUT) Lecturer, Department of Computer Science, University of Tasmania (c.n.cifuentes@cs.utas.edu.au)
[2] LL.B.(Hons)(Tas.), LL.M.(Lond.), LL.M.(Columbia)
Lecturer, Law School, University of Tasmania (anne.fitzgerald@law.utas.edu.au)
[3] Copyright Law Review Committee, Computer Software Protection, Office of Legal Information and Publishing, Attorney-General's Department, Canberra, April 1995 (ISBN 0 642 20830 1)
[4] Final Report, paragraph 1.01
[5] 5 January 1989
[6] 18 January 1991
[7] Copyright Law Review, Draft Report on Computer Software Protection, June 1993 (ISBN 0 642 19361 4)
[8] For a series of papers discussing the Draft Report, see (1993) 4 Journal of Law and Information Science 201-291
[9] Final Report, Chapter 2. For a summary of the CLRC's recommendations, see: [1995] 7 European Intellectual Property D-193; [1995] 3 Computer and Telecommunications Law Review T-47
[10] Final Report, paragraph 2.03
[11] Final Report, paragraph 2.04(c)
[12] Final Report, paragraph 2.04(e)
[13] Final Report, paragraph 2.07
[14] Final Report, Chapter 10
[15] Final Report, paragraph 2.42
[16] Final Report, paragraph 2.63
[17] Final Report, paragraph 2.73
[18] Final Report, Chapter 6
[19] Final Report, Chapter 7
[20] Final Report, Chapter 11
[21] Final Report, Chapter 13
[22] Final Report, Chapter 15
[23] Final Report, Chapter 10
[24] Intellectual Property Society of Australia Seminar on the CLRC’s Final Report, Melbourne, 28 July 1995
[25] Minister for Justice, Duncan Kerr, The Government's Reform Agenda: Current Status and Future Plans, Copyright Law and Practice Symposium, Australian Copyright Council and Copyright Society of Australia, Sydney, 27 October 1995, at 12
[26] The CLRC received 18 submissions on the issue of reverse engineering, 14 of which favoured the incorporation of a reverse engineering exception. For a summary of the reasons for and against reverse engineering in the submissions received by the Committee, see Kent Davey, Reverse Engineering of Computer Programs, (1993) 4 Australian Intellectual Property Journal 59 at 88-91.
[27] SISA members include Fujitsu, Sun Microsystems, Amdahl and Storage Technology.
[28] John Hilvert, Industry giants at loggerheads over source-code access plan, The Australian 7 November 1995, at 21
[29] Final Report, pp.xxii-xxiv
[30] Final Report, paragraph 2.03
[31] Section 10(1) defines "literary work" as including "a computer program or a compilation of computer programs".
[32] Final Report, paragraph 2.04(c)
[33] In the case of a literary work, s31(1)(a) of the Copyright Act 1968 provides that the owner of copyright has the exclusive right to:
(a) reproduce the work in a material form;
(b) publish the work;
(c) perform the work in public;
(d) broadcast the work;
(e) cause the work to be transmitted to subscribers to a diffusion service;
(f) make an adaptation of the work; and
(g) do any of the acts (a) to (e) in relation to an adaptation of the work.
[34] Final Report, paragraph 2.07
[35] Final Report, paragraph 2.08
[36] Final Report, paragraph 2.11(a)
[37] Final Report, paragraphs 2.12 and 9.85
[38] Agreement on Trade-Related Aspects of Intellectual Property Rights, Including Trade in Counterfeit Goods, Dec. 15, 1993, (1994) 33 I.L.M. 83. Article 11 of TRIPS provides:
In respect of at least computer programs ... a member shall provide authors and their successors in title the right to authorise or to prohibit the commercial rental to the public of originals or copies of their copyright works. ... In respect of computer programs, this obligation does not apply to rentals where the program itself is not the essential object of the rental.
[39] Copyright Act 1968, ss.30A(2),(3),(4) and 31(3),(4),(5)
[40] Final Report, paragraph 10.07; and hence the need for an exception to permit copying for normal use (see Part 5 below).
[41] Final Report, paragraph 2.04(e)
[42] Final Report, paragraph 9.53
[43] Final Report, paragraph 2.04(f),(g)
[44] Final Report, paragraph 6.77
[45] Final Report, paragraph 6.87
[46] Final Report, paragraph 4.14
[47] Final Report, paragraph 4.13
[48] Final Report, paragraph 4.06. See Andrew Christie, Designing Appropriate Protection for Computer Programs [1994] 11 EIPR 486 and Andrew Christie, Re-writing the Rules on the Form of Protection for Computer Software (1993) 4 JLIS 224
[49] Draft Report, paragraph 4.25
[50] Final Report, paragraphs 4.06 and 4.14.
[51] Agreement on Trade-Related Aspects of Intellectual Property Rights, Including Trade in Counterfeit Goods, Dec. 15, 1993, (1994) 33 I.L.M. 83 at 87
[52] Final Report, paragraphs 4.07 - 4.09
[53] Final Report, paragraph 4.07
[54] Final Report, paragraph 4.08
[55] [1991] FCA 625; (1991) 22 IPR 417
[56] [1994] FCA 396; (1994) 28 IPR 481
[57] [1959] HCA 67; (1959) 102 CLR 252. See Anne Fitzgerald and Scott Phillips, Patentability of Software in Australia: CCOM v Jiejing (1994) 5 JLIS 296
[58] Pamela Samuelson, Randall Davis, Mitchell D Kapor, J H Reichman, A Manifesto Concerning the Legal Protection of Computer Programs, (1994) 94 Columbia Law Review 2308
[59] Symposium: Toward a Third Intellectual Property Paradigm, (1994) 94 Columbia Law Review 2307
[60] E J Chikofsky and J H Cross, Reverse Engineering and Design Recovery: a Taxonomy, IEEE Software, 7:13-17, January 1990
[61] Disassembly and decompilation are discussed at length in Part 4 of this article.
[62] A language translator is a computer program that takes as input a source code program, written in a high level language, and produces as output source code in a different high level language; eg, a computer program that translates Fortran programs to C programs.
[63] Computer-aided software engineering (CASE) programs aid in the generation of graphical representations of the system from source code or design models of the system, as well as generation of documentation based on existing models.
[64] See Appendix 1
[65] Final Report, paragraph 2.04(c)
[66] For example, the GNU cc compiler, a compiler for the high level language C, is able to generate assembler code with the -S option; otherwise it generates object code. See R M Stallman, Using and Porting GNU CC, version 2.5, October 1993
[67] For example, the GNU as assembler
[68] C Cifuentes and K J Gough, Decompilation of Binary Programs, Software – Practice and Experience, 25(7):811-829, July 1995
[69] In the "Glossary of Terms", the CLRC defined "disassembly" as:
The working back from object code to assembler code ie, a special case of decompilation. Disassembly is achieved using a computer program called a disassembler.
[70] R N Horspool and N Marovac, An Approach to the Problem of Detranslation of Computer Programs, The Computer Journal, 23(3):223-229, 1979
[71] For any machine, the halting problem is the problem of determining whether or not the machine will halt if placed in an initial state. For example, given any instruction in a program, whether object code or source code, it is not possible to determine whether that program will finish (ie, halt) or not.
[72] C Cifuentes
[73] C Cifuentes, Reverse Compilation Techniques, Ph.D dissertation, Queensland University of Technology, School of Computing Science, July 1994; C Cifuentes and K J Gough, Decompilation of Binary Programs, Software – Practice and Experience, 25(7):811-829, July 1995
[74] Pamela Samuelson, Randall Davis, Mitchell D Kapor, J H Reichman, A Manifesto Concerning the Legal Protection of Computer Programs, (1994) 94 Columbia Law Review 2307 at 2336 ("Manifesto")
[75] Final Report, paragraph 2.22
[76] Final Report, paragraph 10.37
[77] T Eisenberg et al., The Computer Worm: A Report to the Provost of Cornell University on an Investigation by the Commission of Preliminary Enquiry, Cornell University, Ithaca, USA, February 1989
[78] D J Pavey and L A Winsborrow, Demonstrating Equivalence of Source Code and PROM Contents, The Computer Language, 36(7):654-667, 1993
[79] R L Sites, A Chernoff, M B Kirk, M P Marks and S G Robinson, Binary Translation, Communications of the ACM, 36(2):69-81, February 1993
[80] Final Report, paragraph 10.38
[81] Final Report, paragraph 10.38
[82] Final Report, paragraph 10.25
[83] or has "behavioural equivalence"
[84] Manifesto, note 74 supra, at 2338
[85] Pamela Samuelson, Randall Davis, Mitchell D Kapor, J H Reichman, A Manifesto Concerning the Legal Protection of Computer Programs (1994) 94 Columbia Law Review 2308 at 2341
[86] "Interoperability" is defined as:
The ability of computer systems to exchange information and mutually to use the information which has been exchanged.
(Final Report, p.xxiii)
[87] Final Report, paragraph 2.23
[88] Final Report, paragraph 2.27
[89] For example, in Sega Enterprises Ltd v Accolade, Inc., [1993] USCA9 19; 977 F.2d 1510 (9th Cir. 1992) it was necessary for Accolade to copy the whole of Sega's game program in reverse engineering to ascertain the interface specifications. Without decompiling the entire program, Accolade would not have known whether it had all the information required to produce video games compatible with the Genesis console.
[90] Adopted 14 May 1991 Directive 91/250 OJ 1991 L122/42
The implementation date of the Directive was 1 January 1993. Only the United Kingdom, Denmark and Italy met that deadline, but all other EU member states have since finalised their implementing legislation.
[91] Article 6 - Decompilation
1. The authorization of the rightholder shall not be required where reproduction of the code and translation of its form within the meaning of Article 4(a) and (b) 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) these 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 authorized to do so;
(b) the information necessary to achieve interoperability has not previously been readily available to the persons referred to in subparagraph (a); and
(c) these acts are confined to the parts of the original program which are necessary 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 interoperability of the independently created computer program;
(b) to be given to others, except when necessary for the interoperability 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.
3. In accordance with the provisions of the Berne Convention for the protection of Literary and Artistic Works, the provisions of this Article may not be interpreted in such a way as to allow its application to be used in a manner which unreasonably prejudices the right holder's legitimate interests or conflicts with a normal exploitation of the computer program.
[92] Preamble, paragraph 12
[93] Article 9(1) of the Directive states 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."
[94] Ireland, Greece
[95] Belgium, France, Germany, Spain, Italy
[96] Denmark, Netherlands, UK
For discussion of the implementation of Article 6 see: Thomas C Vinje, Harmonising IP Laws in the European Union: Past, Present and Future, [1995] 8 EIPR 361 at 365
[97] T Dreier, The Council Directive of 14 May 1991 on the Legal Protection of Computer Programs [1991] European Intellectual Property Review 319 at 325
[98] Mark Powell, The Software Directive, Computer Law and Security Report, Special Supplement, June 1994, 2 at 6
[99] For comment on the possible effect of this omission, see Anthony L Clapes, Decompilation & European Protection of Computer Programs: A Review of Legal Protection of Computer Programs in Europe by Bridget Czarnota & Robert J Hart, (1994) 20 Rutgers Computer & Technology Law Journal 329 at 336
[100] [1986] USCA3 976; 797 F.2d 1222 (3d Cir. 1986), cert. denied, 479 U.S. 1031 (1987)
[101] Zentaro Kitagawa, Comment on "A Manifesto Concerning the Legal Protection of Computer Programs", (1994) 94 Columbia Law Review 2610 at 2616. According to Pamela Samuelson, the American trade negotiators and major US computer companies argued that under American law, decompilation would probably not be regarded as a fair use: Pamela Samuelson, Comparing U.S. and EC Copyright Protection for Computer Programs: Are They More Different Than They Seem? (1994) 13 J.L. & Com. 279 at 290-92. Anthony Clapes remarks that according to conventional wisdom, "during its gestation [the] Directive was the most heavily lobbied issue in the history of the European community." See Anthony L Clapes, Decompilation & European Protection of Computer Programs: A Review of Legal Protection of Computer Programs in Europe by Bridget Czarnota & Robert J Hart, (1994) 20 Rutgers Computer & Technology Law Journal 329
[102] Pamela Samuelson, Comparing U.S. and EC Copyright Protection for Computer Programs: Are They More Different Than They Seem? (1994)13 J.L. & Com. 279 at 290-92. Anthony Clapes comments that "[t]he EC Copyright Directive is ... a product of hard-fought compromise. ... [T]he Eurocrats fairly pleaded with the opposing industry camps to come up with a common proposal. It was only after that effort failed that the Commission took up in earnest the task of pushing its own decompilation draft through the political process." Anthony L Clapes, Decompilation & European Protection of Computer Programs: A Review of Legal Protection of Computer Programs in Europe by Bridget Czarnota & Robert J Hart, (1994) 20 Rutgers Computer & Technology Law Journal 329 at 337
[103] John Hilvert, Industry giants at logger-heads over source code access plan, The Australian, 7 November 1995, at 21
[104] Patrick Conrick, Nettle Slips through CLRC's Gloves, (1995) 8 Australian Intellectual Property Law Bulletin 49 at 51
[105] Id at 50
[106] [1993] USCA9 19; 977 F.2d 1510 (9th Cir.1992)
[107] [1992] USCAFED 794; 975 F.2d 832 (Fed. Cir. 1992)
[108] 17 U.S.C. s.106 provides that the owner of copyright has the exclusive rights, inter alia, to reproduce the copyrighted work in copies, to prepare derivative works based upon the copyrighted work and to authorise the preparation of copies and derivative works.
17 U.S.C. s.107 provides the fair use defence which allows copying "for purposes such as criticism, comment, news reporting, teaching ... scholarship, or research." Section 107 sets out four non-exclusive factors to be considered in determining whether a use made of a work is a fair use in any particular case:
(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes;
(2) the nature of the copyrighted work;
(3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and
(4) the effect of the use upon the potential market for or value of the copyrighted work.
[109] "the purpose and character of [the] use, including whether or not such a use is of a commercial nature or is for nonprofit educational purposes"
[110] [1993] USCA9 19; 977 F.2d 1510 at 1527-28
[111] [1992] USCAFED 794; 975 F.2d 832 (Fed. Cir. 1992)
[112] Id at 843
[113] See Peter S Menell, The Challenges of Reforming Intellectual Property Protection for Computer Software, (1994) 94 Columbia Law Review 2644 at 265; Pamela Samuelson, Randall Davis, Mitchell D Kapor, J H Reichman, A Manifesto Concerning the Legal Protection of Computer Programs, (1994) 94 Columbia Law Review 2307; In Sega, eleven copyright law professors submitted a brief amicus curiae in support of Accolade. See Brief Amicus Curiae of Eleven Copyright Law Professors in Sega Enterprises, Ltd v Accolade, Inc., (1992) 33 Jurimetrics J. 147; Dennis S Karjala, Copyright Protection of Computer Documents, Reverse Engineering and Professor Miller, (1994) 19 U. Dayton L. Rev. 975 at 993-94; Pamela Samuelson, Fair Use for Computer Programs and Other Copyrightable Works in Digital Form: The Implications of Sony, Galoob, and Sega, (1993) 1 J. Intell. Prop. L. 49 at 86-102; David A Rice, Sega and Beyond: A Beacon for Fair Use Analysis .. At Least As Far As It Goes, (1994) 19 U. Dayton L. Rev. 1131; Julie E Cohen, Reverse Engineering and the Rise of Electronic Vigilantism: Intellectual Property Implications of "Lock-Out" Programs, (1995) 68 S. Cal. L. Rev. 1091 at 1105. The decision in Sega has also attracted criticism. See Arthur Miller, Copyright Protection for Computer Programs, Databases, and Computer-Generated Works: Is Anything New Since CONTU?, (1993) 106 Harv. L. Rev. 977.
[114] Anthony L Clapes, Decompilation & European Protection of Computer Programs: A Review of Legal Protection of Computer Programs in Europe by Bridget Czarnota and Robert J Hart, (1994) 20 Rutgers Computer & Technology Law Journal 329 at 335. For a comparison of the EU Directive and the US law post-Sega/Atari, using a number of hypothetical situations, see John T Soma, Gus Winfield and Letty Friesen, Software Interoperability and Reverse Engineering (1994) 20 Rutgers Computer & Technology Law Journal 189 at 238-253
[115] Jerome Huet and Jane C. Ginsburg, Computer Programs in Europe: A Comparative Analysis of the 1991 EC Software Directive,(1992) 30 Colum. J. Transnat. L. 327 at 369-370
[116] Final Report, paragraph 10.28
[117] Final Report, paragraph 10.27.
Section 40(1) provides that:
A fair dealing with a literary ... work, or with an adaptation of a ... work, for the purposes of research or study does not constitute an infringement of the copyright in the work.
Section 40(2) provides that:
... the matters to which regard shall be had, in determining whether a dealing with a ... work or with an adaptation ... being a dealing by way of copying the whole or a part of the work or adaptation, constitutes a fair dealing ... for the purpose of research or study include:
(a) the purpose and character of the dealing;
(b) the nature of the work or adaptation;
(c) the possibility of obtaining the work or adaptation within a reasonable time at an ordinary commercial price;
(d) the effect of the dealing upon the potential market for, or value of, the work or adaptation ...
[118] Final Report, paragraph 10.28
[119] Final Report, paragraphs 10.29-10.31
[120] Gerald Dworkin, The Concept of Reverse Engineering in Intellectual Property Law and its Application to Computer Programs, (1990) 3 Australian Intellectual Property Journal 164 at 178
[121] Final Report, paragraphs 2.28 and 10.89
[122] An opinion was provided by Mr Denis Rose QC, Chief General Counsel of the Attorney-General's Department: Final Report, paragraph 10.29
[123] Final Report, paragraph 10.29
[124] Final Report, paragraph 10.07
[125] Final Report, paragraph 2.15
[126] "Porting" is defined as:
Making the arrangements necessary so that a computer program that runs on one computer is able to run on a differently configured computer. This generally involves modification of the original program.
(Final Report, p.xxiii)
[127] Final Report, paragraphs 2.24 and 2.26
[128] Final Report, paragraph 2.15
[129] Final Report, paragraph 10.24
[130] Final Report, paragraph 10.25
[131] Final Report, paragraph 10.38
[132] Final Report, paragraph 10.38
[133] [1986] USCA3 976; 797 F.2d 1222 (3d Cir. 1986), 479 U.S. 1031 (1986)
[134] For a discussion of US Software Patent Cases see: J. Swinson, Recent Software Patent Developments in the US (1994) 5 JLIS 281. Recent Australian cases on computer software patenting are: CCOM v Jiejing [1994] FCA 396; (1994) 28 IPR 481 and IBM v Commissioner of Patents [1991] FCA 625; (1992) 22 IPR 417
[135] Final Report, pp.xxii-xxiv
AustLII:
Copyright Policy
|
Disclaimers
|
Privacy Policy
|
Feedback
URL: http://www.austlii.edu.au/au/journals/JlLawInfoSci/1995/17.html