Heres a little test. Go to Google and type the search phrase define: reverse engineering. Youll be given a list of definitions, some of which are short and concise and some of which are long, rambling and esoteric. But, basically, these results split into two mind-sets.
The first mind-set is probably best represented by the definition currently provided by Wikipedia: "Reverse engineering (RE) is the process of taking something (a device, an electrical component, a software program, etc.) apart and analyzing its workings in detail, usually with the intention to construct a new device or program that does the same thing without actually copying anything from the original."
The second mind-set is most concisely summarized by the reverse-engineering definition from the Canadian Geospatial Data Infrastructure: "Analyzing a product or other output of a process in order to determine how to duplicate the know-how which has been used to create a product or process."
You might think this is just an exercise in semantics. After all, most terms have multiple, sometimes even conflicting, definitions. Does it really matter exactly how reverse engineering is defined?
Yes, it does. In fact, it matters a whole lot. In this world of out-of-control patents, tight intellectual property controls and— most important—slippery software EULAs (end-user license agreements), the definition of reverse engineering will have a big impact on how developers can integrate with products and systems to build innovative new applications.
Developers and security researchers recently have had their work shut down or curtailed because a court found they had violated the no-reverse-engineering clauses so commonly found in EULAs.
Anyone who reads this column knows that I would prefer it if EULAs had no weight in court cases at all.
But if courts are going to take EULAs seriously, then we need to make sure that they use a definition of reverse engineering that will not put up hurdles to innovation.
Id like to see Wikipedias recent take become the de facto definition of reverse engineering and the one that courts would use in trying cases. The Wikipedia definition clearly states that reverse engineering involves digging deep into the code of an application—most likely by decompiling it and copying much of the functionality of it, and doing so most likely to copy and compete with the original application.
This is clearly the sleaziest and most damaging form of reverse engineering. Its one that doesnt involve innovation—or, at least, not any positive form of innovation.
If this were the definition that courts used when covering potential EULA infractions and other violations, software companies rights would be protected. But so, too, would innovation.
Its when the courts use the definition of reverse engineering espoused by the CGDI and others that we put innovation at risk. And its no coincidence that this definition is used most often.
By this definition, reverse engineering occurs when a user simply looks at an application and analyzes how it works, how it connects to other programs and processes, and how the other programs and processes connect to it. No code penetration is involved, no decompiling. And, usually, the goal isnt to copy an application but to integrate with it or look for potential problems in it.
By this definition, we reverse-engineer the Web every day, and enterprise software companies reverse-engineer a whole score of data center systems.
The problem is that this is the definition that software companies use to stop competition and cover their turf.
A security researcher notices that your application has a network port open that leaves it insecure? No problem: Accuse him or her of reverse engineering and violating a EULA.
A clever user has come up with a program that extends your system, and youre mad because you didnt think of it and want to do the same thing to get more cash from your users? Go get that reverse-engineering criminal!
From now on, lets all make a pact: Whenever you use the term "reverse engineering," make sure its in reference to the sleazy code-copying form of the practice and not to integration, analysis or just plain smart development.
Labs Director Jim Rapoza can be reached at email@example.com.