On 10/8/96, Greg Yukl wrote:
>
> Why would anyone bother to reverse engineer something except for
> commercial purposes? It's a lot of work -- possibly as much work
> or more as it was to create the original product. And, reverse
> engineering is a skill that takes considerable time and effort to
> learn. The time and effort spent is just not worth it unless you
> expect to make money from doing it.
- I reverse engineered significant portions of the Apple II
operating system in order to modify it to create a real-time
laboratory control system (back in my Psychology grad school
days). It took about a year, but I wouldn't have been able
to do my dissertation without this system. This was academic
research, not commercial.
- Several books have been published with titles like "Undocumented
DOS." There have been claims that Microsoft unfairly competes by
relying on undocumented features in its operating system and
windowing environment. These books describe some of the
undocumented features. I don't believe that Microsoft
intentionally acted unfairly in these matters, but I do think
that the books provided a public service. Was the research
effort that went into these books "commercial" or not? Should
the law ban this type of research and publication?
- If you buy a program that has the capability of importing data
from another program, how do you think that the developers of
the importing program figured out the file format? Sometimes
a software publisher will release details on its file format, but
often it will not. Yes, reverse engineering the file format
is a commercial use, but what is the public purpose served by
blocking customers' abilities to share their own data among
programs they have licensed?
- During development of a computer program, it is common to
encounter incompatibilities between the code you're writing
and a device, such as a particular type of printer or modem
or video card. To figure out what's wrong with your program,
you have to figure out how it's mis-interacting with that
device. To do so, you may well have to reverse engineer parts of
the device control program (the "driver") that came with the
device. In my experience, this might take as little as a day.
Again this is commercial use, but what public purpose
would be served by banning it?
- In general, interoperability (the ability of several programs to
work together) may require reverse engineering. Some
details necessary for successful interoperation may be deliberately
hidden by the publisher of one of the pieces of software or they
may be unavailable simply because the publisher hasn't gotten
around to writing down this information in a publishable form.
In modern operating systems (Mac, Win95) several programs run
simultaneously, sharing the computer's memory and devices and
passing data to each other. The harder we make it to achieve
interoperability (because of bans on reverse engineering), the
harder we make it for small companies to publish successful
products for these platforms.
- Publishers ship products with bugs. Often, the bugs are known
at the time of shipment. So, how does a licensor get a bug
fixed?
Yes, one can buy a service contract from the publisher (pay
the publisher money to fix the defects that it shouldn't have
shipped in the first place.) But there is no guarantee that
the publisher will fix the bugs you want fixed.
In fact, draft Article 2B says that a material breach of a
service contract doesn't count as a material breach of the
underlying license contract for the software. So you pay
for the software and for a service contract, but the program
doesn't work and the publisher won't fix the bug. So what
is a customer to do? In some cases, reverse engineering will
help a sophisticated customer assess the safety of a
workaround, or it will help the customer make a limited patch.
Yeah, sure, this is commercial, but why should customers be
barred from this?
_______________________________________________________________________
Cem Kaner, J.D., Ph.D. Attorney at Law
P.O. Box 1200 Santa Clara, CA 95052 408-244-7000
Author (with Falk & Nguyen) of TESTING COMPUTER SOFTWARE (2nd Ed, VNR)
This e-mail communication should not be interpreted as legal advice
or a legal opinion. The transmission of this e-mail communication
does not create an attorney-client relationship between me and you.
Do not act or rely upon law-related information in this communication
without seeking the advice of an attorney.
Received on Sun Oct 27 1996 - 14:27:01 GMT