> In addition, when Dennis would talk about Coherent and his evaluation of the source code, he said he used the known to him, but not widely known bugs in Unix to try to catch copying. If there was copying, those would be copied. If it was freshly implemented, there's a high likelihood that they wouldn't. His conclusion was that someone had access to a lot of knowledge about the Unix system given the fidelity of the implementation, but the lack of bugs and novel ways of doing it suggested independent implementation.

Both Coherent and 4.4BSD have stuck out to me as examples of not-quite-so-clean-room implementations that did well enough (more than enough for BSD) and didn't die a fiery death in litigation (as much as USL tried...).  What I find interesting is that in this day and age, it seems there is almost a requirement for true "clean-room" implementation if something is going to be replicated, which I understand to mean the team developing the new implementation can't be the same team that performed a detailed analysis of the product being reimplemented, but the latter team can produce a white paper/writeup/memorandum describing the results of their analysis and the development team can then use that so long as it doesn't contain any implementation details.

I've always wondered how cleanly that sort of thing can actually be proven and enforced, and I've always thought back to the Coherent situation as an almost model example.  Where proving copying outright can be difficult, knowing one's own product well enough to know the bugs that are incredibly obscure but also reliably consistent is a great way to peg a faithful recreation vs. a flat out copy job.  That said, my assumption with complete UNIX re-implementations is that folks at least had access to the manuals, perhaps had used UNIX before in some capacity.  I would assume the current definition of a clean-room implementation only requires that the developers/implementors don't have access to the code of the parent product (source or reverse engineered), but could read manuals, study behavior in-situ, and use that level of "reverse engineering" to extract the design from the implementation, so not knowing the gritty details, Coherent could be a true clean-room.

BSD is a different beast, as they were literally replacing the AT&T source code before their eyes, so there isn't much argument that can be made for 4.4BSD being a "clean-room" implementation of UNIX.  Simply for compatibility and upgrade-ability of existing systems, they had to be incredibly accurate to the original design.  Given that, that's one of the more surprising things to me about 4.4BSD prevailing in the lawsuit, because while Berkeley could easily prove that they had replaced most of AT&T's code, there's still the fact that their team did have complete and unfettered access to Bell UNIX code at least circa 32V.  Not sure if the licensing allowed for source-code cross-talk between USG/USL UNIX source and Berkeley, but I remember reading somewhere that CSRG students and faculty avoided commercial UNIX like the plague, going so far as to not even look at the literature to see what changes occurred since 32V.

Anywho just some thoughts, I find the realm of reverse engineering and re-implementation fascinating, and am always interested in this sort of discussion.

- Matt G.

P.S. Don't want to derail the thread with this, unless it's deemed worthy addition, but feel free to email privately.  Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler produced by Bell?  I know there was one floating around the "user maintained" utilities at some point, I recall seeing a note in a manual saying something to the effect "Rumor has it there is a PDP-11 disassembler" but I'm curious if such tools were ever provided in any sort of official capacity.  I've been doing some research on what RE tools people had on hand at the time, think "objdump" from GNU binutils.