But with the recent flap about BitKeeper, it might be good to review what the current state of the law is on reverse engineering.

Unfortunately, if we define reverse engineering as trying to figure out how something works, then the state of the law is that there are places on Planet Earth where there are laws restricting what you are allowed to find out by means of reverse engineering software. The center of that restrictive universe right now is the US. Cem Kaner, Professor of Software Engineering and Director, Center for Software Testing Education & Research at the Florida Institute of Technology, believes it is holding American programmers back from being able to compete:

"The recent flurry of rulings that reverse engineering of mass-market products is not fair use have tied one arm behind American programmers' backs while leaving everyone else free to compete with us. . . . These days I teach university courses (undergrad through doctoral) as a Professor of Software Engineering at Florida Tech. We have a lot of grad students from other countries. They are often surprised by our restrictions on reverse engineering -- they certainly don't have their hands tied by these restrictions in their companies.

"The United States used to have a commanding lead in software development. We have been steadily losing that lead. Part of the reason for this is that for the last 15 years, lawyers for software publishers have been pushing for short-term advantages for their clients over the long term health of the industry. The ban on reverse engineering is just another example -- we are shooting the American industry in the head, with little actual benefit for anyone (publisher or engineer) in the United States, but plenty of benefit for engineers in all the rest of the world.

"I welcome international competition. I educate students from around the world and work with engineering faculty from around the world. But there is a big difference between losing to fair competition and losing to suicidal greed."

Let's take a look at what you can and can't do around the world, when you wish to reverse engineer proprietary software. We can view it as we would learning about a repressive government's laws about dress code or some other issue you don't normally worry about, but need to study and obey for travel there, so you don't end up in the clink, so to speak, for wearing shorts or sandals or whatever else they have in their beanie as being worth making a law about.

I polled attorneys and engineers in the US, the UK, and Australia, and I've collected some resources as well, and I've found that there is a good deal of flux and some confusion in this area of law. I am not a lawyer, as you know, so if you need to know how the law applies in a particular situation in your area, please get advice from an attorney.

Why Do People Reverse Engineer Anyway?

People have many reasons why they might wish to reverse engineer software, but two important ones are 1) to make software that can interoperate with the software being studied and 2) to make a product that will compete with it. Why might the the knowledge not be visible? Dan Shearer, Samba Team and open source virtualisation specialist, provides some possible reasons:

* The original programmer is dead, or the company has died, or otherwise events have buried the explanation for how a technology works from the engineer and perhaps everyone else;

* Commercial protection. A company feels its commercial goals would be compromised if the knowledge was published, so it keeps the knowledge secret (and often tries to obscure the knowledge so it is difficult for anyone to find it.)

* Encumbrance on the knowledge. The knowledge might be published, but under such terms as anyone who agrees to the conditions under which the publication is made is limited in what he can do with it. Example: Microsoft's approach to detailed API sharing (Kerberos etc etc.) So the reverse engineer may choose not to see the knowledge. A basic encumbrance is sometimes cost for access to the documentation.

Having said that, the problem with seeking to know whether you can do reverse engineering or not is that it isn't consistent around the world, so your answer depends on where you do it and why.

A Brief US History of the Law on Reverse Engineering

Reverse engineering of manufactured products was originally designed, in US law, as a kind of balancing limit on trade secret protection, to ensure that a company couldn't gain, through that back door, a perpetual, unlimited monopoly on unpatented inventions. With manufactured products, the system worked well. As long as you bought the product legally, you were free to take it apart and see how it ticked. Most of us did that to clocks, radios and various other appliances when we were kids. We were free to do that because trade secret law didn't grant the owner the exclusive right to possess the secret. It only protected the owner against improper acquisition and/or disclosure of the trade secret.

That means that if I broke into your factory and stole your product and then reverse engineered it to figure out how you did it, it wasn't all right, but if I bought your product, it was perfectly legal, and you couldn't prevent me from discovering your secret, if I was willing to put in the time and effort to reverse engineer to obtain it. Reverse engineering was a lawful way to obtain a trade secret. And the time and effort involved was considered enough of a barrier that it gave the owner of the trade secret a measure of protection, by giving him a running start ahead of any copycats.

In fact, reverse engineering was considered a positive, and in the 1989 U.S. Supreme Court decision, Bonito Boats, Inc. v. Thunder Craft Boats, Inc., the court said that reverse engineering was "an essential part of innovation," because it could lead to advances in technology. If you remember the DVD Copy Control Association v. Andrew Bunner case in California, it was a trade secrets case that held that reverse engineering is presumptively legal.

Both white box reverse engineering, decompiling the object code to reveal its structure and figure out the interface specifications for interoperability purposes, and black box reverse engineering, where you only look at a program's input and outputs, are legal normally in the US, if the goal is interoperability. I say normally because fair use is decided case by case. Bypassing anticircumvention devices, however, is a separate no no. Section 1201 of the DMCA forbids reverse engineering if it involves circumvention of a technological protection measure, with limited exceptions, such as for encryption research and security testing. You could probably get away with reverse engineering to fix something, and while security testing is explicitly allowed under the DMCA, it's unclear enough that some have become afraid to avail themselves of the research exception. Fred Von Lohmann of the EFF has described Section 1201 like this: "thou shalt not circumvent" and "do not break into my castle and do not violate my house rules -- seen from the perspective of a copyright holder".

Why Software is Different from a Cotton Gin

There are differences between reverse engineering a mechanical device, like a cotton gin, and reverse engineering software. Shearer says this about the difference:

"By reverse engineering in software we generally mean one of the following:

* Exposing knowledge not visible to the Reverse Engineer which is encapsulated in an computing/electronic format, without necessarily doing anything much with that knowledge. For example, I might reverse engineer a protocol and publish an opinion about whether or not it meets the standards the manufacturer of the software claims it does. Myth: reverse engineering involves creating software, necessarily. It often does in the sense that you need to test your assumptions as you reverse engineering, but the very act of figuring it out is reverse engineering. Very different from the mechanical use of reverse engineering.

* Creating functional equivalency for something whose internals are obscured. The working result is an example of reverse engineering and it is usual that the internals of the result are very unlike the internals of the original. This differs greatly from the normal case in mechanical reverse engineering.

"Another term is "decrypting". This is a specialised subset of reverse engineering."

Because computer software can be protected not only by trade secret law but by copyright and patent law as well, the issue of when you can and when you can't reverse engineer gets complex. If I invented the cotton gin, I could patent it for a time, gaining a monopoly for a time with the tradeoff that I must reveal all my secrets, *or* I could protect how I did it as a trade secret, and I couldn't use copyright to protect the product at all. So my cotton gin invention got one form of protection, tops.

With software, you can get at least two bites of the apple simultaneously. Software is automatically copyrighted, and it can be patented too. And you can opt for trade secret protection instead of patents. Then you can slap a restrictive license on top, if the market will let you get away with it. In fact, in the US, it's the latest trend. And that is part of what makes it so complicated to figure out when you can and when you can't reverse engineer. It's also why some view software patents as overkill. Kaner on recent US decisions that reverse engineering is not fair use:

"The saddest aspect of these rulings is that judges seem to have little understanding of what they are actually ruling on.

"For example, the court in Bowers v Baystate Technologies (Federal Circuit, 2002 U.S. App. LEXIS 17184) tells us that

In this case, the contract unambiguously prohibits "reverse engineering." That term means ordinarily "to study or analyze (a device, as a microchip for computers) [*15] in order to learn details of design, construction, and operation, perhaps to produce a copy or an improved version." Random House Unabridged Dictionary (1993); see also The Free On-Line Dictionary of Computing (2001), at http://wombat.doc.ic.ac.uk/foldoc /foldoc.cgi? reverse+engineering (last visited Jul. 17, 2002). Thus, the contract in this case broadly prohibits any "reverse engineering" of the subject matter covered by the shrink-wrap agreement.

"This prohibits not only decompilation and disassembly but any detailed study of the product, including study by examining its behavior. It would forbid independent behavioral testing of a product by a third party (evaluating its security flaws, for example, prior to a purchase decision). It would forbid independent behavioral testing by a third party licensee for the purpose of publishing product reviews in a magazine.

"Even a narrow ban on reverse engineering bans much, much more than competitive activity by another business. Take a look at http://www.kaner.com/pdfs/ucreveng.pdf. The examples provided in that article are banned by the industry-wide practice of including a didn't-used-to-be-enforceable prohibition of reverse engineering in their licenses."

The fact that software can be protected so many ways also means you can be sued on all of them, trade secret, copyright, patent and contract law theories, if you were unfortunate enough to have signed away your rights to reverse engineer (or to tell what you learned from doing so). Software licenses that forbid reverse engineering may or may not stand up to a challenge, but most folks think that they will. At any rate, there was a case where a federal court of appeals said that such a provision is enforceable and does not conflict with the Copyright Act, and the Supreme Court declined to review the decision, and they would have, if they had seriously disagreed. So be careful what you agree to.

Software is therefore a separate issue when it comes to reverse engineering. The time and effort involved isn't equivalent to reverse engineering a cotton gin, particularly with computers automating some of the heavy lifting.

When Can You Reverse Engineer? -- It Depends

Copyright protects the expression of an idea, but not the idea. That is why you can do reverse engineering to figure out how software works and then write your own to do the same thing. The problem that arises with copyright and reverse engineering is well expressed in this explanation of how to avoid a copyright infringement claim:

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.

Patents protect the implementation of the idea, and that makes it the bully on the block, particularly in software, where there may be limited optimal ways to accomplish something. There is no fair use or reverse engineering exemption with patents. So you can argue all you want about how you had a fair use right to reverse engineer under copyright law, but if the part of the software you reverse engineered was also patented, you are, with some limited exceptions, sunk.

And how do you know in advance if you are going to end up violating a patent? Don't ask me. Nobody seems to know how to avoid violating someone's software patent under the current US system. You seem to find out mainly when someone sues you. Many observers believe the US patent system is broken and needs to be reformed, at a minimum, so that honest people can figure out how to avoid infringement. Meanwhile, ask your lawyer.

But just know that there is no reverse engineering right per se with patented inventions to find out how they work. It was originally the case that with patents you were supposed to reveal the tricks you used. It was the tradeoff. Sadly, software patents are now granted in the US without applicants having to reveal all the inner workings, so some legal commentators have argued that reverse engineering doesn't infringe under the first sale principle of patent law, or if you do it to satisfy your scientific curiosity, that you could assert an experimental use defense. And note that while under copyright law interfaces are not protected, they can be under patent law.

Whether or not reverse engineering is legal also depends, I've learned, on where you do it and why. Note that what matters is where the reverse engineering was done, not where the software was written. If you are in the US and you are doing it for interoperability purposes, as opposed to for the purpose of creating a similar and competitive product, you are probably safe from a copyright infringement claim, but may run afoul of a patent. (But in any particular situation, hire a lawyer to advise you.)

What About Outside the US?

The US is easy to figure out, compared to, say, Japan. At least in the US, they put it in writing. In Japan, it's assumed that reverse engineering for interoperability purposes is probably legal, but the law doesn't come right out and say so. In Japan, the law has no "fair use" concept for computer software, so reverse engineering is technically copyright infringement. Yet, as noted, most legal scholars say that reverse engineering is probably legal in Japan in a practical sense, even though their copyright law doesn't explicitly say that. Note that Japan does accept software patents.

Here's a PDF that tells you what you can use reverse engineering to accomplish in Australia, and as you can see, it's essentially similar to the US:

Making interoperable products

A computer program may be reproduced or adapted in order to get information necessary to enable an interoperable product to be made. The relevant provision also allows the person making the interoperable product to reproduce or adapt the original program in the interoperable product, but only to the extent necessary to enable interoperability either with that program or any other program.

Security testing and error correction

A non-infringing copy of a program may be reproduced or adapted by or on behalf of the owner or licensee of the copy for various security testing purposes, and to correct errors and security flaws, if such reproduction or adaptation is reasonably necessary to achieve the relevant purpose, and only where the resulting information is not readily available from another source.

I asked Brendan Scott, of Open Source Law, an expert on tech law there, if it would be accurate to say that you can do more in Australia than in the US, or if their new law is as restrictive as ours, and here is his answer:

"Hard to say, since I don't have a good understanding of the US position. However, the A-US FTA requires Australia to implement a provision relating to anti-circumvention. There is a 2-year period from the implementation of the FTA in which the anti-circumvention provisions must be implemented -- so they are not in our law at the moment.

"At the moment there is an exception to infringement for the reproduction of literary works which are computer programs -- the issue is that a work may comprise both a literary work and subject matter which is not a literary work. If multiple copyright exists then the exception is a bit useless -- for the purposes of making interoperable programs (s 47D), to correct errors (s 47E) or for security testing (s 47F). Whether interoperability between programs includes interoperability between a program and some data has not been considered.

Further, if analysis of the program relies on reproducing anything which is not a literary work the exception won't help. The Full Federal Court has held that the "aggregate of the visual images generated by the playing of [specific video games the subject of the suit] constituted a cinematograph film [ie something other than a literary work]" (Galaxy Electronics v Sega Enterprises [1997] 403 FCA). So there is definitely scope to argue that these exceptions are even narrower than they seem.

"The anti-circumvention provisions in the FTA are marvellously Byzantine. I invite you to make sense of them on a first or second reading. Stucturally:

(a) they set up a number of prohibitions and a number of possible exceptions;
(b) implementing the prohibitions in local law is mandatory, implementing the exceptions is discretionary;
(c) no exceptions other than those set out in the relevant clause may be implemented;
(d) not all exceptions apply in respect of each prohibition;
(e) arguably, the prohibition on circumvention does not require that the circumvention be or lead to an infringement in order to be actionable -- removing a technological protection which has been applied to Hamlet will still be an infringement. The Hamlet argument is available where the words "a protected work" are read as meaning protected by the technological protection measure. They might also be read to mean "protected by this chapter" or "protected by copyright" which may have a different effect (in any event, bundling a protected with an unprotected work under the protection measure would probably still qualify);
(f) the exceptions to circumvention generally require that the circumvention itself be non infringing.

"So, for example, 'non-infringing reverse engineering activities with regard to a lawfully obtained copy of a computer program, carried out in good faith with respect to particular elements of that computer program that have not been readily available to the person engaged in those activities, for the sole purpose of achieving interoperability of an independently created computer program with other programs' (17.4.7(e)(i)) is a possible exception to the prohibition, required to be implemented by the FTA, against circumventing protection measures. However, someone wishing to analyze a program covered by a protection measure would not only have to meet this requirement, they would also need to comply with section 47D of the Copyright Act. The relevant FTA provisions are here.

"The current Copyright Act is available here."

In the EU, reverse engineering is allowed under Article 6 of the European Software Directive, for interoperability purposes only, not for creating a competing program, and the law strictly limits what you can do with the knowledge you gain. You can't publish it, for example. As you know, the patent situation in the EU is a bit messy at the moment. Software patents are supposedly not allowed, after the Munich Convention, but folks have found ways, and that effort continues. Should the directive pass as presently constituted, it is expected to make reverse engineering of any patented materials illegal, except for limited exceptions. The directive also states that the ideas and principles underlying a program are not protected by copyright, and that logic, algorithms and programming languages may to some extent comprise ideas and principles.

There are some differences between US and UK law, and here's a paragraph from the UK Patent Office website on what constitutes a copy of a computer program in the UK:

Computer programs are protected on the same basis as literary works. Conversion of a program into or between computer languages and codes corresponds to "adapting" a work and storing any work in a computer amounts to "copying" the work. Also, running a computer program or displaying a work on a VDU will usually involve copying and thus require the consent of the copyright owner. The copyright owner will usually need to give permission for 'adapting' and 'copying' a work, however you may not need permission to make transient or incidental temporary copies.

There is no provision for decompilation (white-box reverse engineering) in UK copyright law, and no fair use defense if the reverse engineering is for commercial research or study. And, there is no right to breach confidentiality agreements. In Stac Electronics v. Microsoft Corp., Stac was found to have committed a trade secret violation by reverse engineering a beta version of MS DOS that they had gotten in confidence and then using the information they gained in making their own product. However, in the UK, the EU copyright directive trumps any contractual agreement that contradicts, so decompilation carried out for the purpose of interoperability is allowed, under that umbrella, as long as you don't reveal any confidential data.

There is also a provision (50BA) made for "observing, studying and testing of computer programs":

(1) It is not an infringement of copyright for a lawful user of a copy of a computer program to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.

(2) Where an act is permitted under this section, it is irrelevant whether or not there exists any term or condition in an agreement which purports to prohibit or restrict the act (such terms being, by virtue of section 296A, void).

So, there is no fair use (or fair dealing, UK's much stricter escape hatch) for decompliation or copying during decompilation. However, sniffing (black-box reverse engineering) for interoperability purposes is allowed.

Note that the UK began to revise its patent law in January of 2005. Also, be aware that this article does not touch on Germany, much of Eastern Europe, most of South America.

Summing Up

Kaner points out that there is research going on to make reverse engineering technically impossible:

"I think the most interesting development in this area is technical, not judicial. Significant progress is being made on making object code essentially indecipherable. This is the subject of ongoing doctoral research in computing, industrial research, and at least one book in development."

Shearer brings up an interesting point:

"Virtualization is the bane of the anti-reverse engineering crowd and especially the DRM and we-lock-down-your-hardware subtypes, although it is seldom identified as such. This is because if the hardware is in fact software, we can trick it to tell all sorts of lies or truths. Only play back a movie on frotz-certified graphics chips? No problem, just write the chip in software."

The general trend in the law is to harmonize laws around the world, so they are interoperable, so to speak, to reach an international working consensus on what the laws on copyright and patents ought to be. It's obvious why that would bring benefits. Legislators can see that clearly. Unfortunately, not everyone in the world as readily sees the real benefits that come from interoperability in software.

Everyone sees the benefits of having train tracks be uniform, so you can get on a train in New York and arrive in California safely, and without having to get off and then on another train for another width of tracks. It's no different with software. And as software becomes more and more obviously the underpinning of a globalized society, including its commerce, hopefully more and more legislation will reflect that awareness.

In the meantime, please be careful. That includes using this article only as a jumping off point, and asking your attorney for advice for any real-world application of the law in your area of the world.

Resources

US:

I asked Fred von Lohmann, Esq., of EFF what would be a good article for an overview and he suggested "Is Reverse Engineering Always Legal?" It was written in 1999, but it's still applicable.
2001 IEEE seminar on reverse engineering.
US Copyright Act
DMCA[PDF] - circumvention is covered in Section 1201
Title 17: US Code -- Limitations on exclusive rights: Computer programs
Cases:

Sega Enterprises Ltd. v. Accolade Inc.
Atari Games Corp. v. Nintendo of America, Inc.
Kewanee Oil Co. v. Bicron Corp. (1974) (Supreme Court says grant of patent extinguishes trade secrecy because of patent disclosure requirements).
Bowers v. Baystate Technologies, Inc. - EULA not preempted by Copyright Act
SONY v Connectix

International:

TRIPS
WIPO Copyright Agreement
An overview [PDF]

Japan:

Japanese copyright law

Australia:

Australian Law Online
Australian copyright law explained[PDF]
Cases:

Autodesk Inc. v. Dyason
SONY v. Stevens (summary); and the decision
Powerflex Services Pty. Ltd. v. Data Access Corp.

The EU:

Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonisation of certain aspects of copyright and related rights in the information society

European Commission directive on copyright enforcement - articles 5 and 6
Proposed European Commission directive on computer implemented inventions- see Section 6.
FFII on Software Patents

UK:

UK Copyright Law

Terminology:

Reverse Engineering
Why We Need a New Term for Reverse Engineering
Decompilation