Clean room reverse engineering

Marc Whipple MWhipple at itsgames.com
Fri Dec 4 22:50:35 UTC 2009


David Woolley wrote:

> Marc Whipple wrote:

>> In any event, the concept of "reverse engineering" copyrighted material 
>> is nonsensical under US law (and the law of many other countries.) If 
>> you had enough access to it to reverse engineer it, you didn't make a 
>> new work, you copied an old one. If your new work otherwise is 

> IANAL, but as I understand it there is a limited right to  do white box 
> reverse engineering in the EEC.  It is a lot more limited than is 
> generally assumed in open source circles, and would not extend to 
> reproducing internal behaviours.

>>(removed some specifics)

> Clean room is often used to refer to re-implementing something for which 
> the source code is actually available, or for black box reverse 
> engineering, where you examine the external behaviour of the software in 
> response to external inputs.

[Marc Whipple] Does this perhaps equate to, say, trying to make a World of Warcraft *server* by observing what the World of Warcraft *client* does when it tries to communicate?  Because then I could sort of understand the idea. My impression of what someone would do to "reverse engineer a commercial computer game" was that the idea was to end up with a "copy" of the game without actually reading the code for it. Since you don't, theoretically, have access to a World of Warcraft *server's* code, it would make a lot more sense to talk about reverse engineering it and getting a result which is not a "copy." It doesn't necessarily have to look or act anything like a real WOW server behind the input/output stream, it just has to give the same input/output when communicating.

To the player a game, to a large extent, *is* its "internal behaviors." Almost everything that materially distinguishes Generic Fantasy Plot RPG A from Generic Fantasy Plot RPG B is potentially copyrightable and not really subject to IP defeat through reverse engineering. (Or, more generally, any kind of independent development of functionality.) Not that a game doesn't need a good interface, consistent resource management system, etc, and lots of other functionalities which aren't copyrightable. But a game with great IP and crappy functionality is potentially a great game: a game with great functionality and crappy IP is almost certainly a crappy game. I don't see why you'd want to reverse engineer a crappy game. :)

M



More information about the License-discuss mailing list