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 26454 invoked from network); 8 Sep 2022 22:28:08 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2022 22:28:08 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 2057B422BF; Fri, 9 Sep 2022 08:27:34 +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 17CD5422BC for ; Fri, 9 Sep 2022 08:27:29 +1000 (AEST) Received: by mail-vs1-f50.google.com with SMTP id 129so11428621vsi.10 for ; Thu, 08 Sep 2022 15:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=QfnovvSbmNOZPHKeaC0GRxvbomEags53upIlP8rNp+Y=; b=LTdI/b206mAo16jpOMfJWrcJjjbqPlGwIaQwNcYZQmW068e2K4lBfzu2gaN2QLAqe/ lGi5p61WLenUtaJyKrnSgUnqEspTNkg/U6OhNFMJC1o/3Gl8s66yYjpQ78869H+nRp2S XlEpVlIYWyhgSKPxsLcsp10PggMg+8jAMhsbpHgCGRvMeg8z+DfIzx/2lTSaf+40jfl8 7HHmMSLpDDhKZhKMzzfpbWJztOvRTu31Y4u4VaZBAzhp9yoV/ouFz2HWPU3PbWxJCCnK WozTgOyYARQXHrBniDxQ3rzuneLo+t9m/mfb9KEzZ110rBb2c85q+jsb3ATOdBz9djEX hYhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=QfnovvSbmNOZPHKeaC0GRxvbomEags53upIlP8rNp+Y=; b=ikAzE3a7gkph03Kt6MDjGm8Qmu2g3F5XsO8P9n/px3EAXO3x/XEfUm6tXiwO2jjAZU lBM1sjnoNcvpxMTyjXOXwnAVuA86+jPzB8IOw/GgSBl0K2ahrNsuaB5MZfKQrxpYqzzQ G1/aH1GQmR1ASrWRSFtVW5ShCXEONhgieQ1SI21oQ4CukqGxJSztD6fUHddShH75wZTp wXUT0uhaK68El2C7W6pasGExmmzMlXIPx25F+P2p9e1m7FtkZRmpsuu/lAq9mh64M1sB VlaPQ7Ytood0MH4tSTSLo2odBE0xzoqEiQYM6/Iv7Raqj7+bepu6aoZXU+mnPTM+BqxX 9mvQ== X-Gm-Message-State: ACgBeo3NUyvuBhROtUm7uslyoq2cHkUdrbbDhgiA1gJAyR1t9qD74SIZ 0hYrfjeEME4+tRreXm+y9fcfESI3goTwCkQxSIx4jMwJboJLnw== X-Google-Smtp-Source: AA6agR5NcYMI/klSgTI9MY4mPegfWVyx6QtuQZZmIO4XZRnPo0a+GBwjok2e4znREJny93L/GGyvwH8D8PRxPzt88hs= X-Received: by 2002:a05:6102:38c6:b0:390:e7e4:8a7e with SMTP id k6-20020a05610238c600b00390e7e48a7emr4068743vst.38.1662675988224; Thu, 08 Sep 2022 15:26:28 -0700 (PDT) MIME-Version: 1.0 References: <20220908221639.GR11929@mcvoy.com> In-Reply-To: <20220908221639.GR11929@mcvoy.com> From: Warner Losh Date: Thu, 8 Sep 2022 16:26:17 -0600 Message-ID: To: Larry McVoy Content-Type: multipart/alternative; boundary="000000000000a7b3c505e831eb97" Message-ID-Hash: 4SIO6QXMN5RMJKWXQXMMEOKPDXLX4PRY X-Message-ID-Hash: 4SIO6QXMN5RMJKWXQXMMEOKPDXLX4PRY X-MailFrom: wlosh@bsdimp.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 CC: segaloco , TUHS 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: --000000000000a7b3c505e831eb97 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 8, 2022 at 4:16 PM Larry McVoy wrote: > On Thu, Sep 08, 2022 at 05:50:37PM -0400, Clem Cole wrote: > > > 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. > > And it's a false claim. Go look at the Bell Labs bmap() and the BSD > bmap(), the last time I looked they were bit for bit identical. > Yea, this was part of the de minimis copying that was acknowledged... It was mostly rewritten with most of AT&T's code gone. It's 110 lines of code, out of ~18,000 lines of kernel code. And the structure in 4.4BSD is somewhat different with balloc() being completely different than the rest of V7's subr.c. > I looked there because I split bmap() into bmap_read() and bmap_write() > because the read path is trivial and the write path is quite a bit more > difficult (this was all for the work srk imagined, and I did, to get > rid of the rotational delays). So I was pretty familiar with that > code path and as of about 20 years ago, well past 4.4BSD, bmap() was > unchanged from either v7 or 32v. > But it likely didn't matter, since 32v likely lost its copyright protection due to AT&T distributing too many copies without the required copyright markings. At least that was the preliminary ruling that caused the suit to be settled... AT&T didn't want it finalized, though the cat was somewhat out of the bag at this point... > The weird thing is it isn't that hard to write something that would > walk the code and find other examples. Nobody seemed to care. > Yea, most of the rest of the code around it was rewritten, but not that. Warner --000000000000a7b3c505e831eb97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Sep 8, 2022 at 4:16 PM Larry = McVoy <lm@mcvoy.com> wrote:
On Thu, Sep 08, 2022 = at 05:50:37PM -0400, Clem Cole wrote:
> > 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.=C2=A0 =C2=A0It was rewri= tten over time,
> which replaced AT&T's implementation.=C2=A0 Which is all that = was ever claimed.

And it's a false claim.=C2=A0 Go look at the Bell Labs bmap() and the B= SD
bmap(), the last time I looked they were bit for bit identical.

Yea, this was part of the de minimis copying that = was acknowledged...
It was mostly rewritten with most of AT&T= 's code gone. It's 110 lines of code,
out of ~18,000 line= s of kernel=C2=A0code. And the structure in 4.4BSD is somewhat
di= fferent with balloc() being completely different than the rest of V7's = subr.c.
=C2=A0
I looked there because I split bmap() into bmap_read() and bmap_write()
because the read path is trivial and the write path is quite a bit more
difficult (this was all for the work srk imagined, and I did, to get
rid of the rotational delays).=C2=A0 So I was pretty familiar with that
code path and as of about 20 years ago, well past 4.4BSD, bmap() was
unchanged from either v7 or 32v.

But it= likely didn't matter, since 32v likely lost its copyright protection d= ue
to AT&T distributing too many copies without the required = copyright markings.
At least that was the preliminary ruling that= caused the suit to be settled...
AT&T didn't want it fin= alized, though the cat was somewhat out of the bag
at this point.= ..
=C2=A0
The weird thing is it isn't that hard to write something that would
walk the code and find other examples.=C2=A0 Nobody seemed to care.

Yea, most of the rest of the code around it wa= s rewritten, but not that.

Warner=C2=A0
--000000000000a7b3c505e831eb97--