A federal court ruling last week in the case of Blizzard v. BnetD has dismayed fair use, free software, and consumer rights advocates alike by upholding a prohibition on reverse engineering in the license agreements of a software game publisher. A number of terrific weblogs have already appeared analyzing the court's decision, the frightening way it uses the DMCA's anti-circumvention provision, the threat it poses to open source software programmers, and the loss of fair use rights it implies for consumers in general. It's such a bad decision on so many fronts it's hard to know where to begin.

But at least this unmitigated disaster gives me added impetus to do something I've been meaning to do anyway, which is to have a more general discussion on the topic of reverse engineering. After I published my EULA comparison of Adobe and Autodesk usage limitations, a number of readers wrote to ask why I felt Adobe's more permissive term still deserved demerits. "Why is the prohibition on reverse engineering a bad thing?" wrote one reader. "I thought that to be a method of protecting intellectual property."

I'm not sure how it is that reverse engineering has gotten such a bad rep in recent years, with so many people seeming to have the impression that it's an evil act. But certainly part of the problem is that different people can mean very different things when they use the term. In the mechanical and chip design worlds, courts have endorsed many forms of reverse engineering as being necessary to encourage innovation and a competitive marketplace. Reverse engineering of software often involves decompiling the object code, but not necessarily. And while copyright law explicitly allows reverse engineering for purposes of achieving interoperability, it clearly doesn't permit the outright copying of disassembled code to create a competing product. Between those two poles are innumerable forms of reverse engineering that are not illegal under copyright law but are not explicitly sanctified by it either.

So when a EULA says you can't reverse engineer a software program, what does it mean? Well, it means you can't do anything that the software publisher might call reverse engineering unless you can prove it was for interoperability purposes. And proving that might require you to go court, as it did for the BnetD defendants. Which in turn means you run the risk of getting a judge who feels that the "defendants in this case waived their 'fair use' right to reverse engineer by agreeing to the licensing agreement."

The paradox here is that, while virtually all software EULAs contain a prohibition against reverse engineering, virtually all software companies practice reverse engineering of one form or another themselves. It's not just a matter of interoperability - it's a necessity to stay competitive. And it's a necessity for a society that wants to see innovative products that work better than the old standard. Hey, if Blizzard v. BnetD was an established precedent a few decades ago, we'd probably all be using WordStar and VisiCalc on Xerox Windows.

And what kind of system would they be running them on? The PC industry itself was born by an act of reverse engineering: Compaq's cloning of the original IBM PC BIOS. It's hard to imagine how something similar could happen in the incredibly restrictive legal environment we now have in this country. Technology only progresses when those with new ideas can build upon the existing standards. Our courts seem determined to guarantee that such progress can only be made somewhere outside the US of A.