This post originated from an RSS feed registered with Java Buzz
by Norman Richards.
Original Post: The ethics of decompilation
Feed Title: Orb [norman richards]
Feed URL: http://members.capmac.org/~orb/blog.cgi/tech/java?flav=rss
Feed Description: Monkey number 312,978,199
On the Apple java-dev list, an industrious young programmer posted
about how he was curious how a certain piece of commercial code works
and decided to decompile the code. Of course there was the larger
issues of what he developer planned to do with the code and why he
didn't just ask the developer (apparently this was a small "shareware"
product of sorts). However, a large portion of the debate came from
people ardently condemning decompilers as evil.
Is there anything (ethically) wrong with decompiling commercial
software? No. A decompiler should be a standard tool of ANY
senior level Java developer. Decompilation has been a necessity on
the Java projects I've worked on. I've written about the
extreme arrogance of obfuscation and a how I feel you are doing
your users an extreme disservice my obfuscating code. I can
understand why people might be insecure about their code (usually lack
of quality and lack of any true intellectual property), and so I
suppose I can understand why some people shiver at the thought that
their code might be decompiled. But, decompilers have saved me so
many times that there is no doubt in my mind about whether or not
decompilation is a good thing.
The primary use of a decompiler is understanding why the code that
you are using is broken. I know every vendor wants to believe they
sell solid, well-architected products and that if something should
happen to be wrong that they have knowledgable support staff who can
quickly help you out. But it is simply not true. Most commercial
code (especially Java products developed during the boom) is
hacked together barely functional garbage. Even if you've managed
to steer clear of the the bottom of the barrel companies, chances are you
are using code the it is exceptionally buggy.
I worked with a popular object persistence framework at a prior
company. They did a good job for the most part and they tried to put
out good documentation and they provided reasonable, but slow,
service. However, the object persistence framework was so fundamental
to our product that we simply could not risk depending on their
support to diagnose our problems. (we even had a multi-million dollar
contract with the company in question) The only sensible thing to do
for the more urgent problems was to decompile the code and locate the
problem in parallel to their support team. Whether the problem was on
our end or was bug deep down in their product, we usually found the
problem more quickly and could either fix it or guide their support
team to the real problem so they could get a patch out.
We also had a problem with a popular app server a few years ago.
The servlet engine had a problem with doing jsp includes that containted
a relative path name. We submitted the bug several time, but they never
managed to fix the problem. It wasn't critical to us since we could work
around the problem. Eventually, I was bored enough to decompile that
code. It took me all of 10 minutes to find the bug in their code. I passed
the information along to our support contact. I hope they finally fixed the
problem in the product. I had moved on to other projects before I had
a chance to find out.
I can't count the number of times I have needed look inside a
third party library that was silently eating exceptions or look into
the code to understand how a poorly documented API call works. It
would be nice if everything worked. It would be nice if everything
was documented. It would be nice if companies would truly care about
their customers and provide source code. Until then, I don't go
anywhere without a decompiler close to my side.
Previous Topic
