Many opinions of the evidence, especially on Groklaw, but also elsewhere, including here. But none of these people offering opinions have really seen the evidence, which has been sealed. Mostly people talk about "evidence " offered by Darl at the start. But NONE of the actual evidence came from him. It was researched by a team of expert witnesses on both sides, of which I was one. On Mon, Nov 4, 2024, 8:23 AM Wesley Parish <wobblygong(a)gmail.com> wrote:

By evidence, I mean evidence that was part of the legal case(s). Material presented as a part of a marketing, sales, or public relations effort is not evidence in this sense. I don't know what Darl McBride and SCO were doing here, as I didn't work on that and only met Darl for 30 sec. (He came over to say hello to me in a conference room, and then the lawyers came over and told him to get away from me, for fear that he would pollute the waters. I worked extensively with his brother, Kevin.) My understanding is that SCO was trying to get money from Linux licenses of some sort. The Linux community freaked out. There were two principal legal cases. The first alleged copyright infringement in the development of Linux. I'm not sure who exactly was being sued, since I didn't work on this case. People tended to think that "Linux" was being sued, but I don't think there was any such entity like that. The second case, which I worked on, was about breach of contract between IBM and AT&T, and SCO I guess took on the rights and obligations of AT&T. This second case was extraordinarily complicated and, inasmuch as most everything about it was sealed, Groklaw and people in general never did understand what the issues were. Which, of course, didn't serve as an impediment for them offering up opinions about it. This second case started about 2005 and ended about two or three years ago, so it went on for about 15 years. The copyright case I think ended when it was determined that the copyrights in question didn't belong to SCO. The way the copyright case ended doesn't mean that Linux development didn't violate copyrights. I'm pretty sure that it did, based on conversations with a friend of mine who was a technical expert on that part of the case. One might ask, how could Torvalds and all those Linux developers violate System V copyrights since they had never seen System V code? The answer is that corporations such as IBM also contributed to Linux, and those corporations did have such access. If one wants to take all this seriously and differentiate between what one knows to be true, on the one hand, and what one thinks is true or wants to be true, on the other hand, then I think one would realize that nobody outside of the legal teams knows anything about the case. As I said, I know a whole lot about part of the case(s) and next to nothing about the other parts. Groklaw used to reprint redacted documents that had been released by the court, a couple of which I wrote, but ignored the fact that they were redacted and that all the juicy parts were missing. Generally, if anything was important, it was sealed. I just a few minutes ago glanced at the Wikipedia article "SCO–Linux disputes" and it's not bad. It does pretty much explain the breach of contract case. There is a section titled "IBM code in Linux" that lists some technologies (e.g., JFS, RCU), and that's the area that I worked on. I wrote a program that could in effect do a "diff" on entire operating systems, hundreds of thousands of lines of code. It was amazing to see the results. Even the attorneys who were doing the suing were amazed. (Whether all my discoveries represented actual breach of contract is a legal question, not a technical one, and was therefore well outside the scope of my work.) Marc On Mon, Nov 4, 2024 at 3:50 PM Greg 'groggy' Lehey <grog(a)lemis.com> wrote: -- *My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.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

On Mon, Nov 4, 2024 at 6:32 PM ron minnich <rminnich(a)gmail.com> wrote: 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 8:14 PM Larry McVoy <lm(a)mcvoy.com> wrote: 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. 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_… has the online copy if people want to check it out. 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. 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 06:35:30PM -0700, Warner Losh wrote: 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.

Just to repeat, because of a bunch of confused posts here: The breach of contract case was not about System V code in Linux. It was about non-AT&T code from System V derivatives (e.g., AIX, Dynix) into Linux. (The copyright case was completely different.) You may wonder why non-AT&T code from a System V derivative into LInux should be a legal issue. To find the answer you have to read the contract. If it sounds bonkers, then we can agree that the contract was bonkers. I don't know how strong the copyright case was. I didn't work on it. Marc On Mon, Nov 4, 2024 at 7:13 PM Warner Losh <imp(a)bsdimp.com> wrote: -- *My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*

Ron, there were two cases, copyright and breach-of-contract. I worked on the latter, and no publicized "evidence," such as that from Darl McBride, was relevant. My understanding is that all evidence in the copyright case was discovered by the technical experts working on their own, and that they didn't take anything from McBride either. All that stuff from McBride and the selling of licenses was something that the SCO corporation did, not anything that the lawyers working on the actual cases had anything to do with. The Linux community reacted, and it seems still does, to this McBride stuff. It didn't react to the court cases, although it thought it did, because the evidence was sealed. As I said in earlier posts here recently, the breach-of-contract case wasn't about AT&T code in Linux. It was about IBM- (or Sequent-) written code in Linux. The contract said that IBM was not allowed to put anything from AT&T-licensed OSes into Linux, even if what was put into Linux was from IBM additions to an OS licensed from AT&T. Somebody here likened this to the GPL, in the sense that if you add anything to a GPL-licensed thing, the whole thing, including your stuff, is covered by the GPL. I don't know enough about the GPL to say for sure that that's actually how the GPL works. Marc On Thu, Nov 7, 2024 at 1:41 PM ron minnich <rminnich(a)gmail.com> wrote: -- *My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*

On Thu, Nov 7, 2024 at 4:03 PM Theodore Ts'o <tytso(a)mit.edu> wrote: 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... Which is always a better choice... That's a good outcome... Warner

On Sat, Nov 09, 2024 at 12:29:55PM -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]. [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

(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: 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.) 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. 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. 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. 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. :-)

On Mon, Nov 11, 2024 at 6:55 PM Kevin Bowling <kevin.bowling(a)kev009.com> wrote: 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/…

On Monday, 4 November 2024 at 17:05:45 -0700, Marc Rochkind wrote: OK, that makes sense. Did it contradict the "evidence" that we mortals saw? That wouldn't have made sense. 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. 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. 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? 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(a)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

On Monday, 4 November 2024 at 20:04:38 -0700, Marc Rochkind wrote: 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. 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. 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. 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? 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. Understood. From my point of view this is a technical discussion. ... as long as you didn't mind riding bicycles. Greg -- Sent from my desktop computer. Finger grog(a)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