* [TUHS] RIP Darl McBride former CEO of SCO @ 2024-11-04 1:17 Will Senn 2024-11-04 2:31 ` [TUHS] " Greg 'groggy' Lehey 0 siblings, 1 reply; 31+ messages in thread From: Will Senn @ 2024-11-04 1:17 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: RIP Darl McBride former CEO of SCO 2024-11-04 1:17 [TUHS] RIP Darl McBride former CEO of SCO Will Senn @ 2024-11-04 2:31 ` Greg 'groggy' Lehey 2024-11-04 3:34 ` Wesley Parish 0 siblings, 1 reply; 31+ messages in thread From: Greg 'groggy' Lehey @ 2024-11-04 2:31 UTC (permalink / raw) To: Will Senn; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: RIP Darl McBride former CEO of SCO 2024-11-04 2:31 ` [TUHS] " Greg 'groggy' Lehey @ 2024-11-04 3:34 ` Wesley Parish 2024-11-04 17:35 ` Marc Rochkind 0 siblings, 1 reply; 31+ messages in thread From: Wesley Parish @ 2024-11-04 3:34 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: RIP Darl McBride former CEO of SCO 2024-11-04 3:34 ` Wesley Parish @ 2024-11-04 17:35 ` Marc Rochkind 2024-11-04 22:50 ` [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) Greg 'groggy' Lehey 0 siblings, 1 reply; 31+ messages in thread From: Marc Rochkind @ 2024-11-04 17:35 UTC (permalink / raw) To: Wesley Parish; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-04 17:35 ` Marc Rochkind @ 2024-11-04 22:50 ` Greg 'groggy' Lehey 2024-11-05 0:05 ` [TUHS] " Marc Rochkind 0 siblings, 1 reply; 31+ messages in thread From: Greg 'groggy' Lehey @ 2024-11-04 22:50 UTC (permalink / raw) To: Marc Rochkind; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-04 22:50 ` [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) Greg 'groggy' Lehey @ 2024-11-05 0:05 ` Marc Rochkind 2024-11-05 0:39 ` Warner Losh 2024-11-05 1:31 ` [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) Greg 'groggy' Lehey 0 siblings, 2 replies; 31+ messages in thread From: Marc Rochkind @ 2024-11-05 0:05 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 0:05 ` [TUHS] " Marc Rochkind @ 2024-11-05 0:39 ` Warner Losh 2024-11-05 1:09 ` Larry McVoy 2024-11-05 1:31 ` [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) Greg 'groggy' Lehey 1 sibling, 1 reply; 31+ messages in thread From: Warner Losh @ 2024-11-05 0:39 UTC (permalink / raw) To: Marc Rochkind; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 0:39 ` Warner Losh @ 2024-11-05 1:09 ` Larry McVoy 2024-11-05 1:32 ` ron minnich 2024-11-05 1:35 ` Warner Losh 0 siblings, 2 replies; 31+ messages in thread From: Larry McVoy @ 2024-11-05 1:09 UTC (permalink / raw) To: Warner Losh; +Cc: Marc Rochkind, tuhs 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 1:09 ` Larry McVoy @ 2024-11-05 1:32 ` ron minnich 2024-11-05 1:39 ` Warner Losh 2024-11-05 3:14 ` Larry McVoy 2024-11-05 1:35 ` Warner Losh 1 sibling, 2 replies; 31+ messages in thread From: ron minnich @ 2024-11-05 1:32 UTC (permalink / raw) To: Larry McVoy; +Cc: Marc Rochkind, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 1:32 ` ron minnich @ 2024-11-05 1:39 ` Warner Losh 2024-11-05 3:14 ` Larry McVoy 1 sibling, 0 replies; 31+ messages in thread From: Warner Losh @ 2024-11-05 1:39 UTC (permalink / raw) To: ron minnich; +Cc: Marc Rochkind, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 1:32 ` ron minnich 2024-11-05 1:39 ` Warner Losh @ 2024-11-05 3:14 ` Larry McVoy 2024-11-05 5:00 ` Warner Losh 1 sibling, 1 reply; 31+ messages in thread From: Larry McVoy @ 2024-11-05 3:14 UTC (permalink / raw) To: ron minnich; +Cc: Marc Rochkind, tuhs 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 3:14 ` Larry McVoy @ 2024-11-05 5:00 ` Warner Losh 0 siblings, 0 replies; 31+ messages in thread From: Warner Losh @ 2024-11-05 5:00 UTC (permalink / raw) To: Larry McVoy; +Cc: Marc Rochkind, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 1:09 ` Larry McVoy 2024-11-05 1:32 ` ron minnich @ 2024-11-05 1:35 ` Warner Losh 2024-11-05 1:54 ` Larry McVoy 1 sibling, 1 reply; 31+ messages in thread From: Warner Losh @ 2024-11-05 1:35 UTC (permalink / raw) To: Larry McVoy; +Cc: Marc Rochkind, tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 1:35 ` Warner Losh @ 2024-11-05 1:54 ` Larry McVoy 2024-11-05 2:13 ` Warner Losh 0 siblings, 1 reply; 31+ messages in thread From: Larry McVoy @ 2024-11-05 1:54 UTC (permalink / raw) To: Warner Losh; +Cc: Marc Rochkind, tuhs 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. ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 1:54 ` Larry McVoy @ 2024-11-05 2:13 ` Warner Losh 2024-11-05 3:14 ` Marc Rochkind 0 siblings, 1 reply; 31+ messages in thread From: Warner Losh @ 2024-11-05 2:13 UTC (permalink / raw) To: Larry McVoy; +Cc: Marc Rochkind, The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 2:13 ` Warner Losh @ 2024-11-05 3:14 ` Marc Rochkind 2024-11-07 20:41 ` ron minnich 2024-11-12 1:55 ` Kevin Bowling 0 siblings, 2 replies; 31+ messages in thread From: Marc Rochkind @ 2024-11-05 3:14 UTC (permalink / raw) To: imp; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 3:14 ` Marc Rochkind @ 2024-11-07 20:41 ` ron minnich 2024-11-07 20:59 ` Marc Rochkind 2024-11-12 1:55 ` Kevin Bowling 1 sibling, 1 reply; 31+ messages in thread From: ron minnich @ 2024-11-07 20:41 UTC (permalink / raw) To: Marc Rochkind; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-07 20:41 ` ron minnich @ 2024-11-07 20:59 ` Marc Rochkind 2024-11-08 0:03 ` Theodore Ts'o 2024-11-09 18:29 ` G. Branden Robinson 0 siblings, 2 replies; 31+ messages in thread From: Marc Rochkind @ 2024-11-07 20:59 UTC (permalink / raw) To: ron minnich; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-07 20:59 ` Marc Rochkind @ 2024-11-08 0:03 ` Theodore Ts'o 2024-11-08 0:35 ` Warner Losh 2024-11-09 18:29 ` G. Branden Robinson 1 sibling, 1 reply; 31+ messages in thread From: Theodore Ts'o @ 2024-11-08 0:03 UTC (permalink / raw) To: Marc Rochkind; +Cc: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-08 0:03 ` Theodore Ts'o @ 2024-11-08 0:35 ` Warner Losh 0 siblings, 0 replies; 31+ messages in thread From: Warner Losh @ 2024-11-08 0:35 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Marc Rochkind, The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-07 20:59 ` Marc Rochkind 2024-11-08 0:03 ` Theodore Ts'o @ 2024-11-09 18:29 ` G. Branden Robinson 2024-11-09 20:30 ` Theodore Ts'o 1 sibling, 1 reply; 31+ messages in thread From: G. Branden Robinson @ 2024-11-09 18:29 UTC (permalink / raw) To: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-09 18:29 ` G. Branden Robinson @ 2024-11-09 20:30 ` Theodore Ts'o 2024-11-09 22:23 ` G. Branden Robinson 0 siblings, 1 reply; 31+ messages in thread From: Theodore Ts'o @ 2024-11-09 20:30 UTC (permalink / raw) To: G. Branden Robinson; +Cc: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-09 20:30 ` Theodore Ts'o @ 2024-11-09 22:23 ` G. Branden Robinson 2024-11-10 4:27 ` Theodore Ts'o 0 siblings, 1 reply; 31+ messages in thread From: G. Branden Robinson @ 2024-11-09 22:23 UTC (permalink / raw) To: Theodore Ts'o; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-09 22:23 ` G. Branden Robinson @ 2024-11-10 4:27 ` Theodore Ts'o 0 siblings, 0 replies; 31+ messages in thread From: Theodore Ts'o @ 2024-11-10 4:27 UTC (permalink / raw) To: G. Branden Robinson; +Cc: coff (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. :-) ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-05 3:14 ` Marc Rochkind 2024-11-07 20:41 ` ron minnich @ 2024-11-12 1:55 ` Kevin Bowling 2024-11-12 2:34 ` Kevin Bowling 1 sibling, 1 reply; 31+ messages in thread From: Kevin Bowling @ 2024-11-12 1:55 UTC (permalink / raw) To: Marc Rochkind; +Cc: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-12 1:55 ` Kevin Bowling @ 2024-11-12 2:34 ` Kevin Bowling 2024-11-12 18:12 ` Marc Rochkind 0 siblings, 1 reply; 31+ messages in thread From: Kevin Bowling @ 2024-11-12 2:34 UTC (permalink / raw) To: Marc Rochkind; +Cc: The Eunuchs Hysterical Society 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) 2024-11-12 2:34 ` Kevin Bowling @ 2024-11-12 18:12 ` Marc Rochkind 0 siblings, 0 replies; 31+ messages in thread From: Marc Rochkind @ 2024-11-12 18:12 UTC (permalink / raw) To: Kevin Bowling; +Cc: The Eunuchs Hysterical Society [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) 2024-11-05 0:05 ` [TUHS] " Marc Rochkind 2024-11-05 0:39 ` Warner Losh @ 2024-11-05 1:31 ` Greg 'groggy' Lehey 2024-11-05 3:04 ` [TUHS] " Marc Rochkind 1 sibling, 1 reply; 31+ messages in thread From: Greg 'groggy' Lehey @ 2024-11-05 1:31 UTC (permalink / raw) To: Marc Rochkind; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) 2024-11-05 1:31 ` [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) Greg 'groggy' Lehey @ 2024-11-05 3:04 ` Marc Rochkind 2024-11-06 4:00 ` Greg 'groggy' Lehey 0 siblings, 1 reply; 31+ messages in thread From: Marc Rochkind @ 2024-11-05 3:04 UTC (permalink / raw) To: Greg 'groggy' Lehey; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] Re: IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) 2024-11-05 3:04 ` [TUHS] " Marc Rochkind @ 2024-11-06 4:00 ` Greg 'groggy' Lehey 0 siblings, 0 replies; 31+ messages in thread From: Greg 'groggy' Lehey @ 2024-11-06 4:00 UTC (permalink / raw) To: Marc Rochkind; +Cc: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 31+ messages in thread
* [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) @ 2024-11-05 13:40 Douglas McIlroy 0 siblings, 0 replies; 31+ messages in thread From: Douglas McIlroy @ 2024-11-05 13:40 UTC (permalink / raw) To: TUHS main list As a bit-part expert witness for the other side of the SCO case, I saw hundreds of pages of evidence in the form of side-by-side code comparison. As I recall, the vast majority of highlighted correspondences were small snippets, often rearranged. I didn't interact with the lawyers enough to form a solid opinion about where this stood on the spectrum of coincidence to fair use to plagiarism. It certainly wasn't wholesale copying. I do not recall being asked to opine on whether trade secrets had been stolen. Apropos of rearranged snippets, one of the diff algorithms I experimented with in the mid-70s identified rearrangements. I abandoned it because real life code contains lots of similar lines, so many in PDP-11 assembler programs as to suggest that these programs are largely permutations of each other. The phenomenon is much less common in C, but still present; witness the prevalence of code like int i, n; for(i=0; i<n; i++) { The phenomenon may have been afoot in the SCO evidence. In regard to trade secrets, I was surprised when I moved from Unix at Bell Labs to Linux at Dartmouth and found calendar(1) to be completely rewritten, but with logic absolutely identical to the original version I wrote at the Labs. That was so idiosyncratic that the identity of the two could not have been an accident. Doug ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2024-11-12 18:12 UTC | newest] Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-11-04 1:17 [TUHS] RIP Darl McBride former CEO of SCO Will Senn 2024-11-04 2:31 ` [TUHS] " Greg 'groggy' Lehey 2024-11-04 3:34 ` Wesley Parish 2024-11-04 17:35 ` Marc Rochkind 2024-11-04 22:50 ` [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) Greg 'groggy' Lehey 2024-11-05 0:05 ` [TUHS] " Marc Rochkind 2024-11-05 0:39 ` Warner Losh 2024-11-05 1:09 ` Larry McVoy 2024-11-05 1:32 ` ron minnich 2024-11-05 1:39 ` Warner Losh 2024-11-05 3:14 ` Larry McVoy 2024-11-05 5:00 ` Warner Losh 2024-11-05 1:35 ` Warner Losh 2024-11-05 1:54 ` Larry McVoy 2024-11-05 2:13 ` Warner Losh 2024-11-05 3:14 ` Marc Rochkind 2024-11-07 20:41 ` ron minnich 2024-11-07 20:59 ` Marc Rochkind 2024-11-08 0:03 ` Theodore Ts'o 2024-11-08 0:35 ` Warner Losh 2024-11-09 18:29 ` G. Branden Robinson 2024-11-09 20:30 ` Theodore Ts'o 2024-11-09 22:23 ` G. Branden Robinson 2024-11-10 4:27 ` Theodore Ts'o 2024-11-12 1:55 ` Kevin Bowling 2024-11-12 2:34 ` Kevin Bowling 2024-11-12 18:12 ` Marc Rochkind 2024-11-05 1:31 ` [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) Greg 'groggy' Lehey 2024-11-05 3:04 ` [TUHS] " Marc Rochkind 2024-11-06 4:00 ` Greg 'groggy' Lehey 2024-11-05 13:40 [TUHS] " Douglas McIlroy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).