The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: Re-implementations/Clean-Rooms et al.
@ 2022-09-08 21:50 Clem Cole
  2022-09-08 22:16 ` Larry McVoy
  2022-09-08 22:17 ` Warner Losh
  0 siblings, 2 replies; 12+ messages in thread
From: Clem Cole @ 2022-09-08 21:50 UTC (permalink / raw)
  To: segaloco, TUHS

[-- Attachment #1: Type: text/plain, Size: 8490 bytes --]

On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> 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...).

Be careful with that statement both parts of it are not wholly on target.
In the first, AT&T chose not to litigate against Coherent fully.  As was
pointed out, Dennis and the team that examined the code base determined it
was 'clean enough.'     If I recall, his comment was something like "It was
clear they had seen and had access to the AT&T IP at some point, most
likely at University (IIRC many of the founders were ex-University
Waterloo), but they did not find evidence of direct copying of files."

BSDi/UCB *vs. *USL was a different kettle of fish altogether.   As has been
discussed here extensively (and needs not to be repeated), that suit was
about *Trade Secrets and >>ideas<< that make up what we call UNIX.*   The
real interesting thing about that case is that had USL/AT&T won, the
repercussions for the industry would have been way beyond just BSDi - *but
all of the UNIX clones* and many of us on this list who had been "mentally
contaminated" with AT&T's ideas (I still have my 'mental contamination'
button somewhere in my archives).

The good news is that the US courts had the good sense to realize that the
moment the US Gov put the consent decree down in 1956 and required that
AT&T make their IP available and then enabled AT&T had its people start to
write about their work in the open literature (in UNIX's case the original
CACM paper, but continuing with all the books, follow on papers, etc), plus
being such wonderfully active participants in the research community at
large, it could not be called a secret.



> 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.
>
It's not "day and age" it's from the original case law -- the term was
coined by the late Arthur Kahn, Esquire who was the lead attorney for
Franklin Computers, Inc in the Franklin *vs.* Apple Case - which he
originally won and ultimately lost on appeal [Good guy BTW, particularly
for a non-technically trained person - he 'got it'].   The concept is that
one group is in a dirty room and the other in a clean room.  Information is
unidirectional.   The dirty room can read published documentation, probe,
and test the device/implementation using standard programming techniques.
 And then write a new document that describes the functionality of the
device in question.  Then hand it to the folks in the clean room who can
reimplement a device to that new specification.

The point of contention in the case is if *the original documentation for
the device*, in this case, the Apple Assembler listing for Wos's Apple-II
ROMs were protected by copy once they had been transformed from their
printed form in Apple;'s red books into the binary and stored in the ROMS
themselves.

Franklin's 'dirty room' ultimately wrote a series of test programs that
demonstrated each of the externally available locations and entries in the
ROMs. This they documents and their new clean-room programmers wrote a new
set of ROM that duplicated the functionality.  IIRC the story is that
Franklin ROMs were a few bytes smaller in the end.  Compaq would later the
same scheme for the IBM PC.



>  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.
>
Be careful here. I used to work for a firm that did a lot of work for
different vendors that would build some of these clean-room sub-systems (in
fact for some of the folks --  at least one -- of the readers of this
list).   We were always careful for the clean-room people to be ones we
were fairly sure had not seen that customers product previously.   I was
almost always on the 'dirty' team in many of those projects because I was
so contaminated with the IP of so many of our customers' work.   Because we
worked for IBM, Sun, DEC, HP, DG, AT&T, *etc*. all at the same time had
their IP in-house we had very strict rules about how things were handled.
Even what sites and what sub-nets data could be on -- which system admins
had the passwords.  No one person had access to all of the passwords. We
had a locked safe for each customer with secure things like passwords
(really) and rooms with locks and videos, and access doors.   It was really
serious stuff.

Frankly, I think part of why we got some of the "work for hires" tasks was
because those firms trusted us to handle their IP properly.  No way did we
want to contaminate something accidentally.  Some projects like our big TNC
[Transparent Network Computing] system we were working on for all of IBM,
DEC, HP, and Intel simultaneously -- 4 different teams.  The architects
could talk to each other, and we talked about common issues, but it was a
different code.  I know we implemented things a couple of times - although
we got smarter.   For instance, the original RPC marshaling was done for
IBM with 'the awk script from hell' which later became an interface
generator that all four teams used.



>
> 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.

It was not a clean-room as Arthur defined it.   It was rewritten over time,
which replaced AT&T's implementation.  Which is all that was ever claimed.




>  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.

I expect this is because you don't quite understand what happened.



>  but I remember reading somewhere that CSRG students and faculty avoided
> commercial UNIX like the plague,

Hmmm, I read it on the Internet -- it must be true ;-)

CSRG had Ultrix/VAX, SunOS/3, and I believe HP-UX/PA sources. They shipped
several DEC-developed drivers in 4.1A/4.1B/4.1C -- Sam, Bill Shanon, and I
tested a couple of them on one of my machines in Cory Hall as DEC has
donated one of the 3 CAD machines [UCBCAD - a.k.a. 'coke' ], and it was the
only 'pure' DEC machine on campus - without any 3rd party HW in it.  After
I graduated, I suspect Sam continued the relationship with Tom Quarles, so
4.2BSD was likely tested on that system too.  But I know the RH-based TAPES
and DISKs were all straight from Shannon's SCCS Ultrix repo as he sent them
to me to try before I gave them to Sam.


>  Does anyone know if there was a "formal" PDP-11 and/or VAX disassembler
> produced by Bell?

Most of the compiler kits have disassemblers, as do many debuggers -- what
are you asking?



>  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.
>
In the mid/late-70s (*i.e.* V6/V7 time frame) there are a couple of them --
where to start -- V7 has one inside of adb, and if I recall later versions
of PCC2 has one.  But if you look in the USENIX tapes you can find a couple
of pretty well-adorned ones.   There was one that IIRC was done by ??Cooper
Union?? guys that spit out DEC MACRO-11 syntax for the Harvard assembler.
That should be on the TUHS archives.   Thinking about it,  Phil Karn had
one too that did some interesting label patch-up IIRC - which I think he
brought with him to CMU from somewhere -- but I may be miss remembering
that.

[-- Attachment #2: Type: text/html, Size: 12990 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-09-09  2:17 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-08 21:50 [TUHS] Re: Re-implementations/Clean-Rooms et al Clem Cole
2022-09-08 22:16 ` Larry McVoy
2022-09-08 22:26   ` Warner Losh
2022-09-08 22:28     ` Warner Losh
2022-09-08 23:30     ` Steve Nickolas
2022-09-08 23:42       ` Warner Losh
2022-09-09  0:05         ` Steve Nickolas
2022-09-09  0:17           ` Larry McVoy
2022-09-09  0:52             ` Steve Nickolas
2022-09-09  2:16               ` Larry McVoy
2022-09-08 23:34   ` Clem Cole
2022-09-08 22:17 ` Warner Losh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).