[TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)
Marc Rochkind
mrochkind at gmail.com
Fri Nov 8 06:59:18 AEST 2024
Ron, there were two cases, copyright and breach-of-contract. I worked on
the latter, and no publicized "evidence," such as that from Darl McBride,
was relevant. My understanding is that all evidence in the copyright case
was discovered by the technical experts working on their own, and that they
didn't take anything from McBride either.
All that stuff from McBride and the selling of licenses was something that
the SCO corporation did, not anything that the lawyers working on the
actual cases had anything to do with. The Linux community reacted, and it
seems still does, to this McBride stuff. It didn't react to the court
cases, although it thought it did, because the evidence was sealed.
As I said in earlier posts here recently, the breach-of-contract case
wasn't about AT&T code in Linux. It was about IBM- (or Sequent-) written
code in Linux. The contract said that IBM was not allowed to put anything
from AT&T-licensed OSes into Linux, even if what was put into Linux was
from IBM additions to an OS licensed from AT&T.
Somebody here likened this to the GPL, in the sense that if you add
anything to a GPL-licensed thing, the whole thing, including your stuff, is
covered by the GPL. I don't know enough about the GPL to say for sure that
that's actually how the GPL works.
Marc
On Thu, Nov 7, 2024 at 1:41 PM ron minnich <rminnich at gmail.com> wrote:
> So as I read your comment, Marc, it seems to me that , e.g., Larry's
> claims about bmap, right or wrong, are not germane to this case?
>
> On Thu, Nov 7, 2024 at 8:02 AM Marc Rochkind <mrochkind at 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.
>>
>> 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 at bsdimp.com> wrote:
>>
>>>
>>>
>>> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy <lm at 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 at 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 at gmail.com <mrochkind at gmail.com>*
>>
>
--
*My new email address is mrochkind at gmail.com <mrochkind at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20241107/21ccfb50/attachment.htm>
More information about the TUHS
mailing list