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