[TUHS] RIP Darl McBride former CEO of SCO

[TUHS] RIP Darl McBride former CEO of SCO

[Will Senn]

It happened in September, apparently, but is only now making the rounds. 
Darl McBride, known for taking everybody and his brother to court over 
stolen code, has passed away.

https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-and-nobody-notices/

I actually remember liking SCO back in the day, before the company 
leadership went dark-side. These days, we get to play with ancient unix 
cuz of their license. What a topsy turvy world.

Is there a concise summary of the SCO suits and fallout out there? I've 
seen a lot on the AT&T side of things, but other than having lived 
through it, I've not seen much on what eventually happened and why it 
all sort of just dissappeared.

Will

[TUHS] Re: RIP Darl McBride former CEO of SCO

[Greg 'groggy' Lehey]

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

On Sunday,  3 November 2024 at 19:17:03 -0600, Will Senn wrote:
> It happened in September, apparently, but is only now making the rounds.
> Darl McBride, known for taking everybody and his brother to court over
> stolen code, has passed away.
>
> https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-and-nobody-notices/

Oh.  As you say, RIP.

> I actually remember liking SCO back in the day, before the company
> leadership went dark-side. These days, we get to play with ancient unix cuz
> of their license.

Yes.  SCO really changed between 2002 and 2003.

> Is there a concise summary of the SCO suits and fallout out there? I've seen
> a lot on the AT&T side of things, but other than having lived through it,
> I've not seen much on what eventually happened and why it all sort of just
> dissappeared.

Not quite what you're looking for, but at the time I kept quite a bit
of information at http://www.lemis.com/grog/SCO/

It's a bit of a mess, and a lot of the links have atrophied, but some
of it could be interesting.  Potentially the reference to BSD code in
the fossforce article could be related to
http://www.lemis.com/grog/SCO/code-comparison.php

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: RIP Darl McBride former CEO of SCO

[Wesley Parish]

I've just checked, and ibiblio has retained the Groklaw blog, static 
now, over the past few years. It was perhaps the best dissection of the 
case from a legal point of view:

http://groklaw.ibiblio.org/

http://groklawstatic.ibiblio.org/articlesonly.php

though it seems that only the last pages have in fact made it to 
ibiblio. You may have to browse the Wayback Machine for the earlier ones.

Wesley Parish

On 4/11/24 15:31, Greg 'groggy' Lehey wrote:
> On Sunday,  3 November 2024 at 19:17:03 -0600, Will Senn wrote:
>> It happened in September, apparently, but is only now making the rounds.
>> Darl McBride, known for taking everybody and his brother to court over
>> stolen code, has passed away.
>>
>> https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-and-nobody-notices/
> Oh.  As you say, RIP.
>
>> I actually remember liking SCO back in the day, before the company
>> leadership went dark-side. These days, we get to play with ancient unix cuz
>> of their license.
> Yes.  SCO really changed between 2002 and 2003.
>
>> Is there a concise summary of the SCO suits and fallout out there? I've seen
>> a lot on the AT&T side of things, but other than having lived through it,
>> I've not seen much on what eventually happened and why it all sort of just
>> dissappeared.
> Not quite what you're looking for, but at the time I kept quite a bit
> of information at http://www.lemis.com/grog/SCO/
>
> It's a bit of a mess, and a lot of the links have atrophied, but some
> of it could be interesting.  Potentially the reference to BSD code in
> the fossforce article could be related to
> http://www.lemis.com/grog/SCO/code-comparison.php
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php

[TUHS] Re: RIP Darl McBride former CEO of SCO

[Marc Rochkind]

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

Many opinions of the evidence, especially on Groklaw, but also elsewhere,
including here. But none of these people offering opinions have really seen
the evidence, which has been sealed. Mostly people talk about "evidence "
offered by Darl at the start. But NONE of the actual evidence came from
him. It was researched by a team of expert witnesses on both sides, of
which I was one.

On Mon, Nov 4, 2024, 8:23 AM Wesley Parish <wobblygong@gmail.com> wrote:

> I've just checked, and ibiblio has retained the Groklaw blog, static
> now, over the past few years. It was perhaps the best dissection of the
> case from a legal point of view:
>
> http://groklaw.ibiblio.org/
>
> http://groklawstatic.ibiblio.org/articlesonly.php
>
> though it seems that only the last pages have in fact made it to
> ibiblio. You may have to browse the Wayback Machine for the earlier ones.
>
> Wesley Parish
>
> On 4/11/24 15:31, Greg 'groggy' Lehey wrote:
> > On Sunday,  3 November 2024 at 19:17:03 -0600, Will Senn wrote:
> >> It happened in September, apparently, but is only now making the rounds.
> >> Darl McBride, known for taking everybody and his brother to court over
> >> stolen code, has passed away.
> >>
> >>
> https://fossforce.com/2024/11/once-linuxs-biggest-enemy-darl-mcbride-dies-and-nobody-notices/
> > Oh.  As you say, RIP.
> >
> >> I actually remember liking SCO back in the day, before the company
> >> leadership went dark-side. These days, we get to play with ancient unix
> cuz
> >> of their license.
> > Yes.  SCO really changed between 2002 and 2003.
> >
> >> Is there a concise summary of the SCO suits and fallout out there? I've
> seen
> >> a lot on the AT&T side of things, but other than having lived through
> it,
> >> I've not seen much on what eventually happened and why it all sort of
> just
> >> dissappeared.
> > Not quite what you're looking for, but at the time I kept quite a bit
> > of information at http://www.lemis.com/grog/SCO/
> >
> > It's a bit of a mess, and a lot of the links have atrophied, but some
> > of it could be interesting.  Potentially the reference to BSD code in
> > the fossforce article could be related to
> > http://www.lemis.com/grog/SCO/code-comparison.php
> >
> > Greg
> > --
> > Sent from my desktop computer.
> > Finger grog@lemis.com for PGP public key.
> > See complete headers for address and phone numbers.
> > This message is digitally signed.  If your Microsoft mail program
> > reports problems, please read http://lemis.com/broken-MUA.php
>

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

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

[Greg 'groggy' Lehey]

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

On Monday,  4 November 2024 at 10:35:40 -0700, Marc Rochkind wrote:
> Many opinions of the evidence, especially on Groklaw, but also
> elsewhere, including here. But none of these people offering
> opinions have really seen the evidence,

I think that depends on what SCO (and when) claimed as evidence.  They
did present slides of obfuscated code (replacing ASCII with Greek
letters in the assumption that nobody could recognize the original and
maybe that the code was too precious to show in the orignal).  I can't
find that any more, and maybe its on one of the many dead links on
http://www.lemis.com/grog/SCO/.  But
http://www.lemis.com/grog/SCO/code-comparison.php refers to it and
identifies the errors in the claims.

> Mostly people talk about "evidence " offered by Darl at the
> start. But NONE of the actual evidence came from him. It was
> researched by a team of expert witnesses on both sides, of which I
> was one.

I'd be very interested to hear what else they presented.  Did your
conclusions agree with mine?

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Marc Rochkind]

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

By evidence, I mean evidence that was part of the legal case(s). Material
presented as a part of a marketing, sales, or public relations effort is
not evidence in this sense. I don't know what Darl McBride and SCO were
doing here, as I didn't work on that and only met Darl for 30 sec. (He came
over to say hello to me in a conference room, and then the lawyers came
over and told him to get away from me, for fear that he would pollute the
waters. I worked extensively with his brother, Kevin.) My understanding is
that SCO was trying to get money from Linux licenses of some sort. The
Linux community freaked out.

There were two principal legal cases. The first alleged copyright
infringement in the development of Linux. I'm not sure who exactly was
being sued, since I didn't work on this case. People tended to think that
"Linux" was being sued, but I don't think there was any such entity like
that. The second case, which I worked on, was about breach of contract
between IBM and AT&T, and SCO I guess took on the rights and obligations of
AT&T. This second case was extraordinarily complicated and, inasmuch as
most everything about it was sealed, Groklaw and people in general never
did understand what the issues were. Which, of course, didn't serve as an
impediment for them offering up opinions about it. This second case started
about 2005 and ended about two or three years ago, so it went on for about
15 years. The copyright case I think ended when it was determined that the
copyrights in question didn't belong to SCO.

The way the copyright case ended doesn't mean that Linux development didn't
violate copyrights. I'm pretty sure that it did, based on conversations
with a friend of mine who was a technical expert on that part of the case.
One might ask, how could Torvalds and all those Linux developers violate
System V copyrights since they had never seen System V code? The answer is
that corporations such as IBM also contributed to Linux, and those
corporations did have such access.

If one wants to take all this seriously and differentiate between what one
knows to be true, on the one hand, and what one thinks is true or wants to
be true, on the other hand, then I think one would realize that nobody
outside of the legal teams knows anything about the case. As I said, I know
a whole lot about part of the case(s) and next to nothing about the other
parts. Groklaw used to reprint redacted documents that had been released by
the court, a couple of which I wrote, but ignored the fact that they were
redacted and that all the juicy parts were missing. Generally, if anything
was important, it was sealed.

I just a few minutes ago glanced at the Wikipedia article "SCO–Linux
disputes" and it's not bad. It does pretty much explain the breach of
contract case. There is a section titled "IBM code in Linux" that lists
some technologies (e.g., JFS, RCU), and that's the area that I worked on. I
wrote a program that could in effect do a "diff" on entire operating
systems, hundreds of thousands of lines of code. It was amazing to see the
results. Even the attorneys who were doing the suing were amazed. (Whether
all my discoveries represented actual breach of contract is a legal
question, not a technical one, and was therefore well outside the scope of
my work.)

Marc

On Mon, Nov 4, 2024 at 3:50 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Monday,  4 November 2024 at 10:35:40 -0700, Marc Rochkind wrote:
> > Many opinions of the evidence, especially on Groklaw, but also
> > elsewhere, including here. But none of these people offering
> > opinions have really seen the evidence,
>
> I think that depends on what SCO (and when) claimed as evidence.  They
> did present slides of obfuscated code (replacing ASCII with Greek
> letters in the assumption that nobody could recognize the original and
> maybe that the code was too precious to show in the orignal).  I can't
> find that any more, and maybe its on one of the many dead links on
> http://www.lemis.com/grog/SCO/.  But
> http://www.lemis.com/grog/SCO/code-comparison.php refers to it and
> identifies the errors in the claims.
>
> > Mostly people talk about "evidence " offered by Darl at the
> > start. But NONE of the actual evidence came from him. It was
> > researched by a team of expert witnesses on both sides, of which I
> > was one.
>
> I'd be very interested to hear what else they presented.  Did your
> conclusions agree with mine?
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

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

[Warner Losh]

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

On Mon, Nov 4, 2024 at 5:06 PM Marc Rochkind <mrochkind@gmail.com> wrote:

> By evidence, I mean evidence that was part of the legal case(s). Material
> presented as a part of a marketing, sales, or public relations effort is
> not evidence in this sense. I don't know what Darl McBride and SCO were
> doing here, as I didn't work on that and only met Darl for 30 sec. (He came
> over to say hello to me in a conference room, and then the lawyers came
> over and told him to get away from me, for fear that he would pollute the
> waters. I worked extensively with his brother, Kevin.) My understanding is
> that SCO was trying to get money from Linux licenses of some sort. The
> Linux community freaked out.
>
> There were two principal legal cases. The first alleged copyright
> infringement in the development of Linux. I'm not sure who exactly was
> being sued, since I didn't work on this case. People tended to think that
> "Linux" was being sued, but I don't think there was any such entity like
> that. The second case, which I worked on, was about breach of contract
> between IBM and AT&T, and SCO I guess took on the rights and obligations of
> AT&T. This second case was extraordinarily complicated and, inasmuch as
> most everything about it was sealed, Groklaw and people in general never
> did understand what the issues were. Which, of course, didn't serve as an
> impediment for them offering up opinions about it. This second case started
> about 2005 and ended about two or three years ago, so it went on for about
> 15 years. The copyright case I think ended when it was determined that the
> copyrights in question didn't belong to SCO.
>
> The way the copyright case ended doesn't mean that Linux development
> didn't violate copyrights. I'm pretty sure that it did, based on
> conversations with a friend of mine who was a technical expert on that part
> of the case. One might ask, how could Torvalds and all those Linux
> developers violate System V copyrights since they had never seen System V
> code? The answer is that corporations such as IBM also contributed to
> Linux, and those corporations did have such access.
>

Everybody on the internet has had "access" to System V code (or almost any
mainstream Unix source code) since the mid to late 90s. None of it was
likely legal access, but it was and still is findable with google or other
search engines. But it does make similar looking things a muddier option if
you assume ill intent and deception.


> If one wants to take all this seriously and differentiate between what one
> knows to be true, on the one hand, and what one thinks is true or wants to
> be true, on the other hand, then I think one would realize that nobody
> outside of the legal teams knows anything about the case. As I said, I know
> a whole lot about part of the case(s) and next to nothing about the other
> parts. Groklaw used to reprint redacted documents that had been released by
> the court, a couple of which I wrote, but ignored the fact that they were
> redacted and that all the juicy parts were missing. Generally, if anything
> was important, it was sealed.
>
> I just a few minutes ago glanced at the Wikipedia article "SCO–Linux
> disputes" and it's not bad. It does pretty much explain the breach of
> contract case. There is a section titled "IBM code in Linux" that lists
> some technologies (e.g., JFS, RCU), and that's the area that I worked on. I
> wrote a program that could in effect do a "diff" on entire operating
> systems, hundreds of thousands of lines of code. It was amazing to see the
> results. Even the attorneys who were doing the suing were amazed. (Whether
> all my discoveries represented actual breach of contract is a legal
> question, not a technical one, and was therefore well outside the scope of
> my work.)
>

True, but not all evidence of copying is evidence of a copyright violation.
One can say things look similar, but one needs to do a legal analysis to
know if said copying or apparent copying rises to the level of infringement
or not. Once issues like fair use, de minimis copying and scene a faire get
involved, it gets quite complicated to answer the legal question, even if
on its surface it looks like it might be copying, maybe with attempts to
conceal (since it may just be that all bubble sorts look alike once you
strip them down to semantic parts). Is it just another book about hunting
whales? Or is it too similar to Moby Dick?

Since there was no final judgement, but a negotiated settlement, we don't
have any satisfying answers.

Warner


> Marc
>
> On Mon, Nov 4, 2024 at 3:50 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:
>
>> On Monday,  4 November 2024 at 10:35:40 -0700, Marc Rochkind wrote:
>> > Many opinions of the evidence, especially on Groklaw, but also
>> > elsewhere, including here. But none of these people offering
>> > opinions have really seen the evidence,
>>
>> I think that depends on what SCO (and when) claimed as evidence.  They
>> did present slides of obfuscated code (replacing ASCII with Greek
>> letters in the assumption that nobody could recognize the original and
>> maybe that the code was too precious to show in the orignal).  I can't
>> find that any more, and maybe its on one of the many dead links on
>> http://www.lemis.com/grog/SCO/.  But
>> http://www.lemis.com/grog/SCO/code-comparison.php refers to it and
>> identifies the errors in the claims.
>>
>> > Mostly people talk about "evidence " offered by Darl at the
>> > start. But NONE of the actual evidence came from him. It was
>> > researched by a team of expert witnesses on both sides, of which I
>> > was one.
>>
>> I'd be very interested to hear what else they presented.  Did your
>> conclusions agree with mine?
>>
>> Greg
>> --
>> Sent from my desktop computer.
>> Finger grog@lemis.com for PGP public key.
>> See complete headers for address and phone numbers.
>> This message is digitally signed.  If your Microsoft mail program
>> reports problems, please read http://lemis.com/broken-MUA.php
>>
>
>
> --
> *My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*
>

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

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

[Larry McVoy]

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.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Greg 'groggy' Lehey]

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

On Monday,  4 November 2024 at 17:05:45 -0700, Marc Rochkind wrote:
> By evidence, I mean evidence that was part of the legal case(s). Material
> presented as a part of a marketing, sales, or public relations effort is
> not evidence in this sense.

OK, that makes sense.  Did it contradict the "evidence" that we
mortals saw?  That wouldn't have made sense.

> The way the copyright case ended doesn't mean that Linux development
> didn't violate copyrights. I'm pretty sure that it did, based on
> conversations with a friend of mine who was a technical expert on
> that part of the case.

Yes, I established that in the article that I wrote.  The real
question is how serious the violation was.  In the case (malloc()) it
was put in the Linux tree by somebody at SGI, and its use as
"evidence" appeared to show that System V was still using a very old,
inefficient memory allocation scheme.  More egg on SCO's face than
anything.

> One might ask, how could Torvalds and all those Linux developers
> violate System V copyrights since they had never seen System V code?
> The answer is that corporations such as IBM also contributed to
> Linux, and those corporations did have such access.

I worked for IBM's Linux Technology Centre at the time.  Everything
was very encapsulated.  I had the task of writing a JFS 1
implementation for Linux.  We already had JFS 2, but JFS 1 was a very
different beast.  It was written by IBM, so you'd think that I would
have had access to the sources.  No such luck.  All I got was the
header files.  This was before the SCO debacle, so it wasn't a
consequence of that.  I greatly doubt that any System V code came into
Linux via IBM.

> I just a few minutes ago glanced at the Wikipedia article "SCO–Linux
> disputes" and it's not bad. It does pretty much explain the breach of
> contract case. There is a section titled "IBM code in Linux" that lists
> some technologies (e.g., JFS, RCU), and that's the area that I
> worked on.

The JFS would have been JFS 2, of course--see above.  I can't comment
further.

My understanding had been that RCU originated in Linux (Paul
McKenney).  Following up, though, there's a patent
(https://patents.google.com/patent/US5442758) to this effect that puts
him in second place behind John Slingwine, and it started off at
Sequent.  I discussed the matter with Paul at the time, and he
dismissed the use of System V code out of hand.  Knowing Paul, I
believe him.  What level of code similarity did you find there?

> I wrote a program that could in effect do a "diff" on entire
> operating systems, hundreds of thousands of lines of code. It was
> amazing to see the results.

Did it establish the direction of the transfer?  The other "evidence"
that was published showed SCO claiming that the Berkeley Packet Filter
was part of System V (which I suppose it was), but of course it went
from BSD to System V, and presumably SCO had removed the Berkeley
license header.  And in the RCU case, I could imagine that some of the
RCU code found its way from Sequent to System V.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[ron minnich]

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

I had people relate to me, at least once, cases of utterly independent
implementations of a function that were byte for byte the same, as found in
one court case a friend of mine (now deceased) got pulled into. He had to
prove he'd written his code from scratch. But these were pretty simple
functions. I don't know if bmap qualifies ...

How could this happen? I don't know, but the court case that long predated
SCO. The only conclusion I can reach
is that when enough techniques, ideas, mailling lists, discussions, and
documents become part of a shared culture, the code which
people create might be the same. A weird parallel evolution of code.



On Mon, Nov 4, 2024 at 5: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.
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

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

[Warner Losh]

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

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. CSRG took
the position it was enough that AT&T no longer had enough original code
for them to assert copyright. AT&T too a contrary position. In the end, the
copyright notice was added (where it remains to this day) to acknowledge
this, but permission to use was granted with a covenant to not sue.

So it's complicated: It was rewritten, but not clean-room from scratch
rewritten.
It's one of those complicated situations where there was a real question
over
whether or not there was infringement, in part because there was also a
preliminary ruling that 32V likely didn't have copyright protection for
various
technical reasons, and since Berkeley started from that, there was no case.
AT&T was eager for that preliminary ruling to not be finalized so they
settled
with the Regents and the 7 files were removed completely and copyright
notices added to 70 files but otherwise licensed under what what would
become known as the 4-clause Berkeley License in 4.4BSD-Lite, which
was officially unencumbered by AT&T licensing requirements beyond
the BSDL.

Not a satisfying answer, but most negotiated settlements aren't.

Warner

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

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

[Warner Losh]

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

On Mon, Nov 4, 2024 at 6:32 PM ron minnich <rminnich@gmail.com> wrote:

> I had people relate to me, at least once, cases of utterly independent
> implementations of a function that were byte for byte the same, as found in
> one court case a friend of mine (now deceased) got pulled into. He had to
> prove he'd written his code from scratch. But these were pretty simple
> functions. I don't know if bmap qualifies ...
>
> How could this happen? I don't know, but the court case that long predated
> SCO. The only conclusion I can reach
> is that when enough techniques, ideas, mailling lists, discussions, and
> documents become part of a shared culture, the code which
> people create might be the same. A weird parallel evolution of code.
>

This is the legal principle of sene. a faire: some things are just endemic
to the genre that they have no copyright protection. If there's no other
way (or other sane way) to implement something, then two people can (and
do) reimplement it w/o there being any copyright infringement. There's a
complicated way to break down code into its parts, and see what was copied
vs what's necessary to implement an algorithm (which has no copyright
protection, and no patent protection in the era we're talking about).

It's what keeps the lawyers employed.

Warner


>
> On Mon, Nov 4, 2024 at 5: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.
>> --
>> ---
>> Larry McVoy           Retired to fishing
>> http://www.mcvoy.com/lm/boat
>>
>

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

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

[Larry McVoy]

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.

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.

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

[Warner Losh]

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

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

>

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

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

[Marc Rochkind]

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

Hi Greg! Now I remember where I had seen your name before. Perhaps I read
your deposition (if there was one)? Or just on a list of LTC staffers?

To do justice to your post and all your questions would require too much
writing and thinking, so I'll just clarify a few things.

1. The breach of contract part of the case wasn't about IBM putting System
V code into Linux. It was about IBM putting IBM code into Linux, and
McKinney's RCU was a good example. Nobody thought this was System V code or
that it had anything at all to do with AT&T. I think the LTC was staffed
with a lot of former Dynix (not sure I remember the name correctly) people,
right? And they put some of Dynix into Linux.

2. Examples that got widely talked about, such as malloc, were not good
examples of what the copyright case was about. As I said, I didn't work on
it, but I got briefed sometimes. This is an example of what I was talking
about: People thinking they knew what the issues were based on the issues
that they knew about. 99% of the evidence was sealed.

3. JFS (1 or 2, don't remember) as I recall was a tricky case. Something
like what you say, that it was developed in a clean room, but then put into
AIX and subsequently into Linux. If any AIXness got into Linux, then it was
also (like RCU) a case of IBM putting into Linux code that had come from a
System V derivative.

I would like to make it clear to the whole TUHS community that I personally
am not arguing one way or another about the ethics or legality of any of
this stuff. The contract between IBM and AT&T didn't even make sense.

I think the contribution that LTC made to Linux was enormous, not least
because it told the world that Linux was ready for prime time (e.g.,
mission critical server farms).

Marc

On Mon, Nov 4, 2024 at 6:34 PM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Monday,  4 November 2024 at 17:05:45 -0700, Marc Rochkind wrote:
> > By evidence, I mean evidence that was part of the legal case(s). Material
> > presented as a part of a marketing, sales, or public relations effort is
> > not evidence in this sense.
>
> OK, that makes sense.  Did it contradict the "evidence" that we
> mortals saw?  That wouldn't have made sense.
>
> > The way the copyright case ended doesn't mean that Linux development
> > didn't violate copyrights. I'm pretty sure that it did, based on
> > conversations with a friend of mine who was a technical expert on
> > that part of the case.
>
> Yes, I established that in the article that I wrote.  The real
> question is how serious the violation was.  In the case (malloc()) it
> was put in the Linux tree by somebody at SGI, and its use as
> "evidence" appeared to show that System V was still using a very old,
> inefficient memory allocation scheme.  More egg on SCO's face than
> anything.
>
> > One might ask, how could Torvalds and all those Linux developers
> > violate System V copyrights since they had never seen System V code?
> > The answer is that corporations such as IBM also contributed to
> > Linux, and those corporations did have such access.
>
> I worked for IBM's Linux Technology Centre at the time.  Everything
> was very encapsulated.  I had the task of writing a JFS 1
> implementation for Linux.  We already had JFS 2, but JFS 1 was a very
> different beast.  It was written by IBM, so you'd think that I would
> have had access to the sources.  No such luck.  All I got was the
> header files.  This was before the SCO debacle, so it wasn't a
> consequence of that.  I greatly doubt that any System V code came into
> Linux via IBM.
>
> > I just a few minutes ago glanced at the Wikipedia article "SCO–Linux
> > disputes" and it's not bad. It does pretty much explain the breach of
> > contract case. There is a section titled "IBM code in Linux" that lists
> > some technologies (e.g., JFS, RCU), and that's the area that I
> > worked on.
>
> The JFS would have been JFS 2, of course--see above.  I can't comment
> further.
>
> My understanding had been that RCU originated in Linux (Paul
> McKenney).  Following up, though, there's a patent
> (https://patents.google.com/patent/US5442758) to this effect that puts
> him in second place behind John Slingwine, and it started off at
> Sequent.  I discussed the matter with Paul at the time, and he
> dismissed the use of System V code out of hand.  Knowing Paul, I
> believe him.  What level of code similarity did you find there?
>
> > I wrote a program that could in effect do a "diff" on entire
> > operating systems, hundreds of thousands of lines of code. It was
> > amazing to see the results.
>
> Did it establish the direction of the transfer?  The other "evidence"
> that was published showed SCO claiming that the Berkeley Packet Filter
> was part of System V (which I suppose it was), but of course it went
> from BSD to System V, and presumably SCO had removed the Berkeley
> license header.  And in the RCU case, I could imagine that some of the
> RCU code found its way from Sequent to System V.
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog@lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

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

[Marc Rochkind]

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

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@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 <mrochkind@gmail.com>*

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

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

[Larry McVoy]

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.  100% sure.

I've traced that code through all the Bell Labs stuff to BSD.  The idea
that BSD redid this code the same way, in my mind, is a bridge too far.
bmap() knows about how stuff is laid out on disk, knows about how stuff
works in the inode (think indirect blocks and double indirect blocks),
there is _no_ _way_ BSD wrote the same code independently.  No f-ing
way.  They just took it.

I know we all want to think all the Bell Labs code is free or has been
reimplemented and it's all good, we're clean.  We're not.

It doesn't matter at this point but it matters to me that we are honest
about how we got here.

On Mon, Nov 04, 2024 at 05:32:19PM -0800, ron minnich wrote:
> I had people relate to me, at least once, cases of utterly independent
> implementations of a function that were byte for byte the same, as found in
> one court case a friend of mine (now deceased) got pulled into. He had to
> prove he'd written his code from scratch. But these were pretty simple
> functions. I don't know if bmap qualifies ...
> 
> How could this happen? I don't know, but the court case that long predated
> SCO. The only conclusion I can reach
> is that when enough techniques, ideas, mailling lists, discussions, and
> documents become part of a shared culture, the code which
> people create might be the same. A weird parallel evolution of code.
> 
> 
> 
> On Mon, Nov 4, 2024 at 5: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.
> > --
> > ---
> > Larry McVoy           Retired to fishing
> > http://www.mcvoy.com/lm/boat
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

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

[Warner Losh]

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

On Mon, Nov 4, 2024 at 8:14 PM Larry McVoy <lm@mcvoy.com> 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.  100% sure.
>

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.

You may be 100% sure, but it's not this specific routine.


> I've traced that code through all the Bell Labs stuff to BSD.  The idea
> that BSD redid this code the same way, in my mind, is a bridge too far.
> bmap() knows about how stuff is laid out on disk, knows about how stuff
> works in the inode (think indirect blocks and double indirect blocks),
> there is _no_ _way_ BSD wrote the same code independently.  No f-ing
> way.  They just took it.


You may have found a routine like that, but it's not the bmap routine. It
evolved
from when they started with 32V, true and was copied to ufs_bmap.c 4.2BSD
and
altered to work with the new filesystem layout.

For 4BSD and 4.1BSD it's still in subr.c, where it is in 32V and V7. But
even there,
it's writing directories synchronously but other files async. 32V writes
everything
asynchronously. And a few other diffs if you study.

But the routine bmap was copied to ufs_bmap in 4.2BSD and changed.
It was changed further in 4.3BSD, and further still in 4.4BSD. The code
for this is clear, but in the TUHS repo and on Kirk's disk.

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

and net/2 had ufs_bmap.c. Berkeley agreed to stop distributing it as
it was there, likewise with 4.4BSD.

4.4BSD-Lite has a completely rewritten ufs_bmap.c (I'd checked 4.4bsd-alpha
before). It's very very different. There's an AT&T copyright on the file,
but bmap
is completely different (and it calls routines that are completely
different). You
can see if from the online 4.4-BSDlite2 artifacts (the 4.4 directory from
kirk's
collection also has 4.4-Lite, I believe, and the file is almost the same).

https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/src/sys/ufs/ufs/ufs_bmap.c

has the online copy if people want to check it out.


> I know we all want to think all the Bell Labs code is free or has been
> reimplemented and it's all good, we're clean.  We're not.
>

The historical artifacts we have don't show that. Plus, the ancient unix
license gives the right to 32V and 32V derived systems (which all the BSDs
are),
so even if what you said is true, there's a good foundation (but what you
say
is not true, bmap is not 100% identical between 32V and even 4BSD, let alone
4.4BSD-lite, where it's completely re-written.


> It doesn't matter at this point but it matters to me that we are honest
> about how we got here.


We got here in large part due  AT&T and Berkeley working out their
differences,
Berkeley rewriting some code and AT&T signing off on 4.4BSD-lite and
Berkeley signing off on System V (since AT&T had also copied from Berkeley
without credit).

Now, maybe there was some other routine, or maybe it was Net2 that you found
it in (and it was fixed), but 4.4BSD-lite is clean in this respect.

Warner


> On Mon, Nov 04, 2024 at 05:32:19PM -0800, ron minnich wrote:
> > I had people relate to me, at least once, cases of utterly independent
> > implementations of a function that were byte for byte the same, as found
> in
> > one court case a friend of mine (now deceased) got pulled into. He had to
> > prove he'd written his code from scratch. But these were pretty simple
> > functions. I don't know if bmap qualifies ...
> >
> > How could this happen? I don't know, but the court case that long
> predated
> > SCO. The only conclusion I can reach
> > is that when enough techniques, ideas, mailling lists, discussions, and
> > documents become part of a shared culture, the code which
> > people create might be the same. A weird parallel evolution of code.
> >
> >
> >
> > On Mon, Nov 4, 2024 at 5: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.
> > > --
> > > ---
> > > Larry McVoy           Retired to fishing
> > > http://www.mcvoy.com/lm/boat
> > >
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

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

[Greg 'groggy' Lehey]

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

On Monday,  4 November 2024 at 20:04:38 -0700, Marc Rochkind wrote:
> Hi Greg! Now I remember where I had seen your name before. Perhaps I
> read your deposition (if there was one)? Or just on a list of LTC
> staffers?

My guess is that you saw it elsewhere.  I didn't make a deposition,
and I left IBM 6 months before the announcement of the case.

> To do justice to your post and all your questions would require too much
> writing and thinking, so I'll just clarify a few things.
>
> 1. The breach of contract part of the case wasn't about IBM putting System
> V code into Linux. It was about IBM putting IBM code into Linux, and
> McKinney's RCU was a good example.

Oh.  That changes everything.  Rather like the "viral" GPL?  The
Wikipedia page still claims

  SCO claimed that IBM had, without authorization, contributed SCO's
  intellectual property to the codebase of the open source, Unix-like
  Linux operating system.

> Nobody thought this was System V code or that it had anything at all
> to do with AT&T. I think the LTC was staffed with a lot of former
> Dynix (not sure I remember the name correctly) people, right?

I don't know.  It's possible, but LTC was geographically distributed,
and we (Ozlabs) were in Canberra.  I don't even know where Paul was,
though I have some recollection that it was in the NW of USA.

> 2. Examples that got widely talked about, such as malloc, were not good
> examples of what the copyright case was about. As I said, I didn't work on
> it, but I got briefed sometimes. This is an example of what I was talking
> about: People thinking they knew what the issues were based on the issues
> that they knew about. 99% of the evidence was sealed.

That makes it all the stranger that SCO presented the malloc()
lookalike as an example, especially since they (as Caldera) had
released it a year before.  Could it be that there were two teams, one
doing the publicity and one doing the real investigation?

> 3. JFS (1 or 2, don't remember) as I recall was a tricky
> case. Something like what you say, that it was developed in a clean
> room, but then put into AIX and subsequently into Linux. If any
> AIXness got into Linux, then it was also (like RCU) a case of IBM
> putting into Linux code that had come from a System V derivative.

JFS 1 and 2 were two very different beasts.  JFS 1 never made it to
Linux.  JFS 2 was written for Linux and (I think) later backported to
AIX.  I had initially thought that JFS 2 was a "JFS 1 lite", but in
fact it was a much better implementation.

> I would like to make it clear to the whole TUHS community that I
> personally am not arguing one way or another about the ethics or
> legality of any of this stuff.

Understood.  From my point of view this is a technical discussion.

> I think the contribution that LTC made to Linux was enormous, not
> least because it told the world that Linux was ready for prime time
> (e.g., mission critical server farms).

... as long as you didn't mind riding bicycles.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[ron minnich]

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

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@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@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 <mrochkind@gmail.com>*
>

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

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

[Marc Rochkind]

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

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@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@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@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 <mrochkind@gmail.com>*
>>
>

-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

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

[Theodore Ts'o]

On Thu, Nov 07, 2024 at 01:59:18PM -0700, Marc Rochkind wrote:
> 
> 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.

Well, it is certainly possible to insert dual-licensed code --- for
exaple, there are some WiFi drivers which are dual-licensed under the
BSD and GPL licenses, and the file is very clearly marked as being
dual licensed.  This means that if someone contributes changes to the
file, their are agreeing that their changes are also similarly
dual-licensed --- and so those changes can be take and merged into a
driver that might be part of (for example) FreeBSD.

Now, if you take code which was originally under a weak FOSS license which
is GPL compatible, and you don't mark it as dual licensed when you
incorporate it into a GPL project, the presumption is that the code in
the GPL project is GPL licensed.  So if there are changes made to that
codebase as it exists in the GPL code bases, those changes are
presumed to be GPL-licened, and hence can't be contributed back to the
BSD-licensed code base.

This caused a certain aount of unhappiness by BSD partisans, since
they viewed it unfair the GPL project to take code from the BSD
project, but they couldn't do the reverse.  There were two responses
to this.

The first was, "well, if you were OK with a weak free software
license, and you were presumably happy allowing NetAPP or Sun to take
your code and make $$$ off of it, why are you whining about a GPL
project doing essentilly the same thing as NetAPP or Sun?  In both
cases, you aren't getting improveents back from your code.  Deal with
it."

The second resonse was to work with the BSD folks, and to maintain
certain drivers as dual-licensed, as described earlier.

In some other, related cases, such as Linux's /dev/random driver, or
the UUID library in userspace, I *wanted* the code to get used in as
may places as possible, and so I was **happy** that Apple adopted my
UUID library in MacOS, something that was only possible because I had
dual-licensed the UUID library under the GPL and BSD-style license
from the get-go.  As far as I know no took the /dev/random driver from
Linux and put in their BSD-style licensed OS.  But it certainly worked
as-designed in the case of the UUID library.  (Not that it was a huge
amount of code, but I was passionate about promulgating the use of
UUID's as far and as wide as possible.)

Cheers,

					- Ted

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

[Warner Losh]

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

On Thu, Nov 7, 2024 at 4:03 PM Theodore Ts'o <tytso@mit.edu> wrote:

> On Thu, Nov 07, 2024 at 01:59:18PM -0700, Marc Rochkind wrote:
> >
> > 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.
>
> Well, it is certainly possible to insert dual-licensed code --- for
> exaple, there are some WiFi drivers which are dual-licensed under the
> BSD and GPL licenses, and the file is very clearly marked as being
> dual licensed.  This means that if someone contributes changes to the
> file, their are agreeing that their changes are also similarly
> dual-licensed --- and so those changes can be take and merged into a
> driver that might be part of (for example) FreeBSD.
>
> Now, if you take code which was originally under a weak FOSS license which
> is GPL compatible, and you don't mark it as dual licensed when you
> incorporate it into a GPL project, the presumption is that the code in
> the GPL project is GPL licensed.  So if there are changes made to that
> codebase as it exists in the GPL code bases, those changes are
> presumed to be GPL-licened, and hence can't be contributed back to the
> BSD-licensed code base.
>
> This caused a certain aount of unhappiness by BSD partisans, since
> they viewed it unfair the GPL project to take code from the BSD
> project, but they couldn't do the reverse.  There were two responses
> to this.
>
> The first was, "well, if you were OK with a weak free software
> license, and you were presumably happy allowing NetAPP or Sun to take
> your code and make $$$ off of it, why are you whining about a GPL
> project doing essentilly the same thing as NetAPP or Sun?  In both
> cases, you aren't getting improveents back from your code.  Deal with
> it."
>

Part of the problem, though, in some of these cases was that the entire
license was removed, rather than the GPL being just added...  The BSDL
is quite permissive, true, but not quite that permissive...


> The second resonse was to work with the BSD folks, and to maintain
> certain drivers as dual-licensed, as described earlier.
>

Which is always a better choice...


> In some other, related cases, such as Linux's /dev/random driver, or
> the UUID library in userspace, I *wanted* the code to get used in as
> may places as possible, and so I was **happy** that Apple adopted my
> UUID library in MacOS, something that was only possible because I had
> dual-licensed the UUID library under the GPL and BSD-style license
> from the get-go.  As far as I know no took the /dev/random driver from
> Linux and put in their BSD-style licensed OS.  But it certainly worked
> as-designed in the case of the UUID library.  (Not that it was a huge
> amount of code, but I was passionate about promulgating the use of
> UUID's as far and as wide as possible.)
>

That's a good outcome...

Warner


> Cheers,
>
>                                         - Ted
>

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

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

[G. Branden Robinson]

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

At 2024-11-07T13:59:18-0700, Marc Rochkind wrote:
> 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.

The copyright license applies to the copyrighted material in question.

If you don't distribute material licensed under the GPL, the GPL does
not apply to you.  If you do, it does (barring any exceptions applicable
under copyright law, or a superseding license granted by the copyright
holder).

Traditionally, people in the BSD camp and some others complained when
someone like, say, the GNU Project took a BSD-licensed code base, made
non-negligible contributions to it, and distributed the combination
under the GPL.  This practice won the GPL the charming characterization
of "viral".

That was a misleading description because if you extract the
BSD-licensed code (and only that) back out of the combination, then you
are no longer bound by the GPL.  It can't touch you.  Behold, you are
cured of the "virus", which turns out to be an intrinsic property of
the code, not something that replicates and propagates itself.

However, if you were, say, Sun Microsystems, and did exactly the same
thing as the GNU Project except you proclaimed your non-negligible
contribution "all rights reserved", the aforementioned complainers fell
silent.  I've never heard a comprehensible justification for this
disparity, though I do remember a NetBSD founder describing it to
my face (yes, in person) as "true freedom"; I suppose it was because a
lot of BSD people had dreams of starting a company and enjoying Bill Joy
levels of wealth by putting proprietary "value-adds" on top of BSD--for
all I know this was the BSDI business plan.  That outcome was unlikely
if they distributed their source code under share-and-share-alike terms.

It can of course be tedious to reverse an admixture of code, especially
the more time passes.  This lesson was taught again, this time _to_ GPL
advocates, when Red Hat decided to hide the Git history of their version
of the Linux kernel from everyone but their paying enterprise services
customers.[1]  This was an effort to scrape off a free-riding competitor
known as Oracle Enterprise Linux.  With sophisticated revision control
(and good change set discipline), it can be tractable to detangle code
changes from certain parties.  Git is now so ubiquitous in source
configuration control that one can make the argument that a project's
Git repository is the "preferred form of modification" under the terms
of the GNU GPL itself.  That interpretation would have been inconvenient
for Red Hat, so, as a business necessity, it was not a correct one.

Whether the GPL truly applies to the Linux kernel at all is an
interesting question.  It appears to me that it does--unless and until
you pay membership dues to the Linux Foundation.[2]  You can then treat
it as being under the 2-clause BSD license, MIT/X11 license, or similar.
If anyone knows of a counterexample (that is, of a case of an LF member
out of compliance with the GPL _in the Linux kernel_ being compelled to
come into compliance), I'm all ears.

Regards,
Branden

[1] https://lwn.net/Articles/430098/
[2] a U.S. 501(c)6 "business league", not a 501(c)3 charity

    Classically, this sort of cooperative arrangement is better known as
    a "cartel".  That term was too useful to scholars and lay people
    alike in critical analysis of the behavior of firms, so it is now
    debased and used loosely to refer to a single, stereotypically
    non-federated and dictatorially commanded organization[3] that
    manufactures and/or trafficks in contraband such as illegal drugs.
    We don't even refer to OPEC as a cartel anymore.  (According to
    Google ngram, that usage peaked in 1977 and by 2022 has declined to
    about 8% of its former level.  I wonder if that has to do with the
    Iranian Revolution and subsequent much closer ties between the U.S.
    and KSA.)

[3] Then again, there's always Baltimore's New Day Co-Op... ;-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Theodore Ts'o]

On Sat, Nov 09, 2024 at 12:29:55PM -0600, G. Branden Robinson wrote:
> 
> Whether the GPL truly applies to the Linux kernel at all is an
> interesting question.  It appears to me that it does--unless and until
> you pay membership dues to the Linux Foundation.[2]  You can then treat
> it as being under the 2-clause BSD license, MIT/X11 license, or similar.
> If anyone knows of a counterexample (that is, of a case of an LF member
> out of compliance with the GPL _in the Linux kernel_ being compelled to
> come into compliance), I'm all ears.

The Linux Foundation does not exclusively own the copyright on the
Linux kernel.  The copyright is jointly owned by all of the
contributors of the Linux kernel.  This makes it quite unlike the FSF
projects, where contributions to FSF project require a copyright
assignment[1].   

[1] https://www.fsf.org/bulletin/2022/fall/copyright-assignment-with-the-fsf

The FSF requires the copyright assignment primarily to make it easy to
due entities which the FSF perceives to have violated the GPL.  The
Linux community tends to not prioritize using lawsuits to enforce the
GPL.  Our preference is to use public shaming and pursuading companies
that by holding their changes back, they are actually hurting
themselves.  This is because the Linux kernel is constantly improving,
and if you don't contribute the changes back, in order to to take
advantage of the new features in the latest upstream kernel, you would
have to constantly forward port your patches to tha latest kernel is
P-A-I-N-F-U-L.

For example, consider the data center kernel used by Google.  Since it
is not distributed outside of Google, there is no obligation under the
GPL to distribute sources for any changes made to the Linux kernel.
However, Google *wants* to contribute those changes back, because
forward-porting 9,000 out-of-tree patches is a huge amount of
engineering effort.  Hence, Project Icebreaker[1], which is an effort
to reduce this technical debt by getting as many patches upstream as
possible, with a goal to be able to update to each year's Stable
kernel every year.  (And if you have to forward-port 9,000 commits,
and then test and qualify all of these changes, it's simply
impossible.)

[2] https://lwn.net/Articles/871195/

Linux Foundation membership has absolutely nothing to do with GPL
license obligations.  All Linux Foundation members and non-members,
are obliged to following the GPL license.  And although Linux
Foundation members might wish otherwise, LF membership also doesn't
guarantee that your changes will be accepted upstream.  Getting
changes upstream requires that they pass peer review and the bar that
subsystem maintainers set for technical assistance is quite difficult.
Despite it being a high bar, many companies spend a lot of effort to
make to get their changes upstream --- because it's worth it for them.

And because Google wants the changes contributed by Facebook and
Amazon, and Facebook wants the changes from Amazon and Google, etc.,
this becomes a virtuous circle which encourages other companies, like
IBM, Samsung, etc., to contribute *their* changes back to the Linux
kernel mainline.

So why do companies join the Linux Foundation?  Well, there are a
number of benefits, but one very important one is that it provides a
way for companies to directly collaborate with funded programs to make
improvements to Linux without worrying about anti-trust conerns.  For
example, 15 years ago, IBM, Intel, HP, and other companies collaborate
to improve Linux Scalability, and the companies collaborated about
which asspects of the Linux Scalability Effort they would work on
without having two companies ending up working on the same problems.
Of course, 501(c)(6) organizations are not the only way companies can
safely collaborate; standards development organizations like ANSI and
ISO are aanother way companeis can work together.  But if you think
the Linux Foundation membership dues are expensive, trust me, having
done both, participating in ANSI/ISO/INCITS can be *way* more
expensive.  (Especially once you take into account the mandatory
international travel required...)

						- Ted

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

[G. Branden Robinson]

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

Thanks for the reply, Ted.  It was helpful in part.

At 2024-11-09T15:30:01-0500, Theodore Ts'o wrote:
> On Sat, Nov 09, 2024 at 12:29:55PM -0600, G. Branden Robinson wrote:
> > 
> > Whether the GPL truly applies to the Linux kernel at all is an
> > interesting question.  It appears to me that it does--unless and
> > until you pay membership dues to the Linux Foundation.[2]  You can
> > then treat it as being under the 2-clause BSD license, MIT/X11
> > license, or similar.  If anyone knows of a counterexample (that is,
> > of a case of an LF member out of compliance with the GPL _in the
> > Linux kernel_ being compelled to come into compliance), I'm all
> > ears.
> 
> The Linux Foundation does not exclusively own the copyright on the
> Linux kernel.  The copyright is jointly owned by all of the
> contributors of the Linux kernel.  This makes it quite unlike the FSF
> projects, where contributions to FSF project require a copyright
> assignment[1].

That's a myth.  It is the FSF's stated _preference_, but it is a
negotiable point.  For example, Thomas Dickey negotiated reversion of
copyright to himself when becoming ncurses maintainer 26 years ago.[A]

More recently, in 2021 GCC stopped requiring copyright assignment.[B]
Shortly thereafter, the GNU C Library considered making the same
decision,[C] but I don't know that turned out.

One could argue that ncurses was a special case because it was regarded
as critical infrastructure[J] and its maintainership had been in crisis,
and that GCC and glibc were also special because of the heavy
involvement of deep-pocketed corporate interests in their development.

But is it true for less prestigious projects or individual contributors
with no clout to speak of?

Well, in September I became the maintainer of groff, which is an
official GNU Project.[D]  I quote the onboarding email that was sent to
me when the maintainership change was approved:

>>> For a program to be GNU software does not require transferring
>>> copyright to the FSF; that is a separate question.  If you transfer
>>> the copyright to the FSF, the FSF will enforce the GPL for the
>>> program if someone violates it; if you keep the copyright,
>>> enforcement will be up to you.

Like the "virality" of the GPL, mandatory copyright assignment to the
FSF appears to be one of those things that people like to repeat without
having their facts in order.  Some of them, I suspect, know better but
spread falsehoods anyway, because it is virtuous to oppose RMS for
transgressions real and imagined.  (I've had my own fight with him, and
haven't changed my mind about it.)

> The FSF requires the copyright assignment primarily to make it easy to
> due entities which the FSF perceives to have violated the GPL.

Personally, I think the Linksys lawsuit produced a good outcome.  I
appear not to be alone.[K]

> The Linux community tends to not prioritize using lawsuits to enforce
> the GPL.  Our preference is to use public shaming and pursuading
> companies that by holding their changes back, they are actually
> hurting themselves.

As you say, that's a preference--like the FSF's _preference_ for
copyright assignment.  Please cite some instances of public shaming
leading to public repentance and correction among GPL-violating
distributors of the Linux kernel.

> This is because the Linux kernel is constantly improving,

Unlike all other software...

> and if you don't contribute the changes back, in order to to take
> advantage of the new features in the latest upstream kernel, you would
> have to constantly forward port your patches to tha latest kernel is
> P-A-I-N-F-U-L.

Yes it is.  Another "solution" is to keep ancient kernels around long
after LKML has given up on them.[E]

> For example, consider the data center kernel used by Google.  Since it
> is not distributed outside of Google, there is no obligation under the
> GPL to distribute sources for any changes made to the Linux kernel.

Sure.  The Debian Desert Island and Dissident Tests[F][G] are useful.

> However, Google *wants* to contribute those changes back, because
> forward-porting 9,000 out-of-tree patches is a huge amount of
> engineering effort.  Hence, Project Icebreaker[1], which is an effort
> to reduce this technical debt by getting as many patches upstream as
> possible, with a goal to be able to update to each year's Stable
> kernel every year.  (And if you have to forward-port 9,000 commits,
> and then test and qualify all of these changes, it's simply
> impossible.)

Okay.  This could be an example of Google undertaking good citizenship
(or, more cynically, trying to offload the labor of maintaining kernel
features they value onto others).  But as you say, "since it's not
distributed outside of Google", I don't see how it proves or refutes
anything about LF membership vis à vis GPL enforcement.

> Linux Foundation membership has absolutely nothing to do with GPL
> license obligations.

With respect to the Linux kernel in particular, it seems the GPL _in
practice_ imposes no obligations.  That was my point.  Little
enforcement is visible.  As far as "public shaming" goes, I've seen it
from the FSF and the Software Freedom Conservancy, not from the LF.

Give me examples of the LF leaning on infringers and getting results!
I want them!

(To put on my Carnac hat, one could certainly claim that a ton of such
persuasion has gone on using the velvet glove approach, on a
confidential basis to avoid disturbing the delicate feelings of limited
liability corporations and their share prices.  That's a choice.  One of
the consequences of committing to non-disclosure of evidence is that you
can't blame the public for not being aware of it.)

> All Linux Foundation members and non-members, are obliged to following
> the GPL license.

With what consequence if they don't?

They are obliged to the _copyright holder_; as you point out, "the Linux
Foundation does not exclusively own the copyright on the Linux kernel."
(More's the pity, I reckon, when one of those other copyright holders is
named Patrick McHardy.[L])

If the LF prefers to leave enforcement of the GPL in the Linux kernel to
copyright holders other than themselves, I think they should explicitly
state this policy.

> And although Linux Foundation members might wish otherwise, LF
> membership also doesn't guarantee that your changes will be accepted
> upstream.  Getting changes upstream requires that they pass peer
> review and the bar that subsystem maintainers set for technical
> assistance is quite difficult.  Despite it being a high bar, many
> companies spend a lot of effort to make to get their changes upstream
> --- because it's worth it for them.
> 
> And because Google wants the changes contributed by Facebook and
> Amazon, and Facebook wants the changes from Amazon and Google, etc.,
> this becomes a virtuous circle which encourages other companies, like
> IBM, Samsung, etc., to contribute *their* changes back to the Linux
> kernel mainline.

This seems like a distraction from my point about copyright license
enforcement.  I distinguish that activity from patch integration.

> So why do companies join the Linux Foundation?  Well, there are a
> number of benefits, but one very important one is that it provides a
> way for companies to directly collaborate with funded programs to make
> improvements to Linux without worrying about anti-trust conerns.

Are these concerns anything more than notional?  Is there any precedent
for an antitrust action being undertaken predicated on the use of
technology that is available free of charge to, and customizable without
bound by, anyone in the world?  (I'm well aware of FTC cases around free
web browsers--these typically have turned on bundling with the OS and/or
the placement of site-specific branding icons or configured default
search engines.  To the extent that such examples can be applied to the
Linux kernel at all, is there evidence of any contract anywhere ever
having been signed that prohibits a party from altering the kernel?)

A fortiori, practically speaking, if your firm has an antitrust problem,
all it has to do is protract the case until the next Republican U.S.
administration, which could direct the DoJ to dismiss the case on the
grounds that antitrust actions inherently constitute interference with
the free market.[H]  In any event, the likelihood of any antitrust case
proceeding against any tech company on any basis other than merger or
acquisition seems unlikely.[I]

> For example, 15 years ago, IBM, Intel, HP, and other companies
> collaborate to improve Linux Scalability, and the companies
> collaborated about which asspects of the Linux Scalability Effort they
> would work on without having two companies ending up working on the
> same problems.  Of course, 501(c)(6) organizations are not the only
> way companies can safely collaborate; standards development
> organizations like ANSI and ISO are aanother way companeis can work
> together.  But if you think the Linux Foundation membership dues are
> expensive, trust me, having done both, participating in
> ANSI/ISO/INCITS can be *way* more expensive.  (Especially once you
> take into account the mandatory international travel required...)

This, too, seems to have little to do with GPL enforcement.

But I do sympathize with WG14 and the Austin Group; following recent
developments with C23 and POSIX 2014, it seems that ISO is bent
on giving them a hard time.  Maybe ISO/IEC, or certain players within,
are trying to shed some mass, and/or don't see C and Unix as worth
standardizing anymore.  Old and busted.  What's the new hotness?

Regards,
Branden

[A] https://invisible-island.net/ncurses/ncurses-license.html
    https://invisible-island.net/ncurses/ncurses.faq.html#relicensed
[B] https://lwn.net/Articles/857791/
[C] https://lwn.net/ml/libc-alpha/e13a4072-a53e-d9e1-d5c7-bf4179fead56@redhat.com/
[D] https://directory.fsf.org/wiki/Groff
[E] https://www.cnx-software.com/2021/04/13/allwinner-d1-linux-risc-v-sbc-processor/
[F] https://wiki.debian.org/DesertIslandTest
[G] https://wiki.debian.org/DissidentTest
[H] https://www.nationalreview.com/corner/thatcher-and-hayek/
[I] https://rollcall.com/2024/11/08/trump-administration-faces-antitrust-enforcement-dilemma/
[J] albeit not by termcap and S-Lang fans
[K] https://lwn.net/Articles/957255/
[L] https://www.zdnet.com/article/linux-beats-internal-legal-threat/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Theodore Ts'o]

(Moving this thread over to COF, since we've gotten pretty far afield
from the TUHS list's charter.)

On Sat, Nov 09, 2024 at 04:23:34PM -0600, G. Branden Robinson wrote:
> > The Linux Foundation does not exclusively own the copyright on the
> > Linux kernel.  The copyright is jointly owned by all of the
> > contributors of the Linux kernel.  This makes it quite unlike the FSF
> > projects, where contributions to FSF project require a copyright
> > assignment[1].
> 
> That's a myth.  It is the FSF's stated _preference_, but it is a
> negotiable point.  For example, Thomas Dickey negotiated reversion of
> copyright to himself when becoming ncurses maintainer 26 years ago.[A]

In the web site I quoted, the fact that there is an option not to do
the copyright assignment was apparently conveniently ommitted.  And in
the early 1990's, I *personally* tried negotiating to not do the
copyright assignment directy with the FSF, and I was told to go to
heck.  Given that I *had* taken a legal class from the MIT Sloan
School (Legal issues for the I/T Manager), I knew what the word
"indemnify" meant, and there was no way in the world I was going to
sign the damned FSF copyrioght legal paperwork, and I told the FSF so.

The only other alternative was my not contributing to the GNU Project.


The FSF may have since relaxed their poition in the past 30 years, but
it's not something that they've really admitted (again, see the FSF
web page I referenced).  My theory is that the only reason *why* they
relaxed their position was that it would have made GNU even more
irrelevant if they hadn't (e.g., people don't have to contribute to
GCC; if it's more friendly and easier to contribute to Clang.)


> But is it true for less prestigious projects or individual contributors
> with no clout to speak of?

Well, apparently in the early 1990's I didn't have any clout in the
eyes of the FSF.  :-)

Probably for the best, all things considered.


> With respect to the Linux kernel in particular, it seems the GPL _in
> practice_ imposes no obligations.  That was my point.  Little
> enforcement is visible.  As far as "public shaming" goes, I've seen it
> from the FSF and the Software Freedom Conservancy, not from the LF.
> 
> Give me examples of the LF leaning on infringers and getting results!
> I want them!

OK, I see where you are coming from here.  And I think the main isue
is that the goals of the Linux community are quite different from that
of the FSF.  (And note that I say the Linux community, since these
atttudes predate the founding of the Linux Foundation by **years** and
existed across many developers, some of whom, like me, weren't yet
hired by a Linux corporation; I was at MIT, and my day job was TL for
MIT Kerberos and IPSEC working group chair for the IETF as well as
serving on MIT Network Operations.)

The Linux attitude was a focus on the social contract between
*developers*.  If you improve the Linux kernel, we expect that you
contribute those changes back.  So what we care about is the company
that has 9,000 out of tree patches, representing hundreds of engineer
years of SWE investment.  And here, this is where in practce, GPL
social contract becomes self-enforcing.  It is in the interest of the
company who is interested in keeping up with upstream to get the
changes back upstream.

The FSF and Richard Stallman has a much bigger focus on the ability of
users to be able to get the sources for GPL'ed code, make changes, and
then install that changed sources on their hardware.  That's a fine
goal, and I respect that some people might have that as a very strong
policy preference and something that they care about.  It's just that
it's a very different goal than what most Linux kernel developers care
about.  (And again, this wasn't shaped by my employers; I and many of
the people I know had these preferences long before the Linux
companies formed and started hiring us.)

So take for example, the hypothetical someone who makes a tiny change
to the Linux kernel to create a crappy AI gadge in a square orange
box.  Call it, for the sake of argument, the "Squirrel S1".  :-)

As far as the Linux kernel community is concerned, the Squirrel S1 is
irrelevant.  It has no interesting technology that we would care
about, and while it might be sad that a user might not be able to
change the software in the S1, either because the manufacturer didn't
meet their GPL oligations, or the hardware was locked down and the
GPL2 does't have an anti-Tivo clause it it, in my opinion, the
enforcement is self-executing.  If you're a user, and can't make
changes, and you want to, then don't fork over $199 for the Squirrel
S1!

From the FSF's Free Softare perspective, they obviously have a very
different goal.  They believe all users should have the ability to
access the source code and modify software on a Squirrel S1, whether
they want to doit or not, and regardless of whether that might cause
the device to become more expensive.  They believe this is a core user
freedom, that should never be abograted.

I respect those people who have those feelings.  But obviously people
in the BSD camp don't share those priorities --- and in the Linux
kernel community, while we believe the GPL2 is a great way of
expressing the social expectations between developers, we don't
necessarily share the same attitudes as Mr. Stallman.

Could someone who has some copyright ownership try do some vexatious
lawsuits in order to (legally) extort money out of companies who are
infringing the GPL?  Sure; although I'll note that for the targets of
those lawsuits, I'm not so sure that they would see that much
difference between a Patrck McHardy and the SFC.  And at least
personally, the amount of help that I would give a Patric McHardy and
an SFC lawsuit is pretty much the same; zero, and my personal opinion
is that they are not really helpful, since my goal is to have more
companies being *happy* to contribute to Linux; not to feel coerced
and forced to contribute by sullenly dropping a bunch of code to
comply with the GPL and then walking away.

> > So why do companies join the Linux Foundation?  Well, there are a
> > number of benefits, but one very important one is that it provides a
> > way for companies to directly collaborate with funded programs to make
> > improvements to Linux without worrying about anti-trust conerns.
> 
> Are these concerns anything more than notional?

Well, I was at the IBM Linux Technology Center when we were first
working on standardizing ISO/IEC 23360-2:2006.  This was well after
the FTC consent decree was dissolved in 1996, and while a Republican
(George W. Bush) was president --- and I can tell you that it *was*
something that my employer at the time very much cared about.  We got
very clear instructions about what we could and could't do when we
participated with OSDL and Linux Foundation work groups, and we had
madatory training regarding how to not get in trouble with anti-trust
enforcers.

> But I do sympathize with WG14 and the Austin Group; following recent
> developments with C23 and POSIX 2014, it seems that ISO is bent
> on giving them a hard time.  Maybe ISO/IEC, or certain players within,
> are trying to shed some mass, and/or don't see C and Unix as worth
> standardizing anymore.  Old and busted.  What's the new hotness?

ISO/IEC participation has always been heavyweight, and companies are
quite strategic about the understanding the cost benefit tradeoffs of
participating in ISO.  This has been true for years; and once various
European government customers stopped requiring ISO standardization,
IBM and HP pretty quickly stopped funding the standards tech writer
and those of us who were on the US National Body represenatives to
ISO/IEC for 23360.

(And not just the US; the various companies working on the ISO/IEC
23360 effort had carefully made sure that to have their employees in
other country's national bodies, to make sure the fix was in.  This
was not too different from what Microsoft was accused of doing while
standardizing ISO/IEC 29500, although not to the same scale; there
were many more countries' national bodies involved with ISO/IEC 29500.
So when you say "ISO" is giving the Austin Group a hard time, I'd ask
the question, "who on ISO"?  And what company do they work for; or if
they are an independent contractor, which company might be paying them
at the time; and what the agenda of those company(s) might be?)

Am I super cynical about ISO/IEC standards?  Perhaps.   :-)

     	       		  	   	  	   - Ted


P.S.  Obviously, not *everyone* in the Linux ecosystem feels this way.
For example, there are many people in Debian who are much more aligned
with the FSF.  After all, they are one of the few distros that will
use the GNU/Linux terminology demanded by Stallman.

But I have talked to many Linux kernel developers over the past 30+
years, and I think have a pretty good sense of what the bulk of the
"old-timers" priorities have been.  After all, if we had been much
more aligned with the FSF's philosophies, perhaps we would have worked
on GNU/HURD isntead.  :-)

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

[Kevin Bowling]

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
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

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

[Kevin Bowling]

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

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

[Marc Rochkind]

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

About that IBM-written and Sequent-written code in Linux: It wasn't just
algorithms, it was actual code. Not snippets, but dozens, even hundreds of
lines of code put into Linux from AIX and Dynix. This was different from
the copyright case, where there was disagreement about whether copying
occurred. (Again, the code I'm talking about from AIX and Sequent was NOT
AT&T code. It was entirely authored by IBM and Sequent.)

Whether IBM did anything unethical, illegal, or inappropriate is another
matter entirely. I think the lawyers argued back and forth for years, over
a decade even, about this, but it was way out of my scope.

Marc

On Mon, Nov 11, 2024 at 7:34 PM Kevin Bowling <kevin.bowling@kev009.com>
wrote:

> 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
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

[-- Attachment #2: Type: text/html, Size: 9473 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 --]

[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] 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] 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)

[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)

[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