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

[Kevin Bowling <kevin.bowling@kev009.com>]

On Mon, Nov 11, 2024 at 6:55 PM Kevin Bowling <kevin.bowling@kev009.com> wrote:
>
> On Mon, Nov 4, 2024 at 8:14 PM Marc Rochkind <mrochkind@gmail.com> wrote:
> >
> > Just to repeat, because of a bunch of confused posts here: The breach of contract case was not about System V code in Linux. It was about non-AT&T code from System V derivatives (e.g., AIX, Dynix) into Linux. (The copyright case was completely different.) You may wonder why non-AT&T code from a System V derivative into LInux should be a legal issue. To find the answer you have to read the contract. If it sounds bonkers, then we can agree that the contract was bonkers.
>
> Marc,
>
> I want to thank you for disclosing your experience.  My own
> understanding of all this was basically whatever groklaw said and now
> that all the dust is settled it's easier to hear and consider what
> else was happening.
>
> Dynix was a BSD 4.2 derivative which would make a lot of the
> surrounding discussion in this thread appropriate.  Although with

It was hard to re-find an authority for the BSD root but thanks to
this list [1] which is a neat paper all around.  It also seems like by
the time it was called Dynix/ptx it was fully enmeshed with SysV not
unlike SunOS->Solaris.  Maintained a concept called "universes" which
altered the ABI and commands to suit BSD or SysV environments.

There's a great dump of information here
https://www.krsaborio.net/unix-scalability/index.html but it doesn't
go back far enough for Sequent.

[1] https://archive.org/details/1985-proceedings-summer-portland/page/254/mode/2up


> commercial OS there is no telling what kind of mixing went on, for
> instance Chalie has variously described the BSD and SysV mixing going
> on in AIX on this list and elsewhere.
>
> It is pretty clear that RCU in Linux was a direct teleport of the
> algorithms developed at Sequent but maybe the code underwent some
> intentional churn as Grog mentions of the JFS work (for the record the
> JFS in Linux is more affined to OS/2, the JFS1 and JFS2 in AIX is a
> little different than both).
>
> I wonder if at some point SCO scored an "own-goal" on both cases in
> essentially the same way that USL did where during discovery you find
> out that some legally dubious things happened in both directions.  It
> seems like they probably could have executed some kind of shakedown or
> at least a favorable situation with IBM had the stakes been lower, but
> the cases were both very wide reaching and burnt off whatever kinetic
> value was there into lawyer heat.
>
> Regards,
> Kevin
>
>
> > I don't know how strong the copyright case was. I didn't work on it.
> >
> > Marc
> >
> > On Mon, Nov 4, 2024 at 7:13 PM Warner Losh <imp@bsdimp.com> wrote:
> >>
> >>
> >>
> >> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy <lm@mcvoy.com> wrote:
> >>>
> >>> On Mon, Nov 04, 2024 at 06:35:30PM -0700, Warner Losh wrote:
> >>> > On Mon, Nov 4, 2024 at 6:09???PM Larry McVoy <lm@mcvoy.com> wrote:
> >>> >
> >>> > > The thing I never got a reasonable answer to was I found code in BSD that
> >>> > > was identical to code going back to at least V7.  Find bmap() in the UFS
> >>> > > code and then find the same in V7.  I might be wrong about V7, might be
> >>> > > 32V, might be V6.  I don't think it matters, it's the same in all of them.
> >>> >
> >>> >
> >>> > bmap() is the code that maps a logical block to a phsyical block,
> >>> > > I'm quite familiar with it because I rewrote it to bmap_write() and
> >>> > > bmap_read() as part of making UFS do extents:
> >>> > >
> >>> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf
> >>> > >
> >>> > > When all the lawsuits were going on, since I knew that code really well,
> >>> > > I went off and looked and the BSD code at that time had bit for bit
> >>> > > identical bmap() implementations.
> >>> > >
> >>> > > I never understood why BSD could claim they rewrote everything when they
> >>> > > clearly had not rewritten that.
> >>> > >
> >>> > > I've raised this question before and I just went and looked, bmap() has
> >>> > > changed.  I'm pretty sure I have Kirk's BSD source releases, if I do,
> >>> > > I'm 100% sure I can back up what I'm saying.  Not sure I care enough to
> >>> > > do so, it's all water under the bridge at this point.
> >>> > >
> >>> >
> >>> > The short answer is that ffs_bmap.c was one of the 70 files that had
> >>> > a AT&T copyright notice added to it as part of the AT&T vs Regents suit.
> >>> > By the time 4.4BSD had been released, the file had been substantially
> >>> > rewritten, but some traces of original AT&T code remained.
> >>>
> >>> Yeah, this is completely a false claim.  It was identical.  At least
> >>> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing
> >>> this out around then.
> >>
> >>
> >> 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very different. I checked before I posted. So what i said is not false. I literally had the code up side by side 20 minutes ago. It is definitely different though clearly related and derived a bit. That function is absolutely not 100% copied.
> >>
> >>> For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug fixed
> >>> BSD.  If there ever was a guy that wanted this to be true, it's me.
> >>> It's not true, BSD ripped off Bell Labs code, that's a fact.
> >>
> >>
> >> Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed a AT&T license, prior to the ancient Unix license to get that. So there was no claim to originality prior to 4.4. I didn't look at net/2 though.
> >>
> >> I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is on disk different than v7fs I don't expect it to be identical.
> >>
> >> Warner
> >
> >
> >
> > --
> > My new email address is mrochkind@gmail.com