[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[Noel Chiappa]

    > From: Warner Losh

    >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote:

    >> The bmap implementations I saw were bit for bit identical, same code,
    >> same variables, same style, same indentation. I'm 100% sure they were
    >> not independent.

    > They are different in 4.3BSD. They are different in 4.2BSD (but less
    > different). The underlying filesystems are different on disk, so they
    > routines have to be different.

That last sentence points out something important that people need to remember
in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD
switched to the BSD Fast File System, so I very much doubt that the low-level
(i.e. logical file block to disk block) file system code in anything after
4.1A looks much like the AT+T low-level file system code. (I have no idea how
the BSD code compares to the Linux file system code, but that's between the
Linux people, and Berkeley.)

	Noel

[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[ron minnich]

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

I keep wondering if this assertion of code difference or lack thereof can
be tested. Are not all these sources available? Which bits are missing?

On Tue, Nov 5, 2024 at 9:55 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Warner Losh
>
>     >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote:
>
>     >> The bmap implementations I saw were bit for bit identical, same
> code,
>     >> same variables, same style, same indentation. I'm 100% sure they
> were
>     >> not independent.
>
>     > They are different in 4.3BSD. They are different in 4.2BSD (but less
>     > different). The underlying filesystems are different on disk, so they
>     > routines have to be different.
>
> That last sentence points out something important that people need to
> remember
> in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD
> switched to the BSD Fast File System, so I very much doubt that the
> low-level
> (i.e. logical file block to disk block) file system code in anything after
> 4.1A looks much like the AT+T low-level file system code. (I have no idea
> how
> the BSD code compares to the Linux file system code, but that's between the
> Linux people, and Berkeley.)
>
>         Noel
>

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

[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[Warner Losh]

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

On Tue, Nov 5, 2024 at 10:55 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Warner Losh
>
>     >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote:
>
>     >> The bmap implementations I saw were bit for bit identical, same
> code,
>     >> same variables, same style, same indentation. I'm 100% sure they
> were
>     >> not independent.
>
>     > They are different in 4.3BSD. They are different in 4.2BSD (but less
>     > different). The underlying filesystems are different on disk, so they
>     > routines have to be different.
>
> That last sentence points out something important that people need to
> remember
> in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD
> switched to the BSD Fast File System, so I very much doubt that the
> low-level
> (i.e. logical file block to disk block) file system code in anything after
> 4.1A looks much like the AT+T low-level file system code. (I have no idea
> how
> the BSD code compares to the Linux file system code, but that's between the
> Linux people, and Berkeley.)
>

Yes. The original unix code was copied and redone somewhat. It was still
likely
a derivative work (which is why AT&T forced Berkeley to redo it for
4.4-lite), but
it was like 25% the same, 25% similar but functionally identical and 50%
new for
UFS, but filesystem layout is file system layout and some similarities
persisted.
3bsd added dtofsb() calls. 4bsd added code to make accessing the indirect
blocks
more reliable and made writing directories more reliable.  4.1 was
identical to 4bsd.
4.2 changed a lot. the 32V bmap was 112 lines long, while 4.2 was 196 lines
with
the following diffstat:
 1 file changed, 141 insertions(+), 57 deletions(-)
So by this measure, over half of the new function was new (though most of
the
comments were still the same). It did have the same structure, but
structure isn't
necessarily copyrightable since filesystem layout code will be similar
between
filesystems that are write-in-place. Looking at the diff, there's one
stretch of 15
lines that are identical, but otherwise there's changes (mostly additions)
every
few lines. A substantial re-write. These days, most open source authors
would
replace the copyright statement with their own for such an extensive rewrite
since the diff was over 2x the size of the original file (another very
imperfect
measure). Though the comments remaining identical is troublesome because
they are the parts of the code that are the most creative and subject to the
most freedom while the for loops and such are largely dictated by the
problem
or C language and customary style.

Between 4.2 and 4.3, the changes were around the edges of this function
though not in this function (I was remiss in not chasing down the bare diff
I did last night). By net.2 it was re-written again, moving most of the
function
of bmap elsewhere, so that almost nothing remained from the original 32V
in the original bmap function (though a quick grep shows that parts did move
elsewhere). In net.2 it's back down to 75 lines. shorter even than in 32V
(but
it's a bit deceptive since the code was elsewhere, though also largely
reworked).
diff reports only lines '{', '}', '/*', '*/' and a few simple assignments
(bap = bp->b_un.b_daddr;) and function calls (brelse(bp)) being the same and
all the comments different / gone from this function. Though a fair number
of
the diffs were due to changes in the "buffer cache" interface, some
formatting
changes and some substitution of #defines (like NIADDR) for bare constants
(3
in this case). These changes were also due to the role of bmap being reduced
and things like balloc being used to handle the details a fair bit
differently. And
bits of balloc do resemble bits of the original bmap, but again the
structure
had changed somewhat.

The numbers for my diffs and such are based on Krik's disks, but can also
be tested by looking at the links I posted earlier or downloading and
extracting
the sources from the TUHS archive.

The bmap() function I've extracted from different versions:

https://people.freebsd.org/~imp/pmap/pmap.32v
https://people.freebsd.org/~imp/pmap/pmap.4.2
https://people.freebsd.org/~imp/pmap/pmap.4.3
https://people.freebsd.org/~imp/pmap/pmap.net.2

Warner

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

[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[Warner Losh]

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

On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich@gmail.com> wrote:

> I keep wondering if this assertion of code difference or lack thereof can
> be tested. Are not all these sources available? Which bits are missing?
>

Yes. Great question.

https://people.freebsd.org/~imp/pmap/pmap.32v
https://people.freebsd.org/~imp/pmap/pmap.4.2
https://people.freebsd.org/~imp/pmap/pmap.4.3
https://people.freebsd.org/~imp/pmap/pmap.net.2

has the functions as I extracted them for the diff numbers I posted before.
The TUHS archive links
are at:

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/subr.c
https://www.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/src/sys/sys/subr.c
https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/sys/ufs_bmap.c
https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/sys/sys/ufs_bmap.c
https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/
src/sys/ufs/ufs/ufs_bmap.c

in case anybody wants to check my math or characterizations about the
differences.

Warner


> On Tue, Nov 5, 2024 at 9:55 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
> wrote:
>
>>     > From: Warner Losh
>>
>>     >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote:
>>
>>     >> The bmap implementations I saw were bit for bit identical, same
>> code,
>>     >> same variables, same style, same indentation. I'm 100% sure they
>> were
>>     >> not independent.
>>
>>     > They are different in 4.3BSD. They are different in 4.2BSD (but less
>>     > different). The underlying filesystems are different on disk, so
>> they
>>     > routines have to be different.
>>
>> That last sentence points out something important that people need to
>> remember
>> in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD
>> switched to the BSD Fast File System, so I very much doubt that the
>> low-level
>> (i.e. logical file block to disk block) file system code in anything after
>> 4.1A looks much like the AT+T low-level file system code. (I have no idea
>> how
>> the BSD code compares to the Linux file system code, but that's between
>> the
>> Linux people, and Berkeley.)
>>
>>         Noel
>>
>

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

[TUHS] Copyrights and copying.. [was SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)]

[Christian Hopps]

> On Nov 5, 2024, at 18:58, Warner Losh <imp@bsdimp.com> wrote:

…

> These days, most open source authors would
> replace the copyright statement with their own for such an extensive rewrite
> since the diff was over 2x the size of the original file (another very imperfect
> measure). Though the comments remaining identical is troublesome because
> they are the parts of the code that are the most creative and subject to the
> most freedom while the for loops and such are largely dictated by the problem
> or C language and customary style.


This was interesting to me. I’ve been writing various open source for 20+ years and I think maybe I was given a much stricter rule to follow when I started out and which I’ve followed since — it may very well be wrong but it’s what I’ve followed.

If I started with some code with a copyright at the top, and I rewrote every line I would not replace the copyright but add mine to the file. I was told this was the correct action b/c you aren’t allowed to use the previous code as an aide to writing your new code and consider it only your own, it’s derivative in that case.

Maybe this is just overly careful, but it’s what I’ve done in all my projects (starting back in the 90s with NetBSD and on to contributing to many other open source projects over time).

Thanks,
Chris.

[TUHS] Re: Copyrights and copying.. [was SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)]

[Warner Losh]

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

On Tue, Nov 5, 2024, 1:25 PM Christian Hopps <chopps@chopps.org> wrote:

>
>
> > On Nov 5, 2024, at 18:58, Warner Losh <imp@bsdimp.com> wrote:
>
> …
>
> > These days, most open source authors would
> > replace the copyright statement with their own for such an extensive
> rewrite
> > since the diff was over 2x the size of the original file (another very
> imperfect
> > measure). Though the comments remaining identical is troublesome because
> > they are the parts of the code that are the most creative and subject to
> the
> > most freedom while the for loops and such are largely dictated by the
> problem
> > or C language and customary style.
>
>
> This was interesting to me. I’ve been writing various open source for 20+
> years and I think maybe I was given a much stricter rule to follow when I
> started out and which I’ve followed since — it may very well be wrong but
> it’s what I’ve followed.
>
> If I started with some code with a copyright at the top, and I rewrote
> every line I would not replace the copyright but add mine to the file. I
> was told this was the correct action b/c you aren’t allowed to use the
> previous code as an aide to writing your new code and consider it only your
> own, it’s derivative in that case.
>

If you rewrote everything, that's an original work. There's nothing in
copyright law that talks about process only the end result. While it is
nice to leave yhe original copyright, it's not necessary when there's no
original material left. And there is some incentive to remove it because
you don't want to incorrectly represent who has IP in the file.

Maybe this is just overly careful, but it’s what I’ve done in all my
> projects (starting back in the 90s with NetBSD and on to contributing to
> many other open source projects over time).
>

Yea. While many would replace the copyright for the scenario I described,
many would add their copyright. It's a judgment call: are the changes
transformative to the work or not? There are several creators that take old
Disney film footage and legally remox it into something new. The original
is clearly there, but changed enough to be outside copyright protection.
Sadly, there are no simple, universal rules that let you do this analysis
completely mechanically.

Warner

Thanks,
> Chris.

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

[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[Warner Losh]

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

On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd@gmail.com> wrote:

> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp@bsdimp.com> wrote:
> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich@gmail.com> wrote:
> >> I keep wondering if this assertion of code difference or lack thereof
> can be tested. Are not all these sources available? Which bits are missing?
> >
> > Yes. Great question.
> >
> > https://people.freebsd.org/~imp/pmap/pmap.32v
> > https://people.freebsd.org/~imp/pmap/pmap.4.2
> > https://people.freebsd.org/~imp/pmap/pmap.4.3
> > https://people.freebsd.org/~imp/pmap/pmap.net.2
>
> Hmm; these all 404 for me?


 Doh! Too much muscle memory. Those should all be bmap:

https://people.freebsd.org/~imp/bmap/bmap.32v
<https://people.freebsd.org/~imp/pmap/pmap.32v>
https://people.freebsd.org/~imp/bmap/bmap.4.2
<https://people.freebsd.org/~imp/pmap/pmap.4.2>
https://people.freebsd.org/~imp/bmap/bmap.4.3
<https://people.freebsd.org/~imp/pmap/pmap.4.3>
https://people.freebsd.org/~imp/bmap/bmap.net.2
<https://people.freebsd.org/~imp/pmap/pmap.net.2>

which shows the progression before the rewrite in 4.4BSD-lite.

Warner

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

[TUHS] Fwd: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[Warner Losh]

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

---------- Forwarded message ---------
From: Warner Losh <imp@bsdimp.com>
Date: Fri, Nov 8, 2024 at 3:17 PM
Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of
SCO)
To: David Barto <barto@kdbarto.org>




On Fri, Nov 8, 2024 at 1:07 PM David Barto <barto@kdbarto.org> wrote:

>
>
> On Nov 8, 2024, at 12:27 PM, Warner Losh <imp@bsdimp.com> wrote:
>
>
>
> On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd@gmail.com> wrote:
>
>> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp@bsdimp.com> wrote:
>> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich@gmail.com> wrote:
>> >> I keep wondering if this assertion of code difference or lack thereof
>> can be tested. Are not all these sources available? Which bits are missing?
>> >
>> > Yes. Great question.
>> >
>> > https://people.freebsd.org/~imp/pmap/pmap.32v
>> > https://people.freebsd.org/~imp/pmap/pmap.4.2
>> > https://people.freebsd.org/~imp/pmap/pmap.4.3
>> > https://people.freebsd.org/~imp/pmap/pmap.net.2
>>
>> Hmm; these all 404 for me?
>
>
>  Doh! Too much muscle memory. Those should all be bmap:
>
> https://people.freebsd.org/~imp/bmap/bmap.32v
> <https://people.freebsd.org/~imp/pmap/pmap.32v>
> https://people.freebsd.org/~imp/bmap/bmap.4.2
> <https://people.freebsd.org/~imp/pmap/pmap.4.2>
> https://people.freebsd.org/~imp/bmap/bmap.4.3
> <https://people.freebsd.org/~imp/pmap/pmap.4.3>
> https://people.freebsd.org/~imp/bmap/bmap.net.2
> <https://people.freebsd.org/~imp/pmap/pmap.net.2>
>
> https://people.freebsd.org/~imp/bmap/bmap.32v
https://people.freebsd.org/~imp/bmap/bmap.4.2
https://people.freebsd.org/~imp/bmap/bmap.4.3
https://people.freebsd.org/~imp/bmap/bmap.net.2

Not sure why the previous...

Warner

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

[TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)

[rob]

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

I went to one of the SCO forum events at Santa Cruz at the time and I vaguely remember someone having a chat to use and saying that the dispute was that SCO and IBM were working on project Monterey and some of the SCO SMP code found its way into Linux.

At the time SCO felt that Linux was several years behind on SMP so getting the SMP code would remove the SCO advantage at a time when processors were getting more cores. This may have been more to do with the IBM -vs- SCO contract case.

Regards, Rob.

> On 8 Nov 2024, at 23:18, Warner Losh <imp@bsdimp.com> wrote:
> 
> 
> 
> ---------- Forwarded message ---------
> From: Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>>
> Date: Fri, Nov 8, 2024 at 3:17 PM
> Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)
> To: David Barto <barto@kdbarto.org <mailto:barto@kdbarto.org>>
> 
> 
> 
> 
> On Fri, Nov 8, 2024 at 1:07 PM David Barto <barto@kdbarto.org <mailto:barto@kdbarto.org>> wrote:
> 
> 
>> On Nov 8, 2024, at 12:27 PM, Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>> 
>> 
>> 
>> On Fri, Nov 8, 2024, 6:20 AM Dan Cross <crossd@gmail.com <mailto:crossd@gmail.com>> wrote:
>> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh <imp@bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich <rminnich@gmail.com <mailto:rminnich@gmail.com>> wrote:
>> >> I keep wondering if this assertion of code difference or lack thereof can be tested. Are not all these sources available? Which bits are missing?
>> >
>> > Yes. Great question.
>> >
>> > https://people.freebsd.org/~imp/pmap/pmap.32v <https://people.freebsd.org/~imp/pmap/pmap.32v>
>> > https://people.freebsd.org/~imp/pmap/pmap.4.2 <https://people.freebsd.org/~imp/pmap/pmap.4.2>
>> > https://people.freebsd.org/~imp/pmap/pmap.4.3 <https://people.freebsd.org/~imp/pmap/pmap.4.3>
>> > https://people.freebsd.org/~imp/pmap/pmap.net.2 <https://people.freebsd.org/~imp/pmap/pmap.net.2>
>> 
>> Hmm; these all 404 for me?
>> 
>>  Doh! Too much muscle memory. Those should all be bmap:
>> 
>> https://people.freebsd.org/~imp/bmap/bmap.32v <https://people.freebsd.org/~imp/pmap/pmap.32v>
>> https://people.freebsd.org/~imp/bmap/bmap.4.2 <https://people.freebsd.org/~imp/pmap/pmap.4.2>
>> https://people.freebsd.org/~imp/bmap/bmap.4.3 <https://people.freebsd.org/~imp/pmap/pmap.4.3>
>> https://people.freebsd.org/~imp/bmap/bmap.net.2 <https://people.freebsd.org/~imp/pmap/pmap.net.2>
> https://people.freebsd.org/~imp/bmap/bmap.32v <https://people.freebsd.org/~imp/bmap/bmap.32v>
> https://people.freebsd.org/~imp/bmap/bmap.4.2 <https://people.freebsd.org/~imp/bmap/bmap.4.2>
> https://people.freebsd.org/~imp/bmap/bmap.4.3 <https://people.freebsd.org/~imp/bmap/bmap.4.3>
> https://people.freebsd.org/~imp/bmap/bmap.net.2 <https://people.freebsd.org/~imp/bmap/bmap.net.2>
> 
> Not sure why the previous...
> 
> Warner


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