Reverse engineering is a fundamental software development process which almost all programmers dive into at one time or another, whether with their own or someone else's code, whether they want to or not. The courts have defined reverse engineering as "a fair and honest means of_starting with the known product and working backwards to divine the process which aided in its development or manufacture." As for software reverse engineering, the courts go on to say it's "the process of starting with a finished product and working backwards to analyze how the product operates or it was made." Reverse-engineering expert Andy Johnson-Laird points out that both definitions focus on the reverse-engineering process, not the resulting product, adding that "the static and dynamic examinations of a computer program are the only two activities that are viewed by programmers as being reverse engineering."
Even though it's protected by copyright law, reverse engineering is nonetheless under fire. In fact, if the federal government--pressured by influential software companies--gets its way, reverse engineering may be limited to inspection of software you write, and outlawed in all other instances.
Of course, reverse engineering isn't unique to software development. When an anonymous caveman fashioned the first wheel, an enterprising hardware guy in the next cave probably figured out how to turn a similar hunk of rock into a similar cylinder. From computer chips to potato chips, every industry engages in reverse engineering. Still, it is software reverse engineering that's at the eye of the storm.
Much of the current furor over software reverse engineering revolves around international intellectual-property protection. Recent changes in European Community law allow you to reverse engineer when you want to create software that interoperates with, but does not replace, the original program. In light of the EC provisions (not to mention U.S. cases such as Sega vs. Accolade and Atari vs. Nintendo, both involving reverse engineering), Japan is re-examining its intellectual-property laws, and U.S. software companies fear that the Japanese will be equally lenient when it comes to reverse engineering. Spurred on by IBM, Microsoft, Apple, and others, U.S. trade representatives have sent letters to the Japanese expressing "grave concern" over the possibility that Japan will relax reverse engineering laws.
Confused by the intellectual-property debate, the knee-jerk reaction of most developers is to prohibit reverse engineering. Take a look at the shrink-wrap licenses of software on your shelf (including that of the Dataware search/retrieval engine at the heart of the Dr. Dobb's/CD) and you'll find what Walter Oney (who writes this month's "Programmer's Workbench") calls "draconian" license restrictions forbidding you to modify, translate, adapt, reverse engineer, decompile, or disassemble the software. Amazingly, you sometimes don't even get to read the license until after breaking the seal. Of course, the validity of this shrink-wrap ban on reverse engineering has yet to be tested in court, although both Illinois and Louisiana have statutes legalizing such prohibitions.
The limits of reverse engineering may eventually be determined by a pivotal court case in which Microsoft claims that Stac Electronics reverse engineered betas of MS-DOS 6.0. It's ironic that, on one hand, Microsoft enjoins reverse engineering of its software, while on the other implicitly condoning the process by publishing articles such as Matt Pietrek's excellent "A Look under the Hood of the Windows 3.1 Global Heap and the Functions that Maintain It" in Microsoft Systems Journal (March, 1993). While he doesn't use the "R" word in the article, Pietrek clearly states that the article was adapted from his book Windows Internals, where he openly acknowledges that the information was gained via reverse engineering.
This isn't to say that the right to reverse engineer software hasn't been abused. However, reverse engineering is too difficult, time consuming, and expensive for software thieves (the convenient targets of those who would ban reverse engineering) to bother with. It's more cost-effective for pirates just to copy software.
There are good reasons for going to the trouble of reverse engineering: recycling old software for new systems, rooting out bugs coded by programmers no longer around, and ensuring compatibility with existing software. Perhaps even more important in these days of intellectual-property litigation, reverse engineering provides a way to identify patented technology so that you can avoid infringing upon it.
In the long run, U.S. companies may do themselves more harm than good by stifling reverse engineering, particularly if it's restricted in the U.S. and legal elsewhere in the world. In the short term, software companies have to realize that they can't have it both ways: If you don't want programmers stepping all over your intellectual property, you can't bar them from discovering what that property is--and reverse engineering is the best way to find out.
Jonathan Erickson
editor-in-chief
Copyright © 1994, Dr. Dobb's Journal