Reading about proprietary software law is sometimes a shock, when you are
used to the freedoms of the free software community, because your natural response
to hearing how the law works outside the community is to say: "But that's
awful. That can't be the law." And frankly there is nothing that
advertises the benefits of free licenses as clearly as a brief rundown on
what you can't do outside that realm of freedom. 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 do.
The center of that
restrictive universe right now is the US. Cem Kaner, Professor of Software
Director, Center for Software Testing Education & Research at the
Florida Institute of Technology, believes that restrictions on reverse
engineering are 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.
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 virtualization specialist, provides some possible
- 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 to be a good thing, 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, this exception is unclear enough that some have become afraid to avail
themselves of it. 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
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
- 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 specialized subset of reverse
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 patents 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.
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
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
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) 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)....
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.
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 itself. That is why
you can do reverse engineering to figure out how software works and then
write your own program 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
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:
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.
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;
here is his answer:
Hard to say, since I don't have a
good understanding of the US position. However, the A-US FTA [Free Trade
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  403 FCA). So there is definitely scope to argue that
these exceptions are even narrower than they seem.
The anti-circumvention language in the FTA looks likely to keep lawyers
employed for some time:
The anti-circumvention provisions in the FTA are marvelously Byzantine.
I invite you to make sense of them on a first or second reading.
(a) they set up a number of prohibitions and a number of possible
(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
(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
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 European Union, 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 written, 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 it 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.
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
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 -- a bit like the old days of changing the operating
system date back in time so your legal but time-restricted program
would run. When a DRM-protected media player thinks it is drawing
on a big digital LCD screen in may in fact be a window on your
desktop - or a network connection to the world! And only run
certain software on frotz-certified chipsets? No problem, just
implement the chips 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.
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.
Please see this page for a set of pointers
to additional reading in international copyright law and reverse
to post comments)