From will.senn at gmail.com Mon Nov 4 11:17:03 2024 From: will.senn at gmail.com (Will Senn) Date: Sun, 3 Nov 2024 19:17:03 -0600 Subject: [TUHS] RIP Darl McBride former CEO of SCO Message-ID: 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 From grog at lemis.com Mon Nov 4 12:31:51 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 4 Nov 2024 13:31:51 +1100 Subject: [TUHS] RIP Darl McBride former CEO of SCO In-Reply-To: References: Message-ID: 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From wobblygong at gmail.com Mon Nov 4 13:34:29 2024 From: wobblygong at gmail.com (Wesley Parish) Date: Mon, 4 Nov 2024 16:34:29 +1300 Subject: [TUHS] RIP Darl McBride former CEO of SCO In-Reply-To: References: Message-ID: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> 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 at 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 From mrochkind at gmail.com Tue Nov 5 03:35:40 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Mon, 4 Nov 2024 10:35:40 -0700 Subject: [TUHS] RIP Darl McBride former CEO of SCO In-Reply-To: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: 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 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Tue Nov 5 08:50:35 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 5 Nov 2024 09:50:35 +1100 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From mrochkind at gmail.com Tue Nov 5 10:05:45 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Mon, 4 Nov 2024 17:05:45 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: 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 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 at 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 at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Nov 5 10:39:40 2024 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Nov 2024 17:39:40 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: On Mon, Nov 4, 2024 at 5:06 PM 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. 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 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 at 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 at gmail.com * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Nov 5 11:09:37 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 4 Nov 2024 17:09:37 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: <20241105010937.GC18296@mcvoy.com> 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 From grog at lemis.com Tue Nov 5 11:31:31 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Tue, 5 Nov 2024 12:31:31 +1100 Subject: [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From rminnich at gmail.com Tue Nov 5 11:32:19 2024 From: rminnich at gmail.com (ron minnich) Date: Mon, 4 Nov 2024 17:32:19 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241105010937.GC18296@mcvoy.com> References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> Message-ID: 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Nov 5 11:35:30 2024 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Nov 2024 18:35:30 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241105010937.GC18296@mcvoy.com> References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> Message-ID: On Mon, Nov 4, 2024 at 6:09 PM Larry McVoy 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Nov 5 11:39:25 2024 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Nov 2024 18:39:25 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> Message-ID: On Mon, Nov 4, 2024 at 6:32 PM 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. > 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 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 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Nov 5 11:54:00 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 4 Nov 2024 17:54:00 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> Message-ID: <20241105015400.GD18296@mcvoy.com> On Mon, Nov 04, 2024 at 06:35:30PM -0700, Warner Losh wrote: > On Mon, Nov 4, 2024 at 6:09???PM Larry McVoy 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. From imp at bsdimp.com Tue Nov 5 12:13:24 2024 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Nov 2024 19:13:24 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241105015400.GD18296@mcvoy.com> References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Tue Nov 5 13:04:38 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Mon, 4 Nov 2024 20:04:38 -0700 Subject: [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: 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 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 at 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 at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Tue Nov 5 13:14:19 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Mon, 4 Nov 2024 20:14:19 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: 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 wrote: > > > On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 wrote: >> > >> > > The thing I never got a reasonable answer to was I found code in BSD >> that >> > > was identical to code going back to at least V7. Find bmap() in the >> UFS >> > > code and then find the same in V7. I might be wrong about V7, might >> be >> > > 32V, might be V6. I don't think it matters, it's the same in all of >> them. >> > >> > >> > bmap() is the code that maps a logical block to a phsyical block, >> > > I'm quite familiar with it because I rewrote it to bmap_write() and >> > > bmap_read() as part of making UFS do extents: >> > > >> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf >> > > >> > > When all the lawsuits were going on, since I knew that code really >> well, >> > > I went off and looked and the BSD code at that time had bit for bit >> > > identical bmap() implementations. >> > > >> > > I never understood why BSD could claim they rewrote everything when >> they >> > > clearly had not rewritten that. >> > > >> > > I've raised this question before and I just went and looked, bmap() >> has >> > > changed. I'm pretty sure I have Kirk's BSD source releases, if I do, >> > > I'm 100% sure I can back up what I'm saying. Not sure I care enough >> to >> > > do so, it's all water under the bridge at this point. >> > > >> > >> > The short answer is that ffs_bmap.c was one of the 70 files that had >> > a AT&T copyright notice added to it as part of the AT&T vs Regents suit. >> > By the time 4.4BSD had been released, the file had been substantially >> > rewritten, but some traces of original AT&T code remained. >> >> Yeah, this is completely a false claim. It was identical. At least >> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing >> this out around then. >> > > 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very > different. I checked before I posted. So what i said is not false. I > literally had the code up side by side 20 minutes ago. It is definitely > different though clearly related and derived a bit. That function is > absolutely not 100% copied. > > For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug fixed >> BSD. If there ever was a guy that wanted this to be true, it's me. >> It's not true, BSD ripped off Bell Labs code, that's a fact. >> > > Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed a > AT&T license, prior to the ancient Unix license to get that. So there was > no claim to originality prior to 4.4. I didn't look at net/2 though. > > I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is on > disk different than v7fs I don't expect it to be identical. > > Warner > >> -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Nov 5 13:14:40 2024 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 4 Nov 2024 19:14:40 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> Message-ID: <20241105031440.GE18296@mcvoy.com> 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 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 From imp at bsdimp.com Tue Nov 5 15:00:45 2024 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Nov 2024 22:00:45 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241105031440.GE18296@mcvoy.com> References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105031440.GE18296@mcvoy.com> Message-ID: On Mon, Nov 4, 2024 at 8:14 PM Larry McVoy wrote: > The bmap implementations I saw were bit for bit identical, same code, same > variables, same style, same indentation. I'm 100% sure they were not > independent. 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 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Tue Nov 5 23:40:44 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Tue, 5 Nov 2024 08:40:44 -0500 Subject: [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) Message-ID: 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 > From: Warner Losh >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote: >> The bmap implementations I saw were bit for bit identical, same code, >> same variables, same style, same indentation. I'm 100% sure they were >> not independent. > They are different in 4.3BSD. They are different in 4.2BSD (but less > different). The underlying filesystems are different on disk, so they > routines have to be different. That last sentence points out something important that people need to remember in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD switched to the BSD Fast File System, so I very much doubt that the low-level (i.e. logical file block to disk block) file system code in anything after 4.1A looks much like the AT+T low-level file system code. (I have no idea how the BSD code compares to the Linux file system code, but that's between the Linux people, and Berkeley.) Noel From rminnich at gmail.com Wed Nov 6 04:52:04 2024 From: rminnich at gmail.com (ron minnich) Date: Tue, 5 Nov 2024 10:52:04 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241105175531.D180918C084@mercury.lcs.mit.edu> References: <20241105175531.D180918C084@mercury.lcs.mit.edu> Message-ID: I keep wondering if this assertion of code difference or lack thereof can be tested. Are not all these sources available? Which bits are missing? On Tue, Nov 5, 2024 at 9:55 AM Noel Chiappa wrote: > > From: Warner Losh > > >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote: > > >> The bmap implementations I saw were bit for bit identical, same > code, > >> same variables, same style, same indentation. I'm 100% sure they > were > >> not independent. > > > They are different in 4.3BSD. They are different in 4.2BSD (but less > > different). The underlying filesystems are different on disk, so they > > routines have to be different. > > That last sentence points out something important that people need to > remember > in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD > switched to the BSD Fast File System, so I very much doubt that the > low-level > (i.e. logical file block to disk block) file system code in anything after > 4.1A looks much like the AT+T low-level file system code. (I have no idea > how > the BSD code compares to the Linux file system code, but that's between the > Linux people, and Berkeley.) > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Nov 6 04:58:57 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 5 Nov 2024 11:58:57 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241105175531.D180918C084@mercury.lcs.mit.edu> References: <20241105175531.D180918C084@mercury.lcs.mit.edu> Message-ID: On Tue, Nov 5, 2024 at 10:55 AM Noel Chiappa wrote: > > From: Warner Losh > > >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote: > > >> The bmap implementations I saw were bit for bit identical, same > code, > >> same variables, same style, same indentation. I'm 100% sure they > were > >> not independent. > > > They are different in 4.3BSD. They are different in 4.2BSD (but less > > different). The underlying filesystems are different on disk, so they > > routines have to be different. > > That last sentence points out something important that people need to > remember > in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD > switched to the BSD Fast File System, so I very much doubt that the > low-level > (i.e. logical file block to disk block) file system code in anything after > 4.1A looks much like the AT+T low-level file system code. (I have no idea > how > the BSD code compares to the Linux file system code, but that's between the > Linux people, and Berkeley.) > Yes. The original unix code was copied and redone somewhat. It was still likely a derivative work (which is why AT&T forced Berkeley to redo it for 4.4-lite), but it was like 25% the same, 25% similar but functionally identical and 50% new for UFS, but filesystem layout is file system layout and some similarities persisted. 3bsd added dtofsb() calls. 4bsd added code to make accessing the indirect blocks more reliable and made writing directories more reliable. 4.1 was identical to 4bsd. 4.2 changed a lot. the 32V bmap was 112 lines long, while 4.2 was 196 lines with the following diffstat: 1 file changed, 141 insertions(+), 57 deletions(-) So by this measure, over half of the new function was new (though most of the comments were still the same). It did have the same structure, but structure isn't necessarily copyrightable since filesystem layout code will be similar between filesystems that are write-in-place. Looking at the diff, there's one stretch of 15 lines that are identical, but otherwise there's changes (mostly additions) every few lines. A substantial re-write. These days, most open source authors would replace the copyright statement with their own for such an extensive rewrite since the diff was over 2x the size of the original file (another very imperfect measure). Though the comments remaining identical is troublesome because they are the parts of the code that are the most creative and subject to the most freedom while the for loops and such are largely dictated by the problem or C language and customary style. Between 4.2 and 4.3, the changes were around the edges of this function though not in this function (I was remiss in not chasing down the bare diff I did last night). By net.2 it was re-written again, moving most of the function of bmap elsewhere, so that almost nothing remained from the original 32V in the original bmap function (though a quick grep shows that parts did move elsewhere). In net.2 it's back down to 75 lines. shorter even than in 32V (but it's a bit deceptive since the code was elsewhere, though also largely reworked). diff reports only lines '{', '}', '/*', '*/' and a few simple assignments (bap = bp->b_un.b_daddr;) and function calls (brelse(bp)) being the same and all the comments different / gone from this function. Though a fair number of the diffs were due to changes in the "buffer cache" interface, some formatting changes and some substitution of #defines (like NIADDR) for bare constants (3 in this case). These changes were also due to the role of bmap being reduced and things like balloc being used to handle the details a fair bit differently. And bits of balloc do resemble bits of the original bmap, but again the structure had changed somewhat. The numbers for my diffs and such are based on Krik's disks, but can also be tested by looking at the links I posted earlier or downloading and extracting the sources from the TUHS archive. The bmap() function I've extracted from different versions: https://people.freebsd.org/~imp/pmap/pmap.32v https://people.freebsd.org/~imp/pmap/pmap.4.2 https://people.freebsd.org/~imp/pmap/pmap.4.3 https://people.freebsd.org/~imp/pmap/pmap.net.2 Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Nov 6 05:01:49 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 5 Nov 2024 12:01:49 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <20241105175531.D180918C084@mercury.lcs.mit.edu> Message-ID: On Tue, Nov 5, 2024 at 11:52 AM ron minnich wrote: > I keep wondering if this assertion of code difference or lack thereof can > be tested. Are not all these sources available? Which bits are missing? > Yes. Great question. https://people.freebsd.org/~imp/pmap/pmap.32v https://people.freebsd.org/~imp/pmap/pmap.4.2 https://people.freebsd.org/~imp/pmap/pmap.4.3 https://people.freebsd.org/~imp/pmap/pmap.net.2 has the functions as I extracted them for the diff numbers I posted before. The TUHS archive links are at: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/subr.c https://www.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/src/sys/sys/subr.c https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/sys/ufs_bmap.c https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/src/sys/sys/ufs_bmap.c https://github.com/sergev/4.4BSD-Lite2/blob/master/usr/ src/sys/ufs/ufs/ufs_bmap.c in case anybody wants to check my math or characterizations about the differences. Warner > On Tue, Nov 5, 2024 at 9:55 AM Noel Chiappa > wrote: > >> > From: Warner Losh >> >> >> On Mon, Nov 4, 2024 at 8:14PM Larry McVoy wrote: >> >> >> The bmap implementations I saw were bit for bit identical, same >> code, >> >> same variables, same style, same indentation. I'm 100% sure they >> were >> >> not independent. >> >> > They are different in 4.3BSD. They are different in 4.2BSD (but less >> > different). The underlying filesystems are different on disk, so >> they >> > routines have to be different. >> >> That last sentence points out something important that people need to >> remember >> in this discussion: in between 4.1 and 4.2 (technically, in 4.1B), BSD >> switched to the BSD Fast File System, so I very much doubt that the >> low-level >> (i.e. logical file block to disk block) file system code in anything after >> 4.1A looks much like the AT+T low-level file system code. (I have no idea >> how >> the BSD code compares to the Linux file system code, but that's between >> the >> Linux people, and Berkeley.) >> >> Noel >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chopps at chopps.org Wed Nov 6 06:25:41 2024 From: chopps at chopps.org (Christian Hopps) Date: Tue, 5 Nov 2024 20:25:41 +0000 Subject: [TUHS] Copyrights and copying.. [was SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)] In-Reply-To: References: <20241105175531.D180918C084@mercury.lcs.mit.edu> Message-ID: > On Nov 5, 2024, at 18:58, Warner Losh wrote: … > These days, most open source authors would > replace the copyright statement with their own for such an extensive rewrite > since the diff was over 2x the size of the original file (another very imperfect > measure). Though the comments remaining identical is troublesome because > they are the parts of the code that are the most creative and subject to the > most freedom while the for loops and such are largely dictated by the problem > or C language and customary style. This was interesting to me. I’ve been writing various open source for 20+ years and I think maybe I was given a much stricter rule to follow when I started out and which I’ve followed since — it may very well be wrong but it’s what I’ve followed. If I started with some code with a copyright at the top, and I rewrote every line I would not replace the copyright but add mine to the file. I was told this was the correct action b/c you aren’t allowed to use the previous code as an aide to writing your new code and consider it only your own, it’s derivative in that case. Maybe this is just overly careful, but it’s what I’ve done in all my projects (starting back in the 90s with NetBSD and on to contributing to many other open source projects over time). Thanks, Chris. From imp at bsdimp.com Wed Nov 6 06:35:25 2024 From: imp at bsdimp.com (Warner Losh) Date: Tue, 5 Nov 2024 13:35:25 -0700 Subject: [TUHS] Copyrights and copying.. [was SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)] In-Reply-To: References: <20241105175531.D180918C084@mercury.lcs.mit.edu> Message-ID: On Tue, Nov 5, 2024, 1:25 PM Christian Hopps wrote: > > > > On Nov 5, 2024, at 18:58, Warner Losh wrote: > > … > > > These days, most open source authors would > > replace the copyright statement with their own for such an extensive > rewrite > > since the diff was over 2x the size of the original file (another very > imperfect > > measure). Though the comments remaining identical is troublesome because > > they are the parts of the code that are the most creative and subject to > the > > most freedom while the for loops and such are largely dictated by the > problem > > or C language and customary style. > > > This was interesting to me. I’ve been writing various open source for 20+ > years and I think maybe I was given a much stricter rule to follow when I > started out and which I’ve followed since — it may very well be wrong but > it’s what I’ve followed. > > If I started with some code with a copyright at the top, and I rewrote > every line I would not replace the copyright but add mine to the file. I > was told this was the correct action b/c you aren’t allowed to use the > previous code as an aide to writing your new code and consider it only your > own, it’s derivative in that case. > If you rewrote everything, that's an original work. There's nothing in copyright law that talks about process only the end result. While it is nice to leave yhe original copyright, it's not necessary when there's no original material left. And there is some incentive to remove it because you don't want to incorrectly represent who has IP in the file. Maybe this is just overly careful, but it’s what I’ve done in all my > projects (starting back in the 90s with NetBSD and on to contributing to > many other open source projects over time). > Yea. While many would replace the copyright for the scenario I described, many would add their copyright. It's a judgment call: are the changes transformative to the work or not? There are several creators that take old Disney film footage and legally remox it into something new. The original is clearly there, but changed enough to be outside copyright protection. Sadly, there are no simple, universal rules that let you do this analysis completely mechanically. Warner Thanks, > Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Nov 6 14:00:34 2024 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 6 Nov 2024 15:00:34 +1100 Subject: [TUHS] IBM's involvement (was: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO)) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> Message-ID: 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 at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From rminnich at gmail.com Fri Nov 8 06:41:31 2024 From: rminnich at gmail.com (ron minnich) Date: Thu, 7 Nov 2024 12:41:31 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: 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 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 wrote: > >> >> >> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 wrote: >>> > >>> > > The thing I never got a reasonable answer to was I found code in BSD >>> that >>> > > was identical to code going back to at least V7. Find bmap() in the >>> UFS >>> > > code and then find the same in V7. I might be wrong about V7, might >>> be >>> > > 32V, might be V6. I don't think it matters, it's the same in all of >>> them. >>> > >>> > >>> > bmap() is the code that maps a logical block to a phsyical block, >>> > > I'm quite familiar with it because I rewrote it to bmap_write() and >>> > > bmap_read() as part of making UFS do extents: >>> > > >>> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf >>> > > >>> > > When all the lawsuits were going on, since I knew that code really >>> well, >>> > > I went off and looked and the BSD code at that time had bit for bit >>> > > identical bmap() implementations. >>> > > >>> > > I never understood why BSD could claim they rewrote everything when >>> they >>> > > clearly had not rewritten that. >>> > > >>> > > I've raised this question before and I just went and looked, bmap() >>> has >>> > > changed. I'm pretty sure I have Kirk's BSD source releases, if I do, >>> > > I'm 100% sure I can back up what I'm saying. Not sure I care enough >>> to >>> > > do so, it's all water under the bridge at this point. >>> > > >>> > >>> > The short answer is that ffs_bmap.c was one of the 70 files that had >>> > a AT&T copyright notice added to it as part of the AT&T vs Regents >>> suit. >>> > By the time 4.4BSD had been released, the file had been substantially >>> > rewritten, but some traces of original AT&T code remained. >>> >>> Yeah, this is completely a false claim. It was identical. At least >>> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing >>> this out around then. >>> >> >> 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very >> different. I checked before I posted. So what i said is not false. I >> literally had the code up side by side 20 minutes ago. It is definitely >> different though clearly related and derived a bit. That function is >> absolutely not 100% copied. >> >> For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug fixed >>> BSD. If there ever was a guy that wanted this to be true, it's me. >>> It's not true, BSD ripped off Bell Labs code, that's a fact. >>> >> >> Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed a >> AT&T license, prior to the ancient Unix license to get that. So there was >> no claim to originality prior to 4.4. I didn't look at net/2 though. >> >> I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is on >> disk different than v7fs I don't expect it to be identical. >> >> Warner >> >>> > > -- > *My new email address is mrochkind at gmail.com * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrochkind at gmail.com Fri Nov 8 06:59:18 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Thu, 7 Nov 2024 13:59:18 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: 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 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 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 wrote: >> >>> >>> >>> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 wrote: >>>> > >>>> > > The thing I never got a reasonable answer to was I found code in >>>> BSD that >>>> > > was identical to code going back to at least V7. Find bmap() in >>>> the UFS >>>> > > code and then find the same in V7. I might be wrong about V7, >>>> might be >>>> > > 32V, might be V6. I don't think it matters, it's the same in all >>>> of them. >>>> > >>>> > >>>> > bmap() is the code that maps a logical block to a phsyical block, >>>> > > I'm quite familiar with it because I rewrote it to bmap_write() and >>>> > > bmap_read() as part of making UFS do extents: >>>> > > >>>> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf >>>> > > >>>> > > When all the lawsuits were going on, since I knew that code really >>>> well, >>>> > > I went off and looked and the BSD code at that time had bit for bit >>>> > > identical bmap() implementations. >>>> > > >>>> > > I never understood why BSD could claim they rewrote everything when >>>> they >>>> > > clearly had not rewritten that. >>>> > > >>>> > > I've raised this question before and I just went and looked, bmap() >>>> has >>>> > > changed. I'm pretty sure I have Kirk's BSD source releases, if I >>>> do, >>>> > > I'm 100% sure I can back up what I'm saying. Not sure I care >>>> enough to >>>> > > do so, it's all water under the bridge at this point. >>>> > > >>>> > >>>> > The short answer is that ffs_bmap.c was one of the 70 files that had >>>> > a AT&T copyright notice added to it as part of the AT&T vs Regents >>>> suit. >>>> > By the time 4.4BSD had been released, the file had been substantially >>>> > rewritten, but some traces of original AT&T code remained. >>>> >>>> Yeah, this is completely a false claim. It was identical. At least >>>> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing >>>> this out around then. >>>> >>> >>> 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very >>> different. I checked before I posted. So what i said is not false. I >>> literally had the code up side by side 20 minutes ago. It is definitely >>> different though clearly related and derived a bit. That function is >>> absolutely not 100% copied. >>> >>> For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug fixed >>>> BSD. If there ever was a guy that wanted this to be true, it's me. >>>> It's not true, BSD ripped off Bell Labs code, that's a fact. >>>> >>> >>> Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed a >>> AT&T license, prior to the ancient Unix license to get that. So there was >>> no claim to originality prior to 4.4. I didn't look at net/2 though. >>> >>> I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is on >>> disk different than v7fs I don't expect it to be identical. >>> >>> Warner >>> >>>> >> >> -- >> *My new email address is mrochkind at gmail.com * >> > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Nov 8 10:03:11 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 7 Nov 2024 19:03:11 -0500 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: <20241108000311.GB4141@mit.edu> 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 From imp at bsdimp.com Fri Nov 8 10:35:22 2024 From: imp at bsdimp.com (Warner Losh) Date: Thu, 7 Nov 2024 16:35:22 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241108000311.GB4141@mit.edu> References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> <20241108000311.GB4141@mit.edu> Message-ID: On Thu, Nov 7, 2024 at 4:03 PM Theodore Ts'o 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Nov 9 06:27:04 2024 From: imp at bsdimp.com (Warner Losh) Date: Fri, 8 Nov 2024 12:27:04 -0800 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <20241105175531.D180918C084@mercury.lcs.mit.edu> Message-ID: On Fri, Nov 8, 2024, 6:20 AM Dan Cross wrote: > On Tue, Nov 5, 2024 at 2:02 PM Warner Losh wrote: > > On Tue, Nov 5, 2024 at 11:52 AM ron minnich wrote: > >> I keep wondering if this assertion of code difference or lack thereof > can be tested. Are not all these sources available? Which bits are missing? > > > > Yes. Great question. > > > > https://people.freebsd.org/~imp/pmap/pmap.32v > > https://people.freebsd.org/~imp/pmap/pmap.4.2 > > https://people.freebsd.org/~imp/pmap/pmap.4.3 > > https://people.freebsd.org/~imp/pmap/pmap.net.2 > > Hmm; these all 404 for me? Doh! Too much muscle memory. Those should all be bmap: https://people.freebsd.org/~imp/bmap/bmap.32v https://people.freebsd.org/~imp/bmap/bmap.4.2 https://people.freebsd.org/~imp/bmap/bmap.4.3 https://people.freebsd.org/~imp/bmap/bmap.net.2 which shows the progression before the rewrite in 4.4BSD-lite. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Nov 9 09:18:20 2024 From: imp at bsdimp.com (Warner Losh) Date: Fri, 8 Nov 2024 15:18:20 -0800 Subject: [TUHS] Fwd: SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <20241105175531.D180918C084@mercury.lcs.mit.edu> <61F8BCE5-44C5-49D2-BEFE-B8717E3DDEA8@kdbarto.org> Message-ID: ---------- Forwarded message --------- From: Warner Losh Date: Fri, Nov 8, 2024 at 3:17 PM Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) To: David Barto On Fri, Nov 8, 2024 at 1:07 PM David Barto wrote: > > > On Nov 8, 2024, at 12:27 PM, Warner Losh wrote: > > > > On Fri, Nov 8, 2024, 6:20 AM Dan Cross wrote: > >> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh wrote: >> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich wrote: >> >> I keep wondering if this assertion of code difference or lack thereof >> can be tested. Are not all these sources available? Which bits are missing? >> > >> > Yes. Great question. >> > >> > https://people.freebsd.org/~imp/pmap/pmap.32v >> > https://people.freebsd.org/~imp/pmap/pmap.4.2 >> > https://people.freebsd.org/~imp/pmap/pmap.4.3 >> > https://people.freebsd.org/~imp/pmap/pmap.net.2 >> >> Hmm; these all 404 for me? > > > Doh! Too much muscle memory. Those should all be bmap: > > https://people.freebsd.org/~imp/bmap/bmap.32v > > https://people.freebsd.org/~imp/bmap/bmap.4.2 > > https://people.freebsd.org/~imp/bmap/bmap.4.3 > > https://people.freebsd.org/~imp/bmap/bmap.net.2 > > > https://people.freebsd.org/~imp/bmap/bmap.32v https://people.freebsd.org/~imp/bmap/bmap.4.2 https://people.freebsd.org/~imp/bmap/bmap.4.3 https://people.freebsd.org/~imp/bmap/bmap.net.2 Not sure why the previous... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at atvetsystems.com Sat Nov 9 10:40:22 2024 From: rob at atvetsystems.com (rob at atvetsystems.com) Date: Sat, 9 Nov 2024 00:40:22 +0000 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <20241105175531.D180918C084@mercury.lcs.mit.edu> <61F8BCE5-44C5-49D2-BEFE-B8717E3DDEA8@kdbarto.org> Message-ID: I went to one of the SCO forum events at Santa Cruz at the time and I vaguely remember someone having a chat to use and saying that the dispute was that SCO and IBM were working on project Monterey and some of the SCO SMP code found its way into Linux. At the time SCO felt that Linux was several years behind on SMP so getting the SMP code would remove the SCO advantage at a time when processors were getting more cores. This may have been more to do with the IBM -vs- SCO contract case. Regards, Rob. > On 8 Nov 2024, at 23:18, Warner Losh wrote: > > > > ---------- Forwarded message --------- > From: Warner Losh > > Date: Fri, Nov 8, 2024 at 3:17 PM > Subject: Re: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) > To: David Barto > > > > > > On Fri, Nov 8, 2024 at 1:07 PM David Barto > wrote: > > >> On Nov 8, 2024, at 12:27 PM, Warner Losh > wrote: >> >> >> >> On Fri, Nov 8, 2024, 6:20 AM Dan Cross > wrote: >> On Tue, Nov 5, 2024 at 2:02 PM Warner Losh > wrote: >> > On Tue, Nov 5, 2024 at 11:52 AM ron minnich > wrote: >> >> I keep wondering if this assertion of code difference or lack thereof can be tested. Are not all these sources available? Which bits are missing? >> > >> > Yes. Great question. >> > >> > https://people.freebsd.org/~imp/pmap/pmap.32v >> > https://people.freebsd.org/~imp/pmap/pmap.4.2 >> > https://people.freebsd.org/~imp/pmap/pmap.4.3 >> > https://people.freebsd.org/~imp/pmap/pmap.net.2 >> >> Hmm; these all 404 for me? >> >> Doh! Too much muscle memory. Those should all be bmap: >> >> https://people.freebsd.org/~imp/bmap/bmap.32v >> https://people.freebsd.org/~imp/bmap/bmap.4.2 >> https://people.freebsd.org/~imp/bmap/bmap.4.3 >> https://people.freebsd.org/~imp/bmap/bmap.net.2 > https://people.freebsd.org/~imp/bmap/bmap.32v > https://people.freebsd.org/~imp/bmap/bmap.4.2 > https://people.freebsd.org/~imp/bmap/bmap.4.3 > https://people.freebsd.org/~imp/bmap/bmap.net.2 > > Not sure why the previous... > > Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.branden.robinson at gmail.com Sun Nov 10 04:29:55 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 9 Nov 2024 12:29:55 -0600 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: <20241109182955.m2uoditi3muvg2vg@illithid> 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... ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tytso at mit.edu Sun Nov 10 06:30:01 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 9 Nov 2024 15:30:01 -0500 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241109182955.m2uoditi3muvg2vg@illithid> References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> <20241109182955.m2uoditi3muvg2vg@illithid> Message-ID: <20241109203001.GA1828993@mit.edu> 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 From g.branden.robinson at gmail.com Sun Nov 10 08:23:34 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Sat, 9 Nov 2024 16:23:34 -0600 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241109203001.GA1828993@mit.edu> References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> <20241109182955.m2uoditi3muvg2vg@illithid> <20241109203001.GA1828993@mit.edu> Message-ID: <20241109222334.gy27tvoh5fpbovts@illithid> 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 at 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tytso at mit.edu Sun Nov 10 14:27:37 2024 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 9 Nov 2024 23:27:37 -0500 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: <20241109222334.gy27tvoh5fpbovts@illithid> References: <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> <20241109182955.m2uoditi3muvg2vg@illithid> <20241109203001.GA1828993@mit.edu> <20241109222334.gy27tvoh5fpbovts@illithid> Message-ID: <20241110042737.GB21941@mit.edu> (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. :-) From kevin.bowling at kev009.com Tue Nov 12 11:55:52 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 11 Nov 2024 18:55:52 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: On Mon, Nov 4, 2024 at 8:14 PM Marc Rochkind 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 wrote: >> >> >> >> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 wrote: >>> > >>> > > The thing I never got a reasonable answer to was I found code in BSD that >>> > > was identical to code going back to at least V7. Find bmap() in the UFS >>> > > code and then find the same in V7. I might be wrong about V7, might be >>> > > 32V, might be V6. I don't think it matters, it's the same in all of them. >>> > >>> > >>> > bmap() is the code that maps a logical block to a phsyical block, >>> > > I'm quite familiar with it because I rewrote it to bmap_write() and >>> > > bmap_read() as part of making UFS do extents: >>> > > >>> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf >>> > > >>> > > When all the lawsuits were going on, since I knew that code really well, >>> > > I went off and looked and the BSD code at that time had bit for bit >>> > > identical bmap() implementations. >>> > > >>> > > I never understood why BSD could claim they rewrote everything when they >>> > > clearly had not rewritten that. >>> > > >>> > > I've raised this question before and I just went and looked, bmap() has >>> > > changed. I'm pretty sure I have Kirk's BSD source releases, if I do, >>> > > I'm 100% sure I can back up what I'm saying. Not sure I care enough to >>> > > do so, it's all water under the bridge at this point. >>> > > >>> > >>> > The short answer is that ffs_bmap.c was one of the 70 files that had >>> > a AT&T copyright notice added to it as part of the AT&T vs Regents suit. >>> > By the time 4.4BSD had been released, the file had been substantially >>> > rewritten, but some traces of original AT&T code remained. >>> >>> Yeah, this is completely a false claim. It was identical. At least >>> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing >>> this out around then. >> >> >> 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very different. I checked before I posted. So what i said is not false. I literally had the code up side by side 20 minutes ago. It is definitely different though clearly related and derived a bit. That function is absolutely not 100% copied. >> >>> For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug fixed >>> BSD. If there ever was a guy that wanted this to be true, it's me. >>> It's not true, BSD ripped off Bell Labs code, that's a fact. >> >> >> Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed a AT&T license, prior to the ancient Unix license to get that. So there was no claim to originality prior to 4.4. I didn't look at net/2 though. >> >> I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is on disk different than v7fs I don't expect it to be identical. >> >> Warner > > > > -- > My new email address is mrochkind at gmail.com From kevin.bowling at kev009.com Tue Nov 12 12:34:39 2024 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 11 Nov 2024 19:34:39 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: On Mon, Nov 11, 2024 at 6:55 PM Kevin Bowling wrote: > > On Mon, Nov 4, 2024 at 8:14 PM Marc Rochkind 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 wrote: > >> > >> > >> > >> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 wrote: > >>> > > >>> > > The thing I never got a reasonable answer to was I found code in BSD that > >>> > > was identical to code going back to at least V7. Find bmap() in the UFS > >>> > > code and then find the same in V7. I might be wrong about V7, might be > >>> > > 32V, might be V6. I don't think it matters, it's the same in all of them. > >>> > > >>> > > >>> > bmap() is the code that maps a logical block to a phsyical block, > >>> > > I'm quite familiar with it because I rewrote it to bmap_write() and > >>> > > bmap_read() as part of making UFS do extents: > >>> > > > >>> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf > >>> > > > >>> > > When all the lawsuits were going on, since I knew that code really well, > >>> > > I went off and looked and the BSD code at that time had bit for bit > >>> > > identical bmap() implementations. > >>> > > > >>> > > I never understood why BSD could claim they rewrote everything when they > >>> > > clearly had not rewritten that. > >>> > > > >>> > > I've raised this question before and I just went and looked, bmap() has > >>> > > changed. I'm pretty sure I have Kirk's BSD source releases, if I do, > >>> > > I'm 100% sure I can back up what I'm saying. Not sure I care enough to > >>> > > do so, it's all water under the bridge at this point. > >>> > > > >>> > > >>> > The short answer is that ffs_bmap.c was one of the 70 files that had > >>> > a AT&T copyright notice added to it as part of the AT&T vs Regents suit. > >>> > By the time 4.4BSD had been released, the file had been substantially > >>> > rewritten, but some traces of original AT&T code remained. > >>> > >>> Yeah, this is completely a false claim. It was identical. At least > >>> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing > >>> this out around then. > >> > >> > >> 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very different. I checked before I posted. So what i said is not false. I literally had the code up side by side 20 minutes ago. It is definitely different though clearly related and derived a bit. That function is absolutely not 100% copied. > >> > >>> For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug fixed > >>> BSD. If there ever was a guy that wanted this to be true, it's me. > >>> It's not true, BSD ripped off Bell Labs code, that's a fact. > >> > >> > >> Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed a AT&T license, prior to the ancient Unix license to get that. So there was no claim to originality prior to 4.4. I didn't look at net/2 though. > >> > >> I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is on disk different than v7fs I don't expect it to be identical. > >> > >> Warner > > > > > > > > -- > > My new email address is mrochkind at gmail.com From mrochkind at gmail.com Wed Nov 13 04:12:12 2024 From: mrochkind at gmail.com (Marc Rochkind) Date: Tue, 12 Nov 2024 11:12:12 -0700 Subject: [TUHS] SCO's "evidence" (was: RIP Darl McBride former CEO of SCO) In-Reply-To: References: <52a0ed21-2703-464d-b2e2-72fb44325d47@gmail.com> <20241105010937.GC18296@mcvoy.com> <20241105015400.GD18296@mcvoy.com> Message-ID: 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 wrote: > On Mon, Nov 11, 2024 at 6:55 PM Kevin Bowling > wrote: > > > > On Mon, Nov 4, 2024 at 8:14 PM Marc Rochkind > 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 wrote: > > >> > > >> > > >> > > >> On Mon, Nov 4, 2024, 6:54 PM Larry McVoy 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 wrote: > > >>> > > > >>> > > The thing I never got a reasonable answer to was I found code in > BSD that > > >>> > > was identical to code going back to at least V7. Find bmap() in > the UFS > > >>> > > code and then find the same in V7. I might be wrong about V7, > might be > > >>> > > 32V, might be V6. I don't think it matters, it's the same in > all of them. > > >>> > > > >>> > > > >>> > bmap() is the code that maps a logical block to a phsyical block, > > >>> > > I'm quite familiar with it because I rewrote it to bmap_write() > and > > >>> > > bmap_read() as part of making UFS do extents: > > >>> > > > > >>> > > http://mcvoy.com/lm/papers/SunOS.ufs_clustering.pdf > > >>> > > > > >>> > > When all the lawsuits were going on, since I knew that code > really well, > > >>> > > I went off and looked and the BSD code at that time had bit for > bit > > >>> > > identical bmap() implementations. > > >>> > > > > >>> > > I never understood why BSD could claim they rewrote everything > when they > > >>> > > clearly had not rewritten that. > > >>> > > > > >>> > > I've raised this question before and I just went and looked, > bmap() has > > >>> > > changed. I'm pretty sure I have Kirk's BSD source releases, if > I do, > > >>> > > I'm 100% sure I can back up what I'm saying. Not sure I care > enough to > > >>> > > do so, it's all water under the bridge at this point. > > >>> > > > > >>> > > > >>> > The short answer is that ffs_bmap.c was one of the 70 files that > had > > >>> > a AT&T copyright notice added to it as part of the AT&T vs Regents > suit. > > >>> > By the time 4.4BSD had been released, the file had been > substantially > > >>> > rewritten, but some traces of original AT&T code remained. > > >>> > > >>> Yeah, this is completely a false claim. It was identical. At least > > >>> in 4.3 BSD, I can imagine that 4.4 changed it because I was pointing > > >>> this out around then. > > >> > > >> > > >> 4.3bsd wasn't claimed to be a rewrite. 4.4bsd definitely was very > different. I checked before I posted. So what i said is not false. I > literally had the code up side by side 20 minutes ago. It is definitely > different though clearly related and derived a bit. That function is > absolutely not 100% copied. > > >> > > >>> For the record, I'm a BSD guy, my OS was SunOS 4.x, it was a bug > fixed > > >>> BSD. If there ever was a guy that wanted this to be true, it's me. > > >>> It's not true, BSD ripped off Bell Labs code, that's a fact. > > >> > > >> > > >> Except not in 4.4. 4.3 never was claimed to be a rewrite. You needed > a AT&T license, prior to the ancient Unix license to get that. So there was > no claim to originality prior to 4.4. I didn't look at net/2 though. > > >> > > >> I'll check after dinner for 4.3bsd and 4.2bsd, but since FFS/UFS is > on disk different than v7fs I don't expect it to be identical. > > >> > > >> Warner > > > > > > > > > > > > -- > > > My new email address is mrochkind at gmail.com > -- *My new email address is mrochkind at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.txt at gmail.com Mon Nov 18 21:28:35 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 18 Nov 2024 11:28:35 -0000 (UTC) Subject: [TUHS] Looking for historical vi sources Message-ID: Hello, all. Have you an idea where one could find the sources of the various versions of the ex/vi editor, besides those archived at TUHS: 1BSD/ex-1.1 2.11BSD/src/ucb/ex 2.9BSD/usr/src/ucb/ex/ex2 2.9BSD/usr/src/ucb/ex/ex3 2BSD/src/ex 3BSD/usr/src/cmd/ex 4.1cBSD/usr/src/ucb/ex 4.2BSD/usr/src/ucb/ex 4.3BSD-Reno/src/usr.bin/ex 4.3BSD-Tahoe/usr/src/ucb 4.3BSD-UWisc/src/ucb/ex 4.3BSD/usr/src/ucb/ex 4.4BSD/usr/src/usr.bin/ex 4BSD/usr/src/cmd/ex OpenSolaris_b135/cmd/vi There include vv. 1.1, 2.13, 3.2, 3.6, and many variants of 3.7. Has anything else been preserved to your knowledge? From anton.txt at gmail.com Mon Nov 18 22:00:41 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 18 Nov 2024 12:00:41 -0000 (UTC) Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: Dan Cross wrote: >Programmer ability is certainly an issue, but I would suggest that >another goes back to what Rob was alluding to: compiler writers have >taken too much advantage of UB, making it difficult to write >well-formed programs that last. Following the letter, rather than the spirit, of the standard? >The `realloc` function I mentioned earlier is a good case in point; >the first ANSI C standard says this: "If ptr is a null pointer, the >realloc function behaves like the malloc function for the specified >size. ... If size is zero and ptr is not a null pointer, the object it >points to is freed." While the description of `malloc` doesn't say >thing about what happens when `size` is 0, perhaps making `realloc(0, >NULL)` nominally UB (??), the behavior of `realloc(0, ptr)` is clearly >well defined when `ptr` is not nil, and it's entirely possible that >programs were written with that well-defined behavior as an >assumption. (Worth mentioning is that this language was changed in >C99, and implementations started differing from there.) > >But now, C23 has made `realloc(0, ptr)` UB, regardless of the value of >`ptr` Something similar happened with so-called strict aliasing, when the compilers started assuming pointers to incompatible types as always pointer to different non-overlapping locations: See, e.g.: Linus ranterd about it: >My sense is that tossing in bad programmers is just throwing gasoline >onto a dumpster fire. Particularly when they look to charlatans like >Robert Martin or Allen Holub as sources of education and inspiration >instead of seeking out proper sources of education. I am a bad one as well, to have liked some things in Martin's books /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor Dijxtra, nor Knuth, but why a charlatan? From luther.johnson at makerlisp.com Mon Nov 18 22:46:04 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Mon, 18 Nov 2024 05:46:04 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: C, Lisp, and probably many other languages have gone through a similar historical arc - first they are designed to solve problems, and be a useful and powerful means of expression - then they become official, standardized, and legalistic - then they become commercially competitive, and leverage the legalisms, benchmarks, and other collateral that has accrued - at this point, generations later, the language is evolving with no appreciation or understanding of the aesthetic and practical principles of the original language effort. My old-man-grousing for today. On 11/18/2024 05:00 AM, Anton Shepelev wrote: > Dan Cross wrote: > >> Programmer ability is certainly an issue, but I would suggest that >> another goes back to what Rob was alluding to: compiler writers have >> taken too much advantage of UB, making it difficult to write >> well-formed programs that last. > Following the letter, rather than the spirit, of the standard? > >> The `realloc` function I mentioned earlier is a good case in point; >> the first ANSI C standard says this: "If ptr is a null pointer, the >> realloc function behaves like the malloc function for the specified >> size. ... If size is zero and ptr is not a null pointer, the object it >> points to is freed." While the description of `malloc` doesn't say >> thing about what happens when `size` is 0, perhaps making `realloc(0, >> NULL)` nominally UB (??), the behavior of `realloc(0, ptr)` is clearly >> well defined when `ptr` is not nil, and it's entirely possible that >> programs were written with that well-defined behavior as an >> assumption. (Worth mentioning is that this language was changed in >> C99, and implementations started differing from there.) >> >> But now, C23 has made `realloc(0, ptr)` UB, regardless of the value of >> `ptr` > Something similar happened with so-called strict aliasing, when the > compilers started assuming pointers to incompatible types as always > pointer to different non-overlapping locations: > > See, e.g.: > Linus ranterd about it: > >> My sense is that tossing in bad programmers is just throwing gasoline >> onto a dumpster fire. Particularly when they look to charlatans like >> Robert Martin or Allen Holub as sources of education and inspiration >> instead of seeking out proper sources of education. > I am a bad one as well, to have liked some things in Martin's books > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor > Dijxtra, nor Knuth, but why a charlatan? > > From usotsuki at buric.co Tue Nov 19 00:05:37 2024 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 18 Nov 2024 09:05:37 -0500 (EST) Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, 18 Nov 2024, Luther Johnson wrote: > C, Lisp, and probably many other languages have gone through a similar > historical arc - first they are designed to solve problems, and be a > useful and powerful means of expression - then they become official, > standardized, and legalistic - then they become commercially > competitive, and leverage the legalisms, benchmarks, and other > collateral that has accrued - at this point, generations later, the > language is evolving with no appreciation or understanding of the > aesthetic and practical principles of the original language effort. > > My old-man-grousing for today. I feel like most of the changes to C after C89 were a waste. Apart from stdint.h, I mostly keep to coding in strict C89. -uso. From anton.txt at gmail.com Tue Nov 19 00:55:55 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 18 Nov 2024 14:55:55 -0000 (UTC) Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: Luther Johnson wrote: >C, Lisp, and probably many other languages have gone through a similar >historical arc - first they are designed to solve problems, and be a >useful and powerful means of expression - then they become official, >standardized, and legalistic - then they become commercially >competitive, and leverage the legalisms, benchmarks, and other >collateral that has accrued - at this point, generations later, the >language is evolving with no appreciation or understanding of the >aesthetic and practical principles of the original language effort. Yes, big money makes things strive not for excellence but for accessibility and a low, if not negative, entry threshold. When a language ends up catering to the majority, or developed by a commitee instead of a close-knit yet open society of loving and caring enthusiasts, it undergoes the process above on the way to become usable by volatile teams of poor programmers indoctrinated with doing as everybody else does in order to be understood (which means blingliy following whatver standards and practices are enforced), with any aspiration burned out of actualy inventing things or least experimenting creatively. From anton.txt at gmail.com Tue Nov 19 01:00:22 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 18 Nov 2024 15:00:22 -0000 (UTC) Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: Steve Nickolas wrote: > >I feel like most of the changes to C after C89 were a waste. Apart >from stdint.h, I mostly keep to coding in strict C89. And then I must not only specfy std-c89 in GCC, but add --pedantic, too. There is even a --pedantic club: . From g.branden.robinson at gmail.com Tue Nov 19 02:52:29 2024 From: g.branden.robinson at gmail.com (G. Branden Robinson) Date: Mon, 18 Nov 2024 10:52:29 -0600 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <20241118165229.7o735e6l3qsxmdqz@illithid> At 2024-11-18T14:55:55-0000, Anton Shepelev wrote: > Yes, big money makes things strive not for excellence but for > accessibility and a low, if not negative, entry threshold. I think that's an overgeneralization. The Ada language, for example, drew much wariness and even criticism for being funded by the U.S. Department of Defense, probably the most profligate spender in the history of mankind,[1] and at the same time was condemned for being too hard a language to grasp (too "big") and too hard to write a compiler for. Further, I would argue that Ada was indeed an excellent language, certainly for its time and arguably still. But it was not easy to acquire by programmers who took an absolutely slovenly attitude toward data type discipline, a characterization that fits many pre-ANSI C programmers perfectly. Perhaps those who learn how to manage data types using C as their first language suffer irrevocable brain damage, and are fit subjects for pity and mockery. You won't find _that_ opinion in the Jargon File. Regards, Branden [1] https://www.npr.org/2021/05/19/997961646/the-pentagon-has-never-passed-an-audit-some-senators-want-to-change-that -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From anton.txt at gmail.com Tue Nov 19 03:00:49 2024 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 18 Nov 2024 17:00:49 -0000 (UTC) Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> <20241118165229.7o735e6l3qsxmdqz@illithid> Message-ID: G. Branden Robinson wrote: > >At 2024-11-18T14:55:55-0000, Anton Shepelev wrote: >> Yes, big money makes things strive not for excellence but for >> accessibility and a low, if not negative, entry threshold. > >I think that's an overgeneralization. > >The Ada language, for example, drew much wariness and even criticism for >being funded by the U.S. Department of Defense, probably the most >profligate spender in the history of mankind,[1] and at the same time >was condemned for being too hard a language to grasp (too "big") and too >hard to write a compiler for. >[...] I have nothing against Ada myself, but was referring the popular languages in demand on the market. I think Julia is harder than Ada. From luther.johnson at makerlisp.com Tue Nov 19 04:56:26 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Mon, 18 Nov 2024 11:56:26 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: <20241118165229.7o735e6l3qsxmdqz@illithid> References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> <20241118165229.7o735e6l3qsxmdqz@illithid> Message-ID: I think both Ada and VHDL, started formally, and proceeded formally. I don't have experience with either of them, but from the outside they appear to be competent and rational. I was mostly commenting on early C and Lisp (or Verilog is another example, although I think Verilog has stayed pretty close to the original versions), of being less formal, with more implicit defaults, that just do pretty much what you would expect them to, which gives a great deal of concise leverage. Some of that gets lost when the language gets more formally "correct" or "complete", or you have to be more verbose, or maybe just stay away from certain constructs altogether, if you're not willing to qualify to the nth degree. And so, the later variants become less useful (to me) than the original versions. It's true that the first, informal versions of these languages, do require us to understand, and buy in to, the mindset of the language inventors. But with the later versions, you have to devour 1000 pages of detail from the standards committee. Which gets us to working, productive code faster ? Some prefer one path, some prefer another, but I like to learn the point of view and approach of the original authors, to me it's like reading a novel compared to reading an encyclopedia. On 11/18/2024 09:52 AM, G. Branden Robinson wrote: > At 2024-11-18T14:55:55-0000, Anton Shepelev wrote: >> Yes, big money makes things strive not for excellence but for >> accessibility and a low, if not negative, entry threshold. > I think that's an overgeneralization. > > The Ada language, for example, drew much wariness and even criticism for > being funded by the U.S. Department of Defense, probably the most > profligate spender in the history of mankind,[1] and at the same time > was condemned for being too hard a language to grasp (too "big") and too > hard to write a compiler for. > > Further, I would argue that Ada was indeed an excellent language, > certainly for its time and arguably still. But it was not easy to > acquire by programmers who took an absolutely slovenly attitude toward > data type discipline, a characterization that fits many pre-ANSI C > programmers perfectly. > > Perhaps those who learn how to manage data types using C as their first > language suffer irrevocable brain damage, and are fit subjects for pity > and mockery. You won't find _that_ opinion in the Jargon File. > > Regards, > Branden > > [1] https://www.npr.org/2021/05/19/997961646/the-pentagon-has-never-passed-an-audit-some-senators-want-to-change-that From crossd at gmail.com Fri Nov 22 11:53:03 2024 From: crossd at gmail.com (Dan Cross) Date: Thu, 21 Nov 2024 20:53:03 -0500 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: [TUHS to Bcc:, Cc: COFF] On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev wrote: > Dan Cross wrote: > >Programmer ability is certainly an issue, but I would suggest that > >another goes back to what Rob was alluding to: compiler writers have > >taken too much advantage of UB, making it difficult to write > >well-formed programs that last. > > Following the letter, rather than the spirit, of the standard? Pretty much! > [snip] > >My sense is that tossing in bad programmers is just throwing gasoline > >onto a dumpster fire. Particularly when they look to charlatans like > >Robert Martin or Allen Holub as sources of education and inspiration > >instead of seeking out proper sources of education. > > I am a bad one as well, to have liked some things in Martin's books > /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor > Dijxtra, nor Knuth, but why a charlatan? Briefly, because he writes with unwarranted confidence, and just isn't a very good programmer himself. He writes with an authoritative voice about things that he doesn't know very much, if anything, about. For example, the things he's written about static typing in programming languages are complete nonsense. Sriram Krishnamurthi called him out on that (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did not respond well, doubling down on his unfounded opinions (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html). Later, he justified his opinion by making allusions to the amount of time he's been programming (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html). Hey, when it comes to logical fallacies centered on appeals to length of experience, well...I swooshed a basketball for the first time more than 40 years ago, but I've given up any dream I may have ever had of being a point guard in the NBA. Just doing something for a long time doesn't mean you're good at it. Robert Martin doesn't write production-quality code, period. He claims to "ship" lots of code, but acknowledges that most of that is example code for his books and personal side-projects. But the code examples he has publicly available are not particularly well-structured, readable, or maintainable. For a particular egregious example, see https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c (not the current commit; he modified it somewhat after I sent him https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff79e5064897bce5ef42, which he did not acknowledge; see https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320cd6ca5637f2c062d9d0540cc4a for the timeline). And while that small program is a particularly bad example, other bits of his code are also bad. Ousterhout was asked to comment on his "extract till you drop" approach and presented with a "refactoring" Martin did of a program due to Knuth (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop). Ousterhout responded that he was "bewildered and horrified" by the approach. As Ousterhout put it, "He has taken 25 lines of code that are pretty straightforward and easy to understand, and turned them into 38 lines with 9 methods, none of which has a stitch of documentation. What was the point of this?" (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ) These are all typical of Martin's approach. Hence why I say the man is a charlatan. Others have written at length about why, and how, his advice is generally bad. - Dan C. From luther.johnson at makerlisp.com Fri Nov 22 12:55:00 2024 From: luther.johnson at makerlisp.com (Luther Johnson) Date: Thu, 21 Nov 2024 19:55:00 -0700 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: <712c898c-8d81-1055-b1ce-eae2132b55dc@makerlisp.com> "Appeal to Authority", or "Argument from Authority", one of the fallacious argument methods. I think there are many "experts" who learn just enough about a topic to write a book about it, the idea seems to be, to become an "authority" on a topic, to sell more books and gain more authority and notoriety. I've read many good books by brilliant authors who not only could write about certain topics, but were actually some of the inventors and developers, who then explained it all to us so we could make more things practically work. And then there are slapped-together books of technically trendy slogans and simplistic contrived examples. I like to read books in the former category, the latter, not so much. We can tell the difference by whether the books give us anything we can use - and this is usually more in the realm of ideas, rather than code snippets or "design patterns". The way I like to think about things, anyway. On 11/21/2024 06:53 PM, Dan Cross wrote: > [TUHS to Bcc:, Cc: COFF] > > On Mon, Nov 18, 2024 at 11:47 AM Anton Shepelev wrote: >> Dan Cross wrote: >>> Programmer ability is certainly an issue, but I would suggest that >>> another goes back to what Rob was alluding to: compiler writers have >>> taken too much advantage of UB, making it difficult to write >>> well-formed programs that last. >> Following the letter, rather than the spirit, of the standard? > Pretty much! > >> [snip] >>> My sense is that tossing in bad programmers is just throwing gasoline >>> onto a dumpster fire. Particularly when they look to charlatans like >>> Robert Martin or Allen Holub as sources of education and inspiration >>> instead of seeking out proper sources of education. >> I am a bad one as well, to have liked some things in Martin's books >> /Clean Code/ and /Clean Architecture/ . True, heis no Wirth, nor >> Dijxtra, nor Knuth, but why a charlatan? > Briefly, because he writes with unwarranted confidence, and just isn't > a very good programmer himself. > > He writes with an authoritative voice about things that he doesn't > know very much, if anything, about. For example, the things he's > written about static typing in programming languages are complete > nonsense. Sriram Krishnamurthi called him out on that > (https://x.com/ShriramKMurthi/status/1136411753590472707) and he did > not respond well, doubling down on his unfounded opinions > (https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html). > Later, he justified his opinion by making allusions to the amount of > time he's been programming > (https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html). Hey, > when it comes to logical fallacies centered on appeals to length of > experience, well...I swooshed a basketball for the first time more > than 40 years ago, but I've given up any dream I may have ever had of > being a point guard in the NBA. Just doing something for a long time > doesn't mean you're good at it. > > Robert Martin doesn't write production-quality code, period. He claims > to "ship" lots of code, but acknowledges that most of that is example > code for his books and personal side-projects. But the code examples > he has publicly available are not particularly well-structured, > readable, or maintainable. For a particular egregious example, see > https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c > (not the current commit; he modified it somewhat after I sent him > https://github.com/unclebob/PDP8EmulatorIpad/commit/dbfa03e90a084a25992dff79e5064897bce5ef42, > which he did not acknowledge; see > https://github.com/unclebob/PDP8EmulatorIpad/pull/2/commits/84483cd4d60320cd6ca5637f2c062d9d0540cc4a > for the timeline). > > And while that small program is a particularly bad example, other bits > of his code are also bad. Ousterhout was asked to comment on his > "extract till you drop" approach and presented with a "refactoring" > Martin did of a program due to Knuth > (https://sites.google.com/site/unclebobconsultingllc/one-thing-extract-till-you-drop). > Ousterhout responded that he was "bewildered and horrified" by the > approach. As Ousterhout put it, "He has taken 25 lines of code that > are pretty straightforward and easy to understand, and turned them > into 38 lines with 9 methods, none of which has a stitch of > documentation. What was the point of this?" > (https://groups.google.com/g/software-design-book/c/Kb5K3YcjIXw/m/qN8txMeOCAAJ) > > These are all typical of Martin's approach. Hence why I say the man is > a charlatan. Others have written at length about why, and how, his > advice is generally bad. > > - Dan C. > From douglas.mcilroy at dartmouth.edu Sun Nov 24 05:18:55 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 23 Nov 2024 14:18:55 -0500 Subject: [TUHS] Proposed release goal: [PATCH] [pic] Add support for arbitrary polygons Message-ID: A worthy objective, but it should not be released without user documentation. Where can one see that? Doug From als at thangorodrim.ch Sun Nov 24 08:29:18 2024 From: als at thangorodrim.ch (Alexander Schreiber) Date: Sat, 23 Nov 2024 23:29:18 +0100 Subject: [TUHS] Minimum Array Sizes in 16 bit C (was Maximum) In-Reply-To: References: <20240930191216.tIpea9lo@steffen%sdaoden.eu> Message-ID: On Mon, Nov 18, 2024 at 03:00:22PM -0000, Anton Shepelev wrote: > Steve Nickolas wrote: > > > >I feel like most of the changes to C after C89 were a waste. Apart > >from stdint.h, I mostly keep to coding in strict C89. > > And then I must not only specfy std-c89 in GCC, but add --pedantic, too. > There is even a --pedantic club: . Snippet from a Makefile for a small university exercise of mine from decades ago: ---- snip ----- # flags for debugging DEBUG = -g -DDEBUG # complain about everything suspicious ANAL_RETENTIVE = -ansi -Wall -pedantic -Wtraditional -Wpointer-arith -Werror -Wshadow -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Waggregate-return -Wmissing-declarations -Wnested-externs -Winline # use this for development CC = gcc ${DEBUG} ${ANAL_RETENTIVE} ---- snip ----- Yes, I was keenly aware that I wasn't exactly "God's gift to C Programming" and tried to get as much help from the compiler to avoid obvious mistakes as possible. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison From douglas.mcilroy at dartmouth.edu Sun Nov 24 12:01:25 2024 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sat, 23 Nov 2024 21:01:25 -0500 Subject: [TUHS] Proposed release goal: [PATCH] [pic] Add support for arbitrary polygons In-Reply-To: References: Message-ID: The old Doug is up to the same old tricks. This mystery note was intended for the groff list, of course. Sorry++ Doug On Sat, Nov 23, 2024 at 2:18 PM Douglas McIlroy wrote: > > A worthy objective, but it should not be released without user > documentation. Where can one see that? > > Doug From stuff at riddermarkfarm.ca Mon Nov 25 02:13:18 2024 From: stuff at riddermarkfarm.ca (Stuff Received) Date: Sun, 24 Nov 2024 11:13:18 -0500 Subject: [TUHS] Proposed release goal: [PATCH] [pic] Add support for arbitrary polygons In-Reply-To: References: Message-ID: <59b2fa43-71a0-2cbe-6465-6ccd546410a0@riddermarkfarm.ca> On 2024-11-23 21:01, Douglas McIlroy wrote: > The old Doug is up to the same old tricks. This mystery note was > intended for the groff list, of course. > > Sorry++ > Doug Should that not be "++Sorry"? Sorry -- could not resist. S. > > On Sat, Nov 23, 2024 at 2:18 PM Douglas McIlroy > wrote: >> >> A worthy objective, but it should not be released without user >> documentation. Where can one see that? >> >> Doug From tuhs at tuhs.org Thu Nov 28 04:56:16 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 27 Nov 2024 18:56:16 +0000 Subject: [TUHS] Canonical Historic Approach to iconv(1) Message-ID: So a project I'm working on recently includes a need to store UTF-8 Japanese kana text in source files for readability, but then process those source files through tools only guaranteed to support single-byte code points, with something mapping the UTF-8 code points to single-byte points in the destination execution environment. After a bit of futzing, I've landed on the definition of iconv(1) provided by the Single UNIX Specification to push this character mapping concern to the tip of my pipelines. It is working well thus far and insulates the utilities down-pipe from needing multi-byte support (I'm looking at you Apple). I started thumbing through my old manuals and noted that iconv(1) is not a historic utility, rather, SUS picked it up from HP-UX along the way. Was there any older utility or set of practices for converting files between character encodings besides the ASCII/EBCDIC stuff in dd(1)? As I understand it, iconv(1) is just recognizing sequences of bytes, mapping them to a symbolic name, then emitting them in the complementary series of bytes assigned to that symbolic name in a second charmap file. This sounds like a simple filter operation that could be done in a few other ways. I'm curious if any particular approach was relatively ubiquitous, or if this was an exercise largely left to the individual and so solutions were wide and varied? My tool chain doesn't need to work on historic UNIX, but it would be cool to understand how to make it work on the least common denominator. - Matt G. From henry.r.bent at gmail.com Thu Nov 28 05:08:46 2024 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 27 Nov 2024 14:08:46 -0500 Subject: [TUHS] Canonical Historic Approach to iconv(1) In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 at 13:56, segaloco via TUHS wrote: > I started thumbing through my old manuals and noted that iconv(1) is not a > historic utility, rather, SUS picked it up from HP-UX along the way. > I see iconv(1) (and iconv(5)) in the SVR4 sources, but I don't see any references to HP there - what manpages are you looking at? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Nov 28 10:07:56 2024 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 28 Nov 2024 00:07:56 +0000 Subject: [TUHS] Canonical Historic Approach to iconv(1) In-Reply-To: References: Message-ID: On Wednesday, November 27th, 2024 at 11:08 AM, Henry Bent wrote: > On Wed, 27 Nov 2024 at 13:56, segaloco via TUHS wrote: > > > I started thumbing through my old manuals and noted that iconv(1) is not a historic utility, rather, SUS picked it up from HP-UX along the way. > > > I see iconv(1) (and iconv(5)) in the SVR4 sources, but I don't see any references to HP there - what manpages are you looking at? > > -Henry My mistake, the HP-UX reference was for iconv(3), not iconv(1). The source is the current issue of POSIX, Issue 8 (2024). Indeed iconv(1) is in the SVR4 manuals but only supporting system-provided charmaps. Additionally, while in the SVR4 manuals, I didn't spot it on first pass through SVID Issue 3 which is the SVR4-era issue. It looks like specifying local charmap files was added to the spec in IEEE 1003.1-2004: > Issue 6 > This utility has been rewritten to align with the IEEE P1003.2b draft standard. Specifically, the ability to use charmap files for conversion has been added. - Matt G. From rudi.j.blom at gmail.com Thu Nov 28 13:04:36 2024 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 28 Nov 2024 10:04:36 +0700 Subject: [TUHS] Canonical Historic Approach to iconv(1) Message-ID: The "man 1 iconv" page on both HP-UX 11i 11.23 (Aug 2003) and 11.31 (Feb 2007) remark that iconv was developed by HP. Cheers, uncle rubl -- The more I learn the better I understand I know nothing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woods at robohack.ca Thu Nov 28 10:57:24 2024 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 27 Nov 2024 16:57:24 -0800 Subject: [TUHS] Canonical Historic Approach to iconv(1) In-Reply-To: References: Message-ID: At Thu, 28 Nov 2024 00:07:56 +0000, segaloco via TUHS wrote: Subject: [TUHS] Re: Canonical Historic Approach to iconv(1) > > My mistake, the HP-UX reference was for iconv(3), not iconv(1). The > source is the current issue of POSIX, Issue 8 (2024). Indeed iconv(1) > is in the SVR4 manuals but only supporting system-provided charmaps. > Additionally, while in the SVR4 manuals, I didn't spot it on first > pass through SVID Issue 3 which is the SVR4-era issue. It is documented in the System V Interface Definition, Fourth Edition, Volume 2, Pages 211,212. There's no mention of Unicode or ISO 10646 of course -- they're too new, at least to be in any system standards by that time! After all SVID-4 was only getting caught up with POSIX 1003.1-1990. UTF-8 didn't even show up more widely until early 1993, and wasn't in force in the IETF until 1998 so you can't really expect SVID-4 to use it (even in 1995) for a 1990-based standard. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: