• services
  • Reverse Engineering


    This paper was presented at "Protecting & Exploiting Intellectual Property in Electronics", IBC Conferences, 10 June 1998


    Despite the popularity of the concept of reverse engineering with sections of the engineering community, the legislative position restricts reverse engineering of hardware and makes reverse engineering of software legal only under very limited circumstances in Europe. In the US, slightly more freedom is available to reverse engineers, but great care is still needed to avoid infringement.

    This article considers reverse engineering, and the controversial impact of intellectual property law on reverse engineering techniques, in Europe and elsewhere.

    Contents ]


    The first step, then, is to develop a mental picture of what reverse engineering is. To do this, it would be useful to start with a simplistic model of engineering itself.

    Engineering is the process of turning a specification into a product for performing to it.

    A full specification may not only specify what the product has to do, but also specify performance criteria it needs to meet along the way. As the complexity of IT systems grows, so does the importance of a good specification.

    In between the specification and the product is the engineering or implementation process, which involves some human creativity, and an increasing degree of automation.

    It is convenient to think in terms of "layers" or "levels" of abstraction. Thus:

    • A written functional specification for human consumption is a "top level" description;
    • An abstracted structural description (for example source code or circuit diagrams), for human consumption (but usually machine readable), is an "intermediate level" description;
    • A detailed structural description (e.g. assembler, or a node list) for machine consumption, but possibly comprehensible by humans, is a "low level" description; and
    • The product (a chip storing machine code, an integrated circuit or a circuit board), which is usually incomprehensible to human, constitutes the lowest level.

    Nowadays, in many processes the lower level descriptions are unnecessary and, if produced at all, are produced only for documentation purposes rather than during the design process.

    Often, the same specification can be implemented in many different ways, for example by using different target platforms (e.g. microprocessors) or different engineering tools and techniques (e.g. CMOS or NMOS). There is thus one to many relationship between a top level specification and products produced from it.

    Contents ]


    Reverse engineering, as the name implies, is the reverse of this; in other words, the attempt to recapture the top level specification by analysing the product - "attempt" because it is not possible in practice, or even in theory, to recover everything in the original specification purely by studying the product.

    Reverse engineering is difficult and time consuming, but it is getting easier all the time thanks to IT, for two reasons:

    • Firstly, as engineering techniques themselves become more computerised, more of the design is due to the computer. Thus, recognisable blocks of code, or groups of circuit elements on a substrate, often occur in many different designs produced by the same computer program. These are easier to recognise and interpret than a customised product would be.
    • Secondly, artificial intelligence techniques for pattern recognition, and for parsing and interpretation, have advanced to the point where these and other structures within a product can be recognised automatically.

    However, whilst it is often possible to automate the generation of a higher level structural description of a product, recognising what it is doing is difficult and still requires human skills, and it may simply not be possible to recapture some parts of original specification to which the product was made by studying the product.

    Since reverse engineering still needs human input, at some stage the reverse engineering process needs to produce a complete system description of the product, to allow a human to work out how the product functions; it is only after this human analysis that the product can be split into its component parts.

    Thus, reverse engineering generally consists of the following stages:

    1. Analysis of the product
    2. Generation of an intermediate level product description
    3. Human analysis of the product description to produce a specification
    4. Generation of a new product using the specification.

    There is thus a chain of events between the underlying design specification and any intermediate level design documents lying behind the product, through the product itself, through the reverse engineered product description, through the reverse engineered specification, and into the new product itself. This raises at least the risk of infringement of copyright or similar design or chip protection rights.

    If the same person both reverse engineers the old product and designs the new product, and there are similarities, it is hard to avoid an assumption that some copying has taken place, and so reverse engineering "best practice" involves breaking the chain, so far as possible, at the specification stage. The specification is made as abstract and functional as possible by the reverse engineers, and is then handed over to a "clean room" design team who have no other contact with the old product, or the team who analysed it, and who will then design the new product using as little low-level information as possible from the old product.

    Contents ]



    One group of reverse engineers are users of old products, who want to maintain them, but find that the original supplier may no longer exist, or may have dropped support for the product (1). Most users will want a subcontractor to re-engineer the software, rather than doing so themselves. To maintain an old product, it will often be necessary to understand how it works.

    Recently, the "Year 2000" problem has stimulated interest in maintaining old software. Reverse engineering may be needed if an old product is to work alongside, or within a new system. There is also a desire, amongst some software users, to re-engineer old software, to make it more modular, re-useable, accessible or reliable.


    Genuine competitors may wish to use reverse engineering techniques, for one of two reasons:

    • Firstly, they may wish to produce a product which operates with the product to be analysed (but does not compete with it), or
    • Secondly, they may wish to produce a product which competes with the product to be analysed.

    Examples of interoperable products are applications which need to interoperate with operating systems; software controlled exchanges which need to operate with others; and programs which are locked by hardware "dongles".


    Finally, pirates may occasionally use reverse engineering techniques. Pirates do not usually need to understand how a product works merely to copy it, but occasionally a product may include security features which the pirate needs to defeat.


    There are thus legitimate and illegitimate reasons for wanting to reverse engineer software products, chips, printed circuit boards and other hardware products, and firmware (i.e. mask-programmed or similar embedded software products).

    A genuine competitor will try to reduce their use of the intermediate description generated by reverse engineering to the absolute minimum necessary, to avoid copying, whereas a pirate will attempt to use the reverse engineered code to the maximum extent possible and add the minimum of independently created material, to make the product a "lookalike" in so far as possible, and to reduce the amount of effort they use.

    Contents ]



    Techniques now exist for visually scanning mechanical parts and generating CAD models from them, using machine vision technology; for example, the REFAB (Reverse Engineering - Feature Based) tool available from the Department of Computer Science of the University of Utah (2) and ARL's site. In REFAB, a laser digitiser is used to the scan the part, and the analysis software then analyses the shape of the part, using features which are based on typical machining operations, to generate a computerised manufacturing description which can be displayed, used to copy the product, or produce new products using the design.


    Computer vision has been widely used to scan PCBs for quality control and inspection purposes, and based on this, there are a number of machine vision for analysing and reverse engineering PCBs (3). Several firms on the Internet offer a service of scanning a PCB and supplying a corresponding netlist.


    This is much harder work, since everything is on a much smaller scale.

    The first step is to get through the encapsulating material into the product itself, by chemical etching or grinding. This can be tough in itself, since some manufacturers include hard particles such as carborundum or sapphire in the encapsulating the resin, so that mechanical grinding also destroys the chip.

    Once at the chip surface, each layer of components is photographed, then ground away to reveal the layer below. This process reveals the structure of the chip. Again, the process can be made more difficult, for example by providing some of the components vertically across several layers.

    Although these processes can reveal the structure of the chip, they do not indicate the voltages at each point. However, if the chip is undamaged, voltage contrast electron microscopy can be used to scan the chip in use, and watch the voltage level change over time.

    These processes are generally referred to as "stripping" or "peeling" the chip.

    Having stripped the chip, it can then be analysed using pattern recognition software and human inspection to get to a netlist and then a circuit diagram.

    Several firms on the Internet offer a service of scanning standard cell or gate to automatically generate a netlist (i.e. a low level circuit description which can be used to generate a new integrated circuit) (4).

    Contents ]


    De-compilers are programs which will convert object code back to high level languages such as C (although, to the uninitiated, a C program may be little more meaningful than object code!) (5).

    A range of other tools are available which can trace an analysis the operation of a program, represent the loops of the program and so on.

    Contents ]


    The input and output states of a chip can be monitored using an oscilloscope, or special purpose probes such as logic state analysers or protocol analysers, to acquire a picture of the behaviour of the chip over time or in response to input signals.

    Contents ]


    Many patented goods are not sold with restrictive licences, and hence a bona fide purchaser cannot usually be prevented by the patent from doing what they like with the patented product. Indeed, the patent itself may give the reverse engineer valuable information on how the patented product operates.

    However, a competitive product produced by reverse engineering may still infringe the patent itself - patent infringement does not require copying, and so "clean-room" techniques do not assist.

    Contents ]


    It is widely accepted that copyright does not protect "ideas", but only "expression"; that is, the way in which those ideas are "expressed". This idea is carried through into similar rights, such as Topography Rights. Copyright subsists in "copyright works". Reproduction or translation of the whole or a substantial part of a copyright work will constitute an infringement of copyright.

    Top level specification are themselves copyright works, and intermediate level specifications (source code and circuit diagrams) and lower level specifications (assembly code, net lists and node lists) may also qualify as copyright works.

    A common assumption is that the top level of a design specification is unprotectable by copyright, since it consists only of "ideas" (6). Some assume that this applies also to some lower levels insofar as they cover "algorithms" and not actual code.

    On this assumption, "clean-room" reverse engineering techniques succeed in breaking the chain of copying, since if only unprotectable ideas are communicated to the new design team by the reverse engineers, the new design team cannot be copying protectable "expression".

    However, this approach is incomplete. Firstly, it ignores the fact that the intermediate copies made during reverse engineering are themselves infringements. Secondly, at least in the UK, serious doubt has been cast on the correctness of this approach (7). Thirdly, modern engineering tools can directly accept some high-level specifications, which are thus akin to executable code rather than abstract description.

    In Europe, special codes of protection exist for computer programs (8), semiconductor topographies (9), and databases (10). Each of these contains special definitions of infringement which are binding across the EU, and which (for computer programs and semi-conductor products) mirror those created in the US.

    A given act of reverse engineering may involve several of these provisions; if so, it needs to be clear of infringement under each different head of copyright work.

    With copyright infringement, both the creation of the intermediate copy of the original design documents (which takes place after analysis of the product) and the ultimate products created from it may be infringements of copyright, as we will see from the cases.

    Contents ]


    In the case of computer programs, the EU directive states (11) that the ideas and principles underlying a program are not protected by copyright, and that (12) logic, algorithms and programming languages may to some extent comprise ideas and principles.

    Analysis of the function of a program (but not decompilation (13))is permitted under Article 5.3, if it is carried out by a licensed user in the normal use of the program.

    Reverse engineering is allowed under Article 6, but only for the single purpose of producing an interoperable program (rather than a competing program).

    For this purpose, in addition to reverse engineering itself (i.e. producing a high level version of the code) subsequent forward engineering to produce the interoperable program is permitted.

    However, the reverse engineer has to cross a host of formidable barriers before he can make use of this right;

    1. It must be indispensable to reverse engineer to obtain the necessary information.
    2. The reverse engineering has to be by a licensee or authorised user.
    3. The necessary information must not already have been readily available to those people.
    4. Only the parts of the program necessary for interoperability (i.e. the interfaces) can be reproduced.
    5. The information generated by the reverse engineering cannot be used for anything other than achieving interoperability of an independently created program.
    6. The information cannot be passed on to others except where necessary for this purpose.
    7. The information obtained cannot be used to make a competing program (rather than just an interoperable one).
    8. The "legitimate interests" of the copyright owner or "normal exploitation" of the program must not be prejudice.

    Thus, far from creating a general right to reverse engineer, these provisions create only the smallest of openings for the reverse engineer; they are intended for use only to defeat locked, confidential, proprietary interfaces.

    Contents ]


    Directive 87/54/EEC, and the corresponding US provisions of the Semiconductor Chip Protection Act 1984 (14), contain (15) the same distinction between the protection granted to topography and the concepts, processes, systems, techniques or encoded information embodied in the topography, which are not protected by the topography.

    The topography directive permits reverse engineering (16) (i.e. the analysis of a topography). It does not, however, allow all uses of the information obtained from reverse engineering.

    If a different topography can be created using the information derived from the original, so that it does not "reproduce" the original, then there will be no infringement of the topography right.

    If the reverse engineering information is used, by the reverse engineer, to create a new original mask work, then this too is not an infringement, apparently even if it reproduces a substantial part of the original chip topography. In other words, where a chip has been reversed engineered, chip protection right is useful only against pirates.

    There has been little case law under the chip protection provision. One case which went through three rounds in the US was the Brooktree v. AMD case (17), in which Brooktree Corporation brought an action against AMD, who were producing plug-compatible colour palette chips for use in graphics work stations.

    At the interlocutory stage, the Court held that if AMD could show they had reversed engineered the chip, then anything less than a substantially identical chip would not infringe Brooktree's topography rights. However, at the full trial in 1990, the jury found infringement and this was upheld on appeal in 1993.

    Contents ]


    Databases or collections of data in general may be protected under copyright law, and (in Europe) by a special sui generis right (20).

    Under previous UK copyright law, even the simplest tables of data would have qualified as literary work (19), but under the EU directive, the kind of data which makes up design documents for software, hardware or interfaces will rarely be entitled to copyright protection. However, where a significant investment has been made in compiling the data, then it may nonetheless be protected by the sui generis right (20). No specific reverse engineering rights are given under the sui generis right (despite the inclusion of such a right in the first draft (21)).

    It is not yet clear whether "substantial" means "expensive", or just "not trivial".

    Contents ]


    In the UK at least, copyright law makes no concessions to reverse engineering. The position will inevitably change somewhat in the specific fields of computer software and semiconductor topographies, but where any design document other than a computer program or a semi-conductor topography is copied then normal copyright law will prevail.

    For a three dimensional product, in general, reverse engineering need not recreate any of the design documents which lie behind the product. An analysis program might generate a table of computer-aided design (CAM) control data quite different to those from which the product was made. Further, in many countries, copyright does not offer protection to utilitarian three dimensional articles (although in the UK, the sui generis Design Right (22) does so instead, in similar fashion)

    However, where the reverse engineering process does recreate design documents, copyright or (in the UK) Design Right infringement may occur. For example, if reverse engineering of a PCB regenerates the net list from which it was produced (23), then the net list will be a copyright infringement. The same is true where a computer program is reproduced (24).

    The "fair use" defence to copyright infringement (25) permits copying where this is for the purposes of research or private study. However, in the UK, this does not extend to any commercial research or study, as would be involved in reverse engineering (26). In the specific case of computer software, decompilation is expressly not "fair dealing" (27).

    The position in the US is quite different; there, in the Sega Enterprises v Accolade (28) and Atari Games Corp v. Nintendo (29) cases, the intermediate copies produced by reverse engineering were held to be excused by the equivalent "fair use" defence.

    Contents ]


    Reverse engineering gives no general right to breach obligations to keep information confidential. For example, in Stac Electronics v. Microsoft Corp. (30), Stac (who defeated Microsoft in a patent infringement action) were themselves held to have committed a trade secret violation by reverse engineering features of a beta version of MS DOS, with which they had been supplied in confidence, and then using the reverse engineered information in their own product. The award of $13.6 million against them would have been significant, if they had not won a much larger amount from Microsoft.

    The position is more difficult where a product is widely distributed, but with a contract of sale which purports to include a confidentiality clause; it is not clear that a court would support a transparent attempt to portray as confidential something which was on open sale. Where reverse engineering of a software product is permitted under the EU Directive interoperability, then UK law will not enforce a contractual term to the contrary (31).

    Contents ]



    This US chip topography case concerned copying of 23-30% of Brooktree's colour graphics palette chip in AMD's plug-compatible copy. The copied part was the memory which allegedly was the "core" of the chip.

    At the interlocutory stage, the Judge concluded that whilst this would have been a "substantial part" and hence normally an infringing reproduction of the topography right, where reverse engineering was shown (as apparently it was) the test was whether the new chip was original over the old one - i.e. whether there was substantially identical reproduction. However, the Jury eventually found infringement at full trial, and were upheld on Appeal.


    This US software copyright case concerned Sega's video game console and cartridges. The cartridges had a 20-25 byte code segment which was interrogated by the console, as a security measure.

    Accolade disassembled the code which was common to three different Sega games cartridges, to find the security segment, and included it in competing games cartridges.

    The Ninth Circuit held this disassembly to be a permitted "fair use" of the copyright in the games programs.

    ATARI v. NINTENDO 975 F.2D 872 (FED. CIR. 1992)

    This US software copyright case concerned Nintendo’s NES video game console and cartridges. The cartridges contained a microprocessor, and program code, and was interrogated by the console microprocessor, as a security measure, like the Sega system. The security was potentially a two-way process, with the console checking for a valid cartridge and the potential for the cartridge to check for a valid console (which Nintendo did not actually do).

    Atari disassembled the program code which performed the security signalling exchange (the interface code). However, they also had access to a copy of the source code from the US Copyright Registry, to obtain which they stated (untruthfully) that it was for the purposes of litigation.

    They implemented the signalling exchange to validate the cartridge, thus achieving compatibility of their cartridges with Nintendo consoles. However, they went further and implemented the rest of the interface, to validate the consoles, apparently in case Nintendo changed their product in future. In each case, they copied some actual code, allegedly only to the extent necessary.

    The Court held that the intermediate copying during reverse engineering was legitimate, as "fair use". However, Atari infringed copyright nonetheless, in going too far in copying beyond what was strictly necessary. The programmer apparently also had sight of the source code from the US Copyright Registry, casting some doubt on whether the copying was solely due to the reverse engineering operation.

    Finally, Nintendo had a patent on the interface, and Atari were found to infringe that too.

    AUTODESK INC v. DYASON [1992] RPC 575 & (NO. 2) [1993] 12 RPC 259

    This Australian software copyright case concerned a CAD package, which was supplied with a hardware device containing an EPROM, called the AutoCAD lock, which operated with part of the package called the "Widget-C" program. The program sent a challenge signal to the lock, which replied with a return signal. The program checked the return signal against a lookup table. The lookup table comprised 16 bytes of a 30kByte program. An encrypted form of the lookup table was held in the lock EPROM.

    The Defendant studied the signals with an oscilloscope, and read them. Apparently, the correct contents of the EPROM were deduced from this functional analysis, without reading of the EPROM. They then produced an alternative lock device. The Plaintiff alleged that the table was a substantial part of the program, and that the program had thus been copied.

    The Court held that the table was a substantial part of the program (an issue of importance rather than size) and that it had been copied, and that this was an infringement. A move to re-hear the case, on the basis that the Court had misunderstood, was dismissed (with dissenting judgements).


    This Australian software copyright case concerned a database management system (Dataflex) which was "cloned" by the Defendant. Apparently, although the Court referred to reverse engineering, the Defendant did not actually analyse the code by decompilation or disassembly, but read the manual to produce a lookalike using the same commands and file structures. All this was held not to infringe.

    However, Dataflex used compression of records, using a stored table of Huffman codes to compress and decompress. The table thus constituted an interface between the program and the files. There is no indication that the files were to be shared with other programs, so the table was not an interface to non-competing interoperable programs. The Defendant wanted his program to be able to read files created by Dataflex and so he calculated the required compression table, apparently from inspection of stored records, which therefore reproduced that of Dataflex.

    It was held that although the table was not a substantial part of the program (or even part of the program at all), it attracted literary copyright as a compilation in its own right, and that copyright was held infringed.


    This Singapore software copyright case concerned the Sound Blaster PC Sound Card It contained firmware, and was supplied with an ancillary PC program to operate with it. The Defendants wanted to produce a sound card which could interoperate with PC programs which would operate with the Sound Blaster – in other words, to create a competing substitute. They bought and studied a Sound Blaster and ancillary program. They were held (on the balance of probabilities) to have disassembled and reverse engineered the firmware, and admitted running the ancillary program (which they pleaded as a "fair dealing"). In their product, only about 4% of the code was identical to that of the Sound Blaster firmware, but that 4% included redundancies and errors present in the original, suggesting copying (going beyond that which is necessary).

    The Court held (reversing the first instance) that although the ultimate products did not involve a substantial reproduction of the original program, there was clear evidence that reverse engineering had been used and hence that an intermediate copy had been made. This and the admitted copying (in unlicensed use) of the ancillary program were both not "fair dealing", and hence infringed.


    This UK copyright case concerned an electronic dust meter analyser, and involved a computer program, some engineering drawings, and some circuit diagrams for a PCB. The Defendant was in liquidation, and the Judge found clear infringement of the first two items, so the Report concerns only the PCB circuit diagrams.

    Apparently, the Defendants reverse engineered the Plaintiffs PCB and extracted from it a net list specifying the components and their interconnection, which they then used to make further PCBs.

    The Judge understood that the net list could be interpreted by computer to produce either a circuit diagram or instructions to make a PCB (i.e. higher or lower level descriptions).

    He held that the Plaintiff’s circuit diagrams contained not only an artistic work (the drawing) but also a literary work (the identities represented by the component symbols, and their interconnections, making up a table or a compilation). This literary work was reproduced in the Plaintiff’s PCBs, and hence was copied by the Defendants in their net list derived from the PCBs and containing the same information. This conclusion was later criticised in a later case (Electronic Techniques (Anglia)) Ltd. v. Critchley Components Ltd. [1997] FSR 401 at 412-3) and is still unresolved (Mackie Designs Inc. v. Belivinger, [1999] RPC 717 at 720).

    He did not need to decide whether the Defendants PCBs were also infringements as well as their net list, but logic compels this conclusion. A later case (Autospin (Oil Seals) Ltd v Beehive Spinning, [1995] 23 RPC 683) considered this last point with favour, but decided on other grounds.


    This Irish software copyright case concerned a satellite decoder operated by a Smart Card including a microprocessor and software operating a complex authorisation algorithm to unlock the decoder and unscramble the TV signal. The Defendant marketed a Smart Card which replicated these functions.

    Smart cards cannot be read like conventional computer memories, but the Plaintiff’s case was that they could be reverse engineered using electron microscopy and chip stripping. The Plaintiff had no evidence of reverse engineering but pleaded that because of the complexity of the algorithm, it must be presumed to have occurred and the burden of disproof should lie on the Defendant.

    The Judge declined to accept this presumption, and commented that if reverse engineering was possible, then they should reverse engineer the alleged infringement to obtain evidence of infringement.


    Mars manufacture coin accepting devices for use in vending machines, to determine the denomination and validity of inserted coins. Measurement values, characteristic of genuine coins of each type, were stored in EEPROM in the apparatus in encrypted form.

    When new types of coins were introduced, or the design of an existing denomination was changed, it was necessary to reprogram the EEPROM with new values, using a programming device which communicated with the validator, using communications protocols. Mars supplied reprogramming devices to authorised reprogramming agencies.

    Teknowledge were a non-authorised re-programmer. By analysing the communications protocol and the contents of the EEPROM, they managed to defeat the encryption and learnt the communications protocols. It was conceded that, in the process, they necessarily reproduced the contents of the EEPROM, and of the communications programs.

    Mars brought action for infringement of their copyright in the communications programs, and their database right in the contents of the EEPROM. It was clear that Teknowledge could not avail themselves of the limited reverse engineering defences provided in European copyright law, but they attempted to argue a general right to repair or, alternatively, that the sale by Mars left no rights outstanding to them on the basis of the "non-derogation from grant" principle stated in BL v. Armstrong (32).

    The Judge held that both the copyright in the program and the database right had been infringed by Teknowledge. The European Directives overrode earlier UK common law copyright defences, to provide a complete code on reverse engineering. Even if this were wrong, there was no evidence to shown that Mars was in a monopoly position where "non-derogation from grant" might apply, as in Canon v. Green Cartridge (33).

    Finally, the Judge held that the mere use of encryption per se was not enough to create an obligation of confidentiality; the reverse engineering was not a breach of confidence.


    1. For the US DoD position, see "Reverse and Re-Engineering in the DoD Organic Maintenance Community; current status and future direction", M T Traband et al, Technical Memorandum file number 96-060, 19 February 1996, and ARL's site. For the IEEE position, see the Position Statement of November 1993 of the IEEE United States Activities Board.
    2. See their website
    3. See Footnote 1
    4. See, for example, Quadic Systems’ website
    5. See"Reverse Compilation Techniques", C. Cifuentes, Queensland University of Technology, PhD Thesis, July 1994, and Imagix'swebsite
    6. A simplification of the Abstraction-Filtration-Comparison approach of Computer Associates v. Altai, (1992) 982 F.2d. 693 (2nd Cir)
    7. Ibcos Computers Ltd v. Barclays Mercantile Highland Finance Ltd. [1994] FSR 275
    8. Council Directive 91/250/EEC 14 May 1991; enacted in the UK as S.I. 1992 No. 3233
    9. Council Directive 87/54/EEC 6 December 1986; enacted in the UK as S.I. 1989 No. 1100
    10. Council Directive 96/9/EC 11 March 1996; enacted in the UK as S.I. 1997 No. 3032
    11. 13th recital
    12. 14th recital
    13. See, for example, Copyright, Designs and Patent Act 1988, Section 29(4)
    14. Title 17 USC Chapter 9
    15. Article 8
    16. Article 5.3
    17. Discussed at, for example, [1989] 2 EIPR D-30 and [1990] 11 EIPR D-221
    18. Council Directive 96/9/EC 11 March 1996, Chapter III
    19. See, for example, the football pools coupons of William Hill (Football) Ltd v. Ladbroke (Football) Ltd, [1980] RPC 539 and [1964] 1 W.L.R. 273
    20. See footnote 19 supra
    21. See Article 11(1) of the draft at COM (92) 24 final - SYN 383, 13 May 1992; COM (93) 464 final - SYN 393, 4 October 1993
    22. Copyright, Designs and Patents Act 1988, Part III
    23. As in Anacon Corp. Ltd v. Environmental Research Technology Ltd, [1994] FSR 659
    24. For example, Creative Technology Ltd v. Aztech Systems Pte Ltd [1997] FSR 491, in which the equivalent Singapore provision was considered
    25. Copyright, Designs and Patent Act 1988, Section 29
    26. See Creative Technology Ltd v. Aztech Systems Pte Ltd, supra
    27. Copyright, Designs and Patent Act 1988 Section 29(4)
    28. 977 F.2d 1510 (9th Cir. 1992). Discussed at [1993] 1 EIPR 34 and extensively elsewhere
    29. 975 F.2d 872 (Fed. Cir. 1992). Discussed at [1994] 4 EIPR 175 and extensively elsewhere
    30. See [1994] EIPR 364
    31. Copyright, Designs and Patents Act 1988, Section 50B (4)
    32. British Leyland v. Armstrong [1986] AC 577
    33. Canon v. Green Cartridge [1997] AC 728


    1. Behrens, A and Levary, R "Practical Legal Aspects of Software Reverse Engineering" Communications of the ACM, Vol 41, No 2 February 1998 pages 27-29.
    2. Cifuentes, C and Fitzgerald, A "Reverse Engineering of Computer Programs: Comments on the Copyright Law Review Committee's Final Report on Computer Software Protection", Department of Computer Science, University of Tasmania.
    3. Cohler, C and Pearson, H "Software Interfaces, Intellectual Property and Competition Policy" [1994] 10 EIPR 434.
    4. Davis, G III "Scope of protection of computer-based works: Reverse Engineering, clean rooms and decompilation". In 15th Annual Computer Law Institute Handbook Series (Patent, Copyright, Trademarks and Literary Property Course), 1993, pages 1-15.
    5. Hunter, D "Mind Your Language: Copyright in Computer Languages in Australia" [1998] 3 EIPR 98. Jew, B "Full Bench Appeal Successful – Powerflex Services Pty Ltd v. Data Access Corp", [1997] 12 EIPR 732.
    6. Johnson-Laird, A "Reverse Engineering of software - Separating Legal Myth from Actual Technology" Software Law Journal, Vol V, April 1992, No 2 pages 331-354.
    7. Lai, S "Recent Developments in Copyright Protection and Software Reverse Engineering in Singapore" [1997] 9 EIPR 525.
    8. Maebius, S "The New Use of Fair Use: Accessing Copyrighted Programs Through Reverse Engineering" 75 JPTOS, page 431.
    9. McCabe, P "Reverse Engineering of computer software: A trap for the unwary?" Comput. L. Assoc. Bul. 1, 2 (Feb 1994), pages 1-15.
    10. McManis, C "Intellectual Property Protection and Reverse Engineering of Computer Programs in the United States and the European Community" BTLJ, Issue 8:1 - Spring 1993.
    11. Stern, R "Reverse Engineering for Future Compatibility - Atari v. Nintendo" [1994] 4 EIPR 175.
    12. Stern, R "Reverse Engineering of Software as Copyright Infringement - An Update: Sega Enterprises Ltd v. Accolade Inc" [1993] 1 EIPR 34.
    13. Vinje, T "Threat to Reverse Engineering Practices Overstated - Stac Electronics v. Microsoft Corporation" [1994] 8 EIPR 364.
    14. Wee Loon, N-L "Legitimizing Reverse Engineering of Computer Programs in Copyright Law - How far have we gone in Singapore?", International Journal of Law and Information Technology, Vol 4: January-December 1996, Issue 1: Spring 6, pages. 48-64.

    Contents ]