9

Something I've been curious about, I looked it up and didn't find any straightforward answers. I've heard of clean room engineering where programmers don't look at the code at all of the software they want to reverse engineer, and instead observe the behaviors of that software and writes code that does it. But what if someone decompiled the software, getting code that isn't quite the same as the original code written and then wrote their own code that isn't quite the same as that? I would guess its illegal.

11
  • 3
    It's pretty certain the use conditions will exclude reverse engineering. Mar 29 at 18:42
  • 1
    What if it didn't prohibit it?
    – Oneechan69
    Mar 29 at 18:43
  • 2
    It would depend on the copyright laws in your jurisdiction. If you reverse engineer to create a competing product you may also fall foul of intellectual property rights. Mar 29 at 18:48
  • 6
    The code produced by the decompiler would almost certainly be considered a derived work, and creating this is protected by copyright.
    – Barmar
    Mar 29 at 22:08
  • 6
    I know the term "clean room engineering" as having two teams – one to reverse engineer a software to produce a specification, and another team building the new software from this specification, without having seen the software. Mar 30 at 21:11

3 Answers 3

22

If you look at a decompiled code and are influenced in how you write your code by the decompiled code, this is probably a "derivative work" of the original program and not just "reverse engineering" from the way that the computer program works.

Copyright for software protects the decompiled code that is written, as a literary work, and anything derived from that decompiled code is also protected. But copyright does not protect the functioning and ideas behind a particular piece of software. So, if you figure out how to do the same thing as a piece of software without looking at the decompiled code, it can't be a derivative work of the original software program.

In theory, you could look at the decompiled code and ignore it when writing your own code. But, in practice, this is impossible to prove unless your code is so completely different from the original that your code clearly wasn't derived from the original.

6
  • 9
    That is part of the reason for Chinese walls when re engineering. One group examines the source to write the specs and rundown. Another to make the code again, with no people from group 1 taking to them but for the spec sheet.
    – Trish
    Mar 30 at 8:39
  • 8
    @Trish I prefer to call that clean-room design / reverse engineering to drop the national connotation.
    – Ray
    Mar 30 at 16:15
  • 13
    The great wall of china is hardly a derogatory reference.
    – bmargulies
    Mar 30 at 18:19
  • 1
    @DonQuiKong No. "Sony Computer Entertainment v. Connectix Corporation, 203 F.3d 596 (2000) is a decision by the Ninth Circuit Court of Appeals which ruled that the copying of a copyrighted BIOS software during the development of an emulator software does not constitute copyright infringement, but is covered by fair use. The court also ruled that Sony's PlayStation trademark had not been tarnished by Connectix Corp.'s sale of its emulator software, the Virtual Game Station."
    – ohwilleke
    Mar 31 at 13:42
  • 4
    Also worth noting that if your solution happens to use any patented design features or algorithms (even if you rediscover those algorithms through your own ingenuity!), then a whole different set of rules applies besides copyright.
    – kaya3
    Apr 1 at 1:00
8

Commercial software licenses typically prohibit decompiling (and sometimes disassembling). So right off the bat, there's a likely a legal barrier before you even start writing code.

Some licenses specifically prohibit "reverse engineering".

I'm not a lawyer, but a one-time boss of mine is. Our team wrote software intended to be compatible with (and, in some cases, interchangeable with) a commercial product. He explained that reverse engineering has a narrower meaning in contract law (at least in the U.S.) than the general understanding of the term among software developers and other engineers.

If you have a black box, feed it crafted inputs, and study its outputs, you can figure out its behavior. Engineers call this reverse engineering. (My understanding is that some jurisdictions have explicit protections for this activity in the pursuit of compatibility. In the U.S., I believe it's implicitly allowed.)

Since the software license prohibited "reverse engineering" in the narrower sense, our team had a rule against using that term, even when we meant it in the general sense. Instead, we'd say "figure out." (There were other rules, too.)

True clean room engineering starts by having one team do the "figuring out" and documenting the behavior--essentially creating a requirements document. That document is passed to a second team who have never interacted with the original product nor had the opportunity to learn any proprietary information about it. The second team writes new software based exclusively on the document from the first team. This is (supposedly) the approach used to "clone" the IBM PC BIOS.

Summary:

  • Copy and tweak = copyright infringement

  • Decompile and write new code = probably a license violation, and risk of copyright infringement

  • "Figure out" and write new code = protected to some degree--if you're careful

  • Clean room = safest approach

Regardless of how careful you are, you can be accused of copyright infringement. That doesn't necessarily mean you'd lose in court, but it could be a resource intensive hassle.

Besides copyright law, there are also risks of patent infringement. If your clean room implementation happens to re-invent somebody else's patented technique, you're going to have a bad day. I think re-invention by a clean room team is evidence that the patent was not novel, but I doubt that's a good legal strategy.

2
  • How do you avoid entirely the risk from "re-inventing somebody else's patented technique?". Seems to imply that you need to know all patented techninques and still yet not being influenced by them.
    – D Duck
    Mar 31 at 10:01
  • 4
    @DDuck: That's an unavoidable risk with patents. And since damages are increased if you knowingly infringe on somebody else's patent, many tech companies implore their engineers to never read any patents. Sadly, keeping engineers in the dark about advancements in their fields is somewhat contrary to the intent of the patent system. Mar 31 at 13:58
6

The canonical example of what you're looking for is ReactOS. Here's how they do it:

For us in the US when you speak of clean-room reverse engineering it means that one person tears apart the implementation of a device, writes documentation and another reads that documentation and implements. Other countries do not require this invisible great wall of development and allow the same person that disassembles the interface to also write the replacement implementation.

1
  • 3
    Clean room or not, studying the implementation ("tear apart", "disassembling") rather than characterizing the device's behavior sounds risky. Also, the U.S. doesn't require clean room development, but it does give you a strong legal defense if accused of copyright infringement. Mar 31 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .