You know, I've always had one question about "cleanroom" work. The person in the cleanroom knows what the output is supposed to be, so how clean is the cleanroom really?

For instance, if I said I wanted to write a sorting algorithm, then I would know that my goal is to sort some data. I might come up with a novel way of doing that, or I might come up with one that has already been written. Either way, I have the goal in mind.

No one is going to really care unless I come up with a novel method that is somehow better than the other versions, sure, but then when you extrapolate that idea to something like, "I want to make an open source version of <extremely popular proprietary tool>" then I know that I am attempting to emulate 1 to 1 that tool.

Just because I cannot read their source code, does that actually separate my work from their work in a meaningful way? What happens if my code and their code is somewhat identical? Where is the dividing line that prevents them from shutting me down the way Nintendo shuts down Switch Emulation software?

> The person in the cleanroom knows what the output is supposed to be, so how clean is the cleanroom really?

Very, this is the entire point. If you only know an input/output mapping, then you don't know the internals of the original product. Your implementation is "clean" wrt that potentially proprietary knowledge. You use the two-room approach (one team in a dirty room seeing potentially proprietary information, one in the cleanroom with only the spec) to ensure that segregation of knowledge for your future legal defense. This lets you make the case, in court, that any duplication from the original to the "clone" (or whatever) product is just coincidental, or the consequence of standard design choices.

If you don't use this approach, you don't have that cover, and you have essentially no defense if copying is found.

Remember, the main point of this is the legal defense.