Is that really clean-room, though? (Note that "clean-room" is not a term in US copyright law, it's just a technique that certain people hope results in a work that is not a derivative of whatever they're reimplementing.)
If I learn a pop song, and sing it and accompany myself on the piano, and someone else transcribes it, then two things are true: first, of course it will result in identical melodies and chord progressions, and second, of course (it seems to me) this is a derivative work and there's no way you can say its copyright is independent. On the other hand, if I learn a pop song, and then teach the fundamentals of songwriting to someone, and they write a song with a I-V-vi-IV progression with angsty lyrics about an estranged lover, no matter how much it resembles existing pop songs in intent, there's a much stronger argument for independent invention.
A "clean-room" approach to determine a specification where none exists is sound - e.g., if you're developing a driver for a piece of hardware which only has a proprietary driver, you can run the driver under instrumentation and see what it does, and then write your own driver that twiddles hardware in the same way but takes its own approach to implementation. A "clean-room" approach to determine internals feels less sound to me: if you're disassembling the code to determine structure layout and naming, aren't you really just transforming the code into an overly-detailed natural language representation, then back into code?
(To be clear, I don't know if this is what ReactOS does/did, I just think that this "clean-room" defense doesn't hold super strongly, or in other words, that if this is what ReactOS does/did, it can be true both that ReactOS believes they did a clean-room reimplementation and that it's an infringement of NT's copyrights, despite a lot of hard work by the ReactOS devs.)
>> From what I understand a lot of the kernel work was done by clean-room reverse engineering. One person decompiles and documents the system and another re-implements given the documentation.
> Is that really clean-room, though?
That is precisely the technique that Compaq used to reverse engineer the IBM PC BIOS. I'm sure it can be done in a legally risky way, but the fundamental technique has been quite well tested, legally speaking.
I don’t remember the details of the BIOS case. A BIOS responds kind of like hardware. You put values in a register, trigger an interrupt, and look at the result in another register. As I recall, the clean room implementation replicated the same behavior, which is permitted. But documenting the actual structure of the code, including variable names, and copying that is not clean room reverse engineering from the point of view of copyright law.
> If I learn a pop song, and sing it and accompany myself on the piano, and someone else transcribes it,
I hate bad analogies. A bad analogy just confuses the issue.
There's one and exactly one song called "Billie Jean", which was written, composed, and performed by Michael Jackson.
There are however a thousand different works relating the history of Michael Jackson's work with Quincy Jones in producing the song "Billie Jean" for the album Thriller.
So is there one and exactly one implementation of a Windows NT kernel, or is there a possibility there could be many different types of Windows NT kernel implementations?
So, if I sing a song with lyrics "Billie Jean is not my lover" with melody re-re-do-la-re-re-do-la, is it a different song because it was recorded by me? It is pretty clear in copyright law that my recording would infringe Michael Jackson's song.
What does "a Windows NT kernel" mean? Exposes the same interface? (Does Linux + WINE count?) Operates internally in the same way?
Maybe a better example is UNIX. Linux offers the same conceptual interface, but is neither binary-compatible with UNIX nor is implemented the same way. It is not UNIX, and does not infringe. NT, FreeBSD, and Solaris all have / had compatibility interfaces for Linux that are binary-compatible but wildly different internally. They also do not infringe. And no "clean-room" work was necessary to reach this state.
Clean room re-implementations have stood up to many court challenges through the years, and are interoperability is explicitly permitted under things like the DMCA.
Yes, many clean-room reimplementations have stood up to court challenges. But many non-clean-room reimplementations have stood up, too. My argument is that it's neither necessary nor sufficient, just loosely correlated, and clean-room is not inherently a defense. And in particular, my argument is that it matters whether the communication between the dirty and clean rooms is a specification of an interface, or a description of a reverse-engineered implementation.
And yes, interoperability is permitted - that's why I'm saying it seems fine to clean-room reimplement a driver to communicate with a specific device. You do not need to have the same internal structures and the same function names to achieve interoperability, and I think making that argument that the DMCA allows you to have the same internal code layout will be hard.
> You do not need to have the same internal structures and the same function names to achieve interoperability
That might be the case for interoperability with a hardware device, but you probably do to make an operating system that's compatible with Windows software and drivers, considering how historically brazen developers are at abusing internal details of Windows. Consider virus scanners that happily patch internal data structures like the SSDT, or other programs that detour a bunch of API functions, then expect those functions to be called in a specific order when a different API function is called, or programs that just reach into stack frames they don't control and pluck out values[1]. (There are some other good ones in that link.) Windows takes pains to be compatible with insane programs like this, so you could argue that copying weird implementation details like this is necessary for interoperability.
Considering IBM couldn't stop Compaq after taking some pretty good steps, it has been legal for a while. Without clean room re-implementations we would have no PC clone industry.
If I learn a pop song, and sing it and accompany myself on the piano, and someone else transcribes it, then two things are true: first, of course it will result in identical melodies and chord progressions, and second, of course (it seems to me) this is a derivative work and there's no way you can say its copyright is independent. On the other hand, if I learn a pop song, and then teach the fundamentals of songwriting to someone, and they write a song with a I-V-vi-IV progression with angsty lyrics about an estranged lover, no matter how much it resembles existing pop songs in intent, there's a much stronger argument for independent invention.
A "clean-room" approach to determine a specification where none exists is sound - e.g., if you're developing a driver for a piece of hardware which only has a proprietary driver, you can run the driver under instrumentation and see what it does, and then write your own driver that twiddles hardware in the same way but takes its own approach to implementation. A "clean-room" approach to determine internals feels less sound to me: if you're disassembling the code to determine structure layout and naming, aren't you really just transforming the code into an overly-detailed natural language representation, then back into code?
(To be clear, I don't know if this is what ReactOS does/did, I just think that this "clean-room" defense doesn't hold super strongly, or in other words, that if this is what ReactOS does/did, it can be true both that ReactOS believes they did a clean-room reimplementation and that it's an infringement of NT's copyrights, despite a lot of hard work by the ReactOS devs.)