Comment by geofft
7 years ago
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.
[1]: https://devblogs.microsoft.com/oldnewthing/20031223-00/?p=41...