From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22010 invoked from network); 8 Sep 2022 21:52:32 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2022 21:52:32 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 50A01422A8; Fri, 9 Sep 2022 07:52:09 +1000 (AEST) Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) by minnie.tuhs.org (Postfix) with ESMTPS id AA5F2422A3 for ; Fri, 9 Sep 2022 07:52:04 +1000 (AEST) Received: by mail-vs1-f50.google.com with SMTP id c3so19716060vsc.6 for ; Thu, 08 Sep 2022 14:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=ceusbA8suJa+RyS6peV9Wo5ld/PNGTnr8/AFF+XQDPg=; b=R1qtjdayx9hrA/fd7jp+AXag86/zCDLdupWBxv/wkh6w0VH3UIi1zmky3+g9d+v2oK DTgc0BpsywQX0ckbkjaB97XtRI0wkGWujt1bO4Bc06gFIrnne9hmPXg0roObUt0qAM9n tozM0fF13xjxkSxP19fnYSPF19ZqvERw9C6iQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=ceusbA8suJa+RyS6peV9Wo5ld/PNGTnr8/AFF+XQDPg=; b=2qzfmUnFnsci6+CQcyvCKEPmznMj03wbjJwUwEg6c8FvTiWDKQFlUdorkNsORVuan3 aisifq4TVx0ZdfndcML/0jg5vrrSotlyRtrAMnnHHF1lIlKn6E7EkXbrHOhEDXaHlGQ0 vb++SqGeFsgCU2W6k+KI6dgBtg69muqUVeDH7+eTE1nmEGWiz4Men9zIXmOuK8nbvaxV 9o/CziDJGECvz4UpTiTugaz6xKMcFGNpRqAo7Lc8vDUkz1uWnLjPTjQRof3UtR2VQA2F HcFFucq/Nxs1L/ojRfkgUc6JbHk+4H1oScKONRR69XIhPVvcvSUR6mwZW67U+M+2i9q3 LlVQ== X-Gm-Message-State: ACgBeo3zcR+cOBR03c81Opc/ahGioOYLKNZqNcZqTUWWmBw4NTLTWIF5 t9axhAagpepXzxFIlLTzPzcIetAWNFroX7VAUi+pE9/tzlrqOQ== X-Google-Smtp-Source: AA6agR7+dMnMofgiqt1cDUdXk8MlzG0qpLqgdA/1OaPkEeIhQXudHjhtAZxmJux+bWXa//VLsAZ73cx1o1bHFo68koU= X-Received: by 2002:a67:1586:0:b0:398:1076:8fd5 with SMTP id 128-20020a671586000000b0039810768fd5mr3434516vsv.47.1662673863675; Thu, 08 Sep 2022 14:51:03 -0700 (PDT) MIME-Version: 1.0 From: Clem Cole Date: Thu, 8 Sep 2022 17:50:37 -0400 Message-ID: To: segaloco , TUHS Content-Type: multipart/alternative; boundary="00000000000005ad3e05e8316dc2" Message-ID-Hash: QOIOM5ITLQJ5KFCBQUQNWF2RTPI772BT X-Message-ID-Hash: QOIOM5ITLQJ5KFCBQUQNWF2RTPI772BT X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Re-implementations/Clean-Rooms et al. List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000005ad3e05e8316dc2 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 8, 2022 at 12:51 PM segaloco via TUHS 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. --00000000000005ad3e05e8316dc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 8, 2022 at 12:51 PM se= galoco via TUHS <tuhs@tuhs.org> = wrote:
Both Coherent= and 4.4BSD have stuck out to me as examples of not-quite-so-clean-room imp= lementations that did well enough (more than enough for BSD) and didn't= die a fiery death in litigation (as much as USL tried...).=C2=A0
Be careful with that statement bo= th parts of it are not wholly on target.=C2=A0 In the first, AT&T chose= not to litigate against Coherent fully.=C2=A0 As was pointed out, Dennis a= nd the team that examined the=C2=A0code base determined it was 'clean e= nough.'=C2=A0 =C2=A0 =C2=A0If 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=C2=A0(IIRC many of the founders were ex-Un= iversity Waterloo), but they did not find evidence of direct copying of fil= es."

BSDi/UCB vs. USL was a different kettle of fish al= together.=C2=A0 =C2=A0As has been discussed here extensively (and needs not= to be repeated), that suit was about=C2=A0Trade Secrets a= nd >>ideas<< that make up what we call UNIX.=C2=A0 =C2= =A0The 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 ha= d been "mentally contaminated" with AT&T's ideas (I still= have my 'mental contamination' button somewhere in my archives).

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

=C2=A0
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 an= alysis of the product being reimplemented, but the latter team can produce = a white paper/writeup/memorandum describing the results of their analysis a= nd 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 ca= se 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'].= =C2=A0 =C2=A0The concept is that one group is in a dirty room and the other= in a clean room.=C2=A0 Information is unidirectional.=C2=A0 =C2=A0The dirt= y room can read published documentation, probe, and test the device/impleme= ntation using standard programming techniques.=C2=A0 =C2=A0And then write a= new document that describes the functionality of the device in question.= =C2=A0 Then hand it to the folks in the clean room who can reimplement a de= vice to that new specification.

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

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

=C2=A0
=C2=A0I would assume the current definition of a clean-room implementatio= n only requires that the developers/implementors don't have access to t= he code of the parent product (source or reverse engineered), but could rea= d manuals, study behavior in-situ, and use that level of "reverse engi= neering" 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 --=C2=A0 at le= ast one -- of the readers of this list).=C2=A0 =C2=A0We were always careful= for the clean-room people to be ones we were fairly sure had not seen that= customers product previously.=C2=A0 =C2=A0I was almost always on the '= dirty' team in many of those projects because I was so contaminated wit= h the IP of so many of our customers' work.=C2=A0 =C2=A0Because we work= ed for IBM, Sun, DEC, HP, DG, AT&T, etc. all at the same time ha= d their IP in-house we had very strict rules about how things were handled.= =C2=A0 Even what sites and what sub-nets data could be on -- which system a= dmins had the passwords.=C2=A0 No one person had access to all of the passw= ords. We had a locked safe for each customer with secure things like passwo= rds (really) and rooms with locks and videos, and access doors.=C2=A0 =C2= =A0It was really serious stuff.

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

=C2=A0
=

BSD is a different beast, as they were literally replacing the AT&T sou= rce code before their eyes, so there isn't much argument that can be ma= de for 4.4BSD being a "clean-room" implementation of UNIX.=C2=A0<= /font>
It was not a clean-room = as Arthur defined it.=C2=A0 =C2=A0It was rewritten over time, which replace= d AT&T's implementation.=C2=A0 Which is all that was ever claimed.<= /font>


=C2=A0
=C2=A0Given that, that= 's one of the more surprising things to me about 4.4BSD prevailing in t= he lawsuit, because while Berkeley could easily prove that they had replace= d most of AT&T's code, there's still the fact that their team d= id have complete and unfettered access to Bell UNIX code at least circa 32V= .
I expect this is beca= use you don't quite understand what happened.

=C2=A0
=C2=A0but 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 tru= e ;-)
=C2=A0
CSRG had Ultrix/VAX, SunOS/3, and I believe HP-UX/PA sources. They shi= pped several DEC-developed drivers in 4.1A/4.1B/4.1C -- Sam, Bill Shanon, a= nd 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.=C2=A0 After I graduated, I suspect Sam continued the relationship= with Tom Quarles, so 4.2BSD was likely tested on that system too.=C2=A0 Bu= t 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.
=C2=A0
=C2=A0Does anyone know if there was a &q= uot;formal" PDP-11 and/or VAX disassembler produced by Bell?=C2=A0
Most of=C2=A0the compiler = kits have disassemblers, as do many debuggers -- what are you asking?=C2=A0

=C2= =A0
=C2=A0saying something to the effect "Rumor has it there is a = PDP-11 disassembler" but I'm curious if such tools were ever provi= ded in any sort of official capacity.
In the mid/late-70s (i.e. V6/V7 time frame) there= are a couple of them=C2=A0-- where to start -- V7 has one insid= e of adb, and if I recall later versions of PCC2 has one.=C2=A0 But if you = look in the USENIX tapes you can find a couple of pretty well-adorned ones.= =C2=A0 =C2=A0There was one that IIRC was done by ??Cooper Union?? guys that= spit out DEC MACRO-11 syntax for the Harvard assembler.=C2=A0 That should = be on the TUHS archives.=C2=A0 =C2=A0Thinking about it,=C2=A0 Phil Karn had= one too that did some interesting label patch-up IIRC - which I think he b= rought with him to CMU from somewhere -- but I may be miss remembering that= .
--00000000000005ad3e05e8316dc2--