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.