Of course copyright and patents are different beasts, so this similarity is probably legally insignificant.
To me, it seems obvious that if the developer read the code that's getting replaced and reproduced its behavior to the T, by reading it and running it many times... that's the opposite of a clean room implementation. What do you think a dirty room implementation is then?
I'm not saying you are right or wrong, I'm not an IP attorney and I think IP is really boring. I can see how if a developer at a giant company rewrites open source X in Swift, C# or Golang in order to exploit it commercially, there could be a cathedral of opinions that would support, "Okay, this is what is meant by clean room." In the same way that BigCo developers work with their attorneys to file patents for ideas they saw elsewhere and didn't invent all the time. It's one of many possible beliefs about IP, and it can even thrive in reality, but it doesn't mean it is a correct one.
However I'm unaware of case law indicating that it's strictly necessary. If the final implementation differs enough from the original, no copyright infringement occurs and no one is going to sue anyone, so the steps taken to arrive at the new version are less relevant.
> Typically, a clean-room design is done by having someone examine the system to be reimplemented and having this person write a specification. This specification is then reviewed by a lawyer to ensure that no copyrighted material is included. The specification is then implemented by a team with no connection to the original examiners.
Without the disconnection between examiners and implementers, it's only slightly similar to a clean room. And we have new case law to consider: an API may be subject to copyright, and those unit tests are highly suspect under that lens.
It remains to be tested in court.
In this case caseysoftware clearly benefits from the GPL code that gets replaced. End users get no guarantees.
- I wrote unit tests for every single one of those functions to confirm/validate the behavior.
- Then I deleted all 900 lines of code and committed it.
- Then I wrote code to make the unit tests pass again.
It was painful but that kept it tightly scoped and I could "prove" the behavior hadn't changed AND that I didn't use the original code.
There's an argument that the unit tests could be a "derivative work" but they were not part of the original system, did not change or add functionality to the system, and did not impact its performance so we discounted that concern.
The more pressing was that - as an open source project - and the guy doing the audit, I had reviewed the GPL implementation and had access to it at any time. What helped me there is that I made a point of using more modern language constructs and patterns which improved the performance of those functions by 30-90% and I resolved a number of buggy edge cases and other problems so it was clearly "substantially different."
This was never tested in a lawsuit and do NOT take the above as a definitive solution.