I'm no longer confident that Fedora will continue to be a thriving open-source project. If IBM is killing RHEL clones now, why risk Fedora being next?

I hear you saying "RHEL is derived from Fedora" and "Fedora is a separate open-source project". The thing is, RHEL is derived from Centos Stream *now*. Why does Fedora need to exist? Or rather, why does Red Hat need to provide engineering and infra to Fedora? It's true that Fedora is a separate project, but its mostly contributed by Red Hat employees. If IBM decides tomorrow to stop paying for Fedora because Centos Stream is enough, can Fedora stand alone?

Maybe this is just FUD, but I no longer have confidence in an IBM owned Linux distro. I've already moved to Debian for personal machines, and I've been advocating it professionally as well. It's just irresponsible for an org that spends significant engineering time customizing their Linux installations to base on an uncertain Red Hat/IBM backed distro over a fully open-source project with no strings attached. Fool me once shame on you but fool me twice and, well, IBM isn't going to get me again.

But with your extensive history in he Red Hat sphere you should know that each release of CentOS Stream is a frozen Fedora release.

Fedora will still act as the testing ground for all things CentOS, and therefore all things RHEL.

What are the arguments against this model of development where they have a "future distro" like Fedora to model their future RHEL releases after?

This is the current state. Why should IBM maintain rolling updates into Fedora ("rawhide"), then cut a Fedora release, then bless a Fedora release as Centos Stream, then backport from rawhide to Centos Stream as needed until they decide to cut a RHEL branch? If I were an exec at IBM, that would seem like a lot of extra releng salary that could be better spent directly on core product (which is RHEL which comes from Centos Stream) or billable hours. Someone's bonus can go up a few bills by eliminating a line item while improving efficiency.

Why should IBM continue paying for rawhide -> fedora release -> centos stream -> rhel ? How long until the fedora release step is put out to pasture then eventually culled?

That is to say nothing of the fact that Fedora is used very extensively internally, and that there are hardware partners like Lenovo that sell it preinstalled, and Fedora Asahi which is the new home of Apple hardware enablement (and thus the best Aarch64 development platform). The Fedora ecosystem is extremely valuable to Red Hat.

But this is all backwards.

> Why should IBM maintain rolling updates into Fedora

The better question is why is IBM maintaining rolling updates into Fedora? Because they have a business incentive to do so. As other comments have opined, they get free testing, free feedback of upcoming changes. The community gets a lot in return. RedHat funds so much open source/free(dom) software development it's ludicrous. There's reciprocity here. There's a lot of other distributions also benefiting from RedHat's work, like Debian (and vice versa).

It seems like the community here on HN has gone complete bonkers over this RedHat business decision. We've reached a next level of open source entitlement syndrome.

We are not entitled to use RHEL for free. We are not entitled to repackage RHEL and sell it for free either. We are only entitled to those part of the source code which is covered by copyleft licenses. Are we entitled to the SRPM for those programs? We don't know. The patches applied, sure. How about the spec files to assemble the RPMs? Who knows. But it seems like everybody are demanding that RedHat should keep doing this work and ensure that third parties can keep their business model of reselling said work.

This is probably not a popular opinion, but the community seem to have a deranged take on this situation.

No, we're not. Even for code covered by copyleft licenses, we are only entitled to the source for which we have received a binary. However, once we have received those sources, we should be free to do with them whatever the license allows.

But that last part is what Red Hat is violating, and that's why some people have a deranged take, thank you very much: they use their sales contracts to specifically deny freedoms granted by copyleft licenses.

If you as a Red Hat customer redistribute the source code, Red Hat won't sue you. You didn't do anything illegal, you are doing what you are allowed to do.

Nothing in the GPL entitles you to future support from Red Hat, source code of future versions or anything of the sorts.

You're free to do whatever you want with the sources. Red Hat is free to stop business with you at any time. There's nothing contradictory here.

But the GPL does not compel RedHat to keep you as a customer. There are two separate legal instruments, the license for the source and the terms for RHEL. RedHat are free to chose their customers. We can't force a company to take us on as a customer.

I don't think you realize just how much RH focuses on releasing stable software. They have SLAs with government agencies, healthcare providers and they need to live up to them. This is why CentOS Stream is in fact more secure than RHEL because they spend so much time testing the patches that go into RHEL that CentOS Stream now gets them before RHEL. A reversal to the state of affairs with old CentOS.

It is also why they were so keen on killing any project that claims to be a RHEL clone, because they want their customers to know what they're downloading, and know what they're running. RHEL comes with guarantees.

Of course I'm the first to admit that most of their motivations to kill the CentOS source repo were financial. That doesn't change the fact that Red Hat is a very enterprise-minded company, and their perspective isn't always obvious to the rest of us.

And they can do that work internally, privately, in the dark, where they cannot benefit from any community engagement, or they can do that work in the open, engaging with the community.

I suspect the difference in cost between the two is not significant enough to be relevant, and the open variant has more benefits.

Note that this was RH's stated intent when the whole CentOS non-Stream EoL shenanigans went down - they said that Fedora & CentOS Stream benefits RHEL, CentOS non-Stream does not.

[After writing this, I was curious about Fedora project costs, they are lower than I thought: https://budget.fedoraproject.org/budget/FY20/overall.html - Red Hat's contribution was ~$196k for FY2020 (in cash, there's probably more 'soft' costs in terms of staff and hardware time/resources)).

It is.

His perspective is very interesting and appreciated, especially love how he frames things historically. Knowing the history really helps put things in context. TFA is long, but worth reading.

I'm about 30 years younger than Jon Hall, so I couldn't be familiar with his accomplishments other than by oral/written accounts. Since he hasn't written big hit books I could read or software I could use (alright alright, Linux for Dummies), I constantly saw people calling him a legend but never understood why. I finally asked around in the Linux kernel community, and was explained the extent of his contribution: he was Linus' mentor in a way. When they met in 1994, Linus was a 25 yo student and Jon a 44 yo DEC marketing manager. I like to think of their conversation as something like "Listen to me kid, this is what you gonna do".

With this in mind, a line in Jon Hall's wikipedia bio stands out: It was during his time with Digital that he initially became interested in Linux and was instrumental in obtaining equipment and resources for Linus Torvalds to accomplish his first port, to Digital's Alpha platform.. Another one in his linkedin work history reflects this view: Senior Marketing Manager, DEC, 1983-1998: In 1994 met Linus Torvalds, recognized commercial value of Linux, obtained funding for port of Linux to 64-bit Alpha processor, opening up a billion dollar line of Linux-based High Performance Computing Super Computers.

WP: https://en.wikipedia.org/wiki/Jon_Hall_(programmer)

LI: https://www.linkedin.com/in/maddog/

Yes, however that's always been something you just kind of accepted with free software. That's part of what giving something away for free entails: not everyone is going to give something, or anything at all, back.

The difference with say Oracle Awesome Linux or whatever is that they are selling RH’s value add work and ecosystem as a service. As in they literally come in “Buy this stuff to be supported with our other stuff, we ship whatever RH ships.”

IMO, Red Hat’s changes are really making it more expensive to create exclusive “Oracle Red Hat for X” or similar business models. The people who can’t afford RHEL for their academic HPI still can’t, and just pick something else. People here quacking about Fedora are just quacking - Fedora is a project with a commercial purpose that serves the company’s needs. It will exists until it doesn’t.

RH isn’t Microsoft - everyone acknowledges that lots of distros exist and many are excellent. You can start a distribution today. But “fine, I’ll just use Debian” isn’t really a valid answer either. Debian is an awesome project and product, but if you chose Red Hat in the first place for reasons other than “I got a CD with a magazine in 1998”, Debian probably isn’t ideal without you doing alot of work. Then it’s a money discussion. (Cost of humans doing stuff vs paying RH to do stuff and humans to do other stuff)

I would extend that to almost noone.

99% of people are going to not give anything back. 0.9% will file complaints or bug reports or donate money or whatever. 0.1% will actually give back any functional code.

Don’t know why people are very passive when it comes it.

In US, depending on who you ask / how you count, the number is anywhere from 50% to 75%.

Maybe that's still a reasonable assumption to make. Maybe it isn't. Maybe it was in the past but isn't anymore due to the proliferation of clouds, serverless, saas, whatever.

In general, there's been a huge revamp of the user experience for RHEL and associated services. And it's been for the better. The experience on console.redhat.com is stellar and worth it alone, in my view.

[1]: https://access.redhat.com/articles/simple-content-access

[2]: https://console.redhat.com/insights/image-builder

[3]: https://access.redhat.com/documentation/en-us/red_hat_enterp...

[4]: https://access.redhat.com/documentation/en-us/red_hat_enterp...

It Is Difficult to Get a Man to Understand Something When His Salary Depends Upon His Not Understanding It

It's always fascinating to hear what a septuagenarian considers to be the "inflection points" of their career. It's especially striking how my own inflection points interweave with theirs. I was right in the middle of the SCO bullshit, but I'm not sure I'm allowed to talk about some of it. Maybe enough corporate lawyers have retired and/or died by now that I can finally say what I want anyway. If I can find the motivation.

I'm glad maddog is still sharing his story, as I find as I get older that I care less and less about sharing anything with anyone on the Internet. Any conversation of any significance to me tends to happen face-to-face these days, so it hardly seems worth it to share or engage with anyone I don't know personally.

> In fact, not only was selling software hard, but you could not copyright

Was that the actual legal situation in 1969 - that software could not be copyrighted?

I totally find it believable that, in 1969, the author believed that - but was his belief legally accurate?

I wasn't practicing law back then, but my secondhand understanding is that while it wasn't clear that copyright would apply to software, or how, savvy players largely expected some kind of protection for written software beyond trade secrecy.

There were all kinds of questions, theories, and proposals about whether that would happen under copyright law or perhaps through some software-specific regime. The US answer was clear when "computer program" was written into the scoping definitions of the Copyright Act. We still cite back to the commission that pushed that recommendation, CONTU, when debating loose ends.

I also found a journal article [1] which says (p. 1748, my emphasis):

> There was considerable debate in the 1960s, during the gestation of the legislation that became the Copyright Act of 1976, about whether computer programs could, or should, be protected by copyright law. Although no one seriously questioned that source code forms of programs could be copyrighted as written texts, there were two principal concerns about applying copyright to machine-executable forms of programs...

So, according to that, the debate was primarily about whether object code was copyrightable, as opposed to source code. At the time, distributing software as source code was extremely common – indeed, configuration files were rare, configuration was commonly hardcoded in the source code, making compilation a necessary part of the installation process – which meant that source code being much more clearly copyrightable than object code would have been less of an obstacle to commercial software distribution than it would have been in later decades, when object code only distribution became much more common.

[0] Catalog of Copyright Entries. Third Series: 1972: Title Index. Books: July-Dec. page 3926 which lists "CILA Mark-1 system (casualty insurance logistics automated) source program listing. NETWORK DATA PROCESSING CORP" – https://books.google.com/books?id=4kAhAQAAIAAJ&pg=RA1-PA6 – note there are many other references to "computer programs" in that index, but it is sometimes unclear whether they are manuals or source code; this particular entry is rather clearly source code.

[1] Pamela Samuelson, "The Uneasy Case for Software Copyrights Revisited", George Washington Law Review, vol 79 no 6 (September 2011), pp. 1746-1782. https://www.gwlr.org/wp-content/uploads/2012/07/79-6-Samuels...

I don't think I've seen that asserted before. I certainly wouldn't bank on it these days.

As for timing, there were companies speculating well before '72 that copyright would be the game. Archival work found a copyright-based license agreement from IBM from as early as 1969. See https://www.create.ac.uk/blog/2018/11/14/the-first-software-....

That's not the same as saying the question was settled. After the Copyright Act amendment, it sure was.

Let me ask the question historically: in previous decades, how often have the legal interpretations of the Copyright Office ended up being affirmed by the Courts and/or Congress, versus how often have they been overturned by them?

Also, the Courts owe a certain degree of deference to regulatory agency statutory interpretations, as established by the Supreme Court cases Skidmore v. Swift & Co. (1943) and Chevron U.S.A., Inc. v. Natural Resources Defense Council, Inc. (1984)–the second of which came after the time period we are discussing, but the first came before it. There is no obvious reason why that deference would not also apply to the US Copyright Office's interpretations of copyright law, and indeed there is case law applying those decisions to it.

> That's not the same as saying the question was settled.

The journal article I cited says that the question was settled all along for source code, and the legal doubts were only about object code.

As I recall, Skidmore held that what agencies say laws mean gets only the deference it deserves. In other words, the courts will reconsider for themselves how persuasive their arguments are.

Chevron starts with the question of whether the administrative agency's decision was made in a way that a statute gives the force of law. The Copyright Act gives the Copyright Office that power in administering some processes, like copyright registration. But last I checked, which was well after Chevron, questions about whether an application followed the registration process got deference, but the more basic question of whether something's copyrightable in the first place remained with the courts. Just because it's called the "Copyright Office" doesn't mean the courts will defer to it about the whole Copyright Act.

This difference could very well matter for some going issues, like the Copyright Office's recent rejection of some artwork created with the help of generative AI. I would be very, very surprised to see appeals courts handing that legal question over the Copyright Office.

I can't claim to have researched it formally, but my impression from reading a number of cases on the topic is that most of the time, the Courts end up agreeing with the Copyright Office. And more often than not, when they disagree with it, the disagreement gets reversed. For example, in National Broadcasting Co. v. Satellite Broadcast Networks, Inc (940 F.2d 1467 (11th Cir. 1991)), the 11th Circuit concluded that satellite broadcasters were cable systems. After oral argument, but before the decision was handed down, the Copyright Office issued a rule that they were not. The Court decided that the Office's rule was not retroactive, and hence did not apply to the case; they expressed doubts about whether they owed it deference, but avoided deciding that. Subsequently, in Satellite Broadcasting & Communications Ass'n of America v. Oman (17 F.3d 344 (11th Cir. 1994)), a different panel decided the Copyright Office rule was owed Chevron deference, and reversed a District Court decision applying that 1991 decision.

> As I recall, Skidmore held that what agencies say laws mean gets only the deference it deserves. In other words, the courts will reconsider for themselves how persuasive their arguments are.

You make Skidmore sound weaker than it actually is – in Skidmore, SCOTUS reversed the District Court and the 5th Circuit for failing to give sufficient deference to the statutory interpretations issued by the Department of Labor. Skidmore instructs Courts to evaluate an agency's "rulings, interpretations, and opinions", in light of "the thoroughness evident in its consideration, the validity of its reasoning, its consistency with earlier and later pronouncements, and all those factors which give it power to persuade". In other words, if a Court wants to reject an agency's interpretation, it has to present a persuasive argument that it is flawed on one of those grounds, or else the rejection has significant odds of being overturned on appeal.

> But last I checked, which was well after Chevron, questions about whether an application followed the registration process got deference, but the more basic question of whether something's copyrightable in the first place remained with the courts

In Varsity Brands, Inc. v. Star Athletica, LLC (799 F.3d 468 (6th Cir. 2015)), the Court of Appeals ruled that copyright registration decisions were owed Skidmore deference, and overturned the District Court for failing to extend that deference – in a dispute about copyrightability. It said that (in the 6th Circuit at least) when the Copyright Office judges a work to be copyrightable, as expressed through its decision to register the work, there is a rebuttable presumption that the Copyright Office's judgement is correct. That decision was upheld by the Supreme Court on appeal, but all three of majority, concurrence and dissent dodged the issue of deference entirely.

Looking back at the Athletica opinion, the 6th followed the Supreme Court in referring to Skidmore as "the power to persuade", as distinct from "the power to control". There's an abstract rubric for courts to use in assessing agency interpretations that don't have the force of law. But the door is very much left open for courts to adopt interpretations they find more thorough, better reasoned, more consistent, &c. You could squint and see an outline of how appeals courts review all decisions there.

With "presumption", I think you may be confusing terms. There's a statutory presumption you get in your favor once you successfully register copyright with the Copyright Office. That's a presumption for a party challenging the validity of a copyright to overcome---say, a defendant in a copyright infringement suit. Judges and courts don't bear "burdens" under "presumptions". They follow the rules that put them on litigants, or review the decisions of lower courts that should have.

Consider the opposite case where the Copyright Office refuses registration because it says the subject matter's not copyrightable. Perhaps because the artist created the artwork by prompting Midjourney. There's an appeal process for refusal to register within the Copyright Office, under its regulations. If you appeal twice and lose twice there, that's "final agency action" courts can look at.

If the issue ends up in court, the statutory presumption of 410(c), by its terms, doesn't apply. No issued registration, no presumption of validity. But there is still Skidmore. In the Sixth Circuit that's clear now. The court couldn't ignore the Copyright Office's reasons. But if it weren't persuaded, it could rule otherwise. It would have to read the Copyright Office and grapple with it, but not agree with it. Especially if it heard a better argument in briefing.

There are two different rebuttable presumptions here – one is the statutory rebuttable presumption under the Copyright Act; the other is that Skidmore deference is itself a rebuttable presumption. They are distinct, but in copyright cases, is there a clearcut boundary between them? If you read the 6th Circuit's decision, you will find that they deal with both the statutory presumption issue and the Skidmore/Chevron deference issue in the same section, and treat them as closely related as opposed to clearly separable. Maybe, if you think I'm confusing the two, you might think the Sixth Circuit panel was too?

> Judges and courts don't bear "burdens" under "presumptions".

I think we are using "burden" here in different senses. You are using it in a narrow, technical legal sense, and I agree with you that in that sense, the parties bear "burdens", not the Court.

However, in a broader sense of the term "burden" – in the sense of (informal) logic, philosophy, discourse analysis, etc – lower courts do bear a persuasive burden, of convincing the appellate courts to uphold rather than overturn their decisions, and rebuttable presumptions can work to shape, even increase, that burden.

> The court couldn't ignore the Copyright Office's reasons. But if it weren't persuaded, it could rule otherwise. It would have to read the Copyright Office and grapple with it, but not agree with it. Especially if it heard a better argument in briefing.

The District Court erred by simply engaging in a cursory dismissal of the Copyright Office's interpretive position, as opposed to engaging in a detailed analysis of that position against the Skidmore factors. If it had done that, the 6th Circuit would have found it harder to reverse the District Court's decision, even if it had ultimately arrived at the same result. Of course, if the 6th Circuit really wanted to overturn the decision, it could have (especially given de novo review)–but the District Court could have made the 6th Circuit's work cut out for it, as opposed to giving it easy grounds for a reversal.

You could say the lower court both failed to meet its persuasive burden with respect to the appellate court, and simultaneously failed to impose a greater persuasive burden on the appellate court (in reversing) than it could have. But for both, these are added persuasive burdens which only exist because the rebuttable presumption of Skidmore created them.

https://en.wikipedia.org/wiki/Software_copyright#History

Strange you don't believe Jon Hall, but willing to believe some random stranger on social media.

I'm not aware that Jon Hall would claim any particular expertise or interest in legal history, whereas there may well be "some random strangers on social media" who do.

Also, this is a matter which can be established by citing sources which Jon Hall might be unfamiliar with (for the simple reason that the topic might never have interested him sufficiently for him to research it.)

The one I remember most: "Q: how can we help Linux gain market share on the desktop, beyond the few percentage point it already has?" "A: that won't work. Find a market that doesn't currently use computers, create a product that can address the needs of this market, and make sure that it uses Linux. For instance, think about smartphones."

At one COMDEX in Chicago, I think it was the late 90s, he talked me and a friend into manning his booth for a couple hours so he could go check out the show. I don't remember if it was LPI, LI, or some other Linux related thing. We just handed out distro CDs and told people about Linux IIRC.

It was a crazy time when Linux was taking the PC world by storm, Tux was everywhere.

I think it can't be overstated how significant GNU was in making Linux successful. Everyone basically already knew how to use its userspace because GNU had been around for so long and people were already deploying it on the proprietary unices.

It's a bummer to see what's been done to rms/fsf since... practically tarred and feathered.

The free software community, at long last, finally have decided humans are more important than bits and have excised people from their midst who treated bits as more important than humans. This was the right thing to do. I should know. (Sigh.)

You are paying for:

- A reproducible target. You know EXACTLY what code you are running. If you manage more than three installations this is the only way you can diagnose and fix whatever issues your installation has.

- Support. The very few times I used RHEL support I always got timely and thorough assistance. Even when chasing a hardware bug or issues with third party device drivers.

- Backwards and FORWARDS compatibility. Red Hat systematically backports kernel bug fixes and support for new hardware to old kernels. We ran 2.6 kernels on Intel hardware released long after the 2.6 series were EOL.

- Device drivers. No, not for your five dollar mouse, but for hardware that costs the same as a small SUV.

If you're avoiding RHEL due to cost, have a look at their SKU list and talk to your local sales org, they have a wide range of options.

(Not affiliated with Red Hat or IBM, but RHCE since 2004)

Of course, any software developer targeting RHEL is also kind of an integrator, and if their company also needs to buy hundreds or thousands of licenses, well, the same thing applies.

This gets even weirder and worse if you think about using public cloud providers, who act as RHEL redistributors -- but you need to somehow have your own VM images... with RHEL. (I work for a company in this exact situation r.n.) Are we "freeloaders"? Because, I guess, if we are, then we might stop, but I don't see how that would benefit RHEL, because we'd have to drop support for RHEL instead of paying so much in license fees.

https://connect.redhat.com/ https://connect.redhat.com/en/programs/independent-software-... https://developers.redhat.com/articles/faqs-no-cost-red-hat-...

On the other hand, I worked for another company before, which was making a distributed storage product that targeted, beside other things RHEL (well, we really only used CentOS) because that was perceived as potentially most common customer profile. None of us wanted CentOS for our development needs, nor were we using CentOS for our own infrastructure etc. So, we paid nothing to Red Hat. I don't know how much this "special friendship" would cost if we had to buy any kind of a license to simply target RHEL (but we'd need a lot of machines running it -- during my time there we had ~20 ESX for testing, so... idk, that'd be what... couple thousands VMs? -- something like that).

Some how it made me want to get all LP certifications there, hehe

> For years Unix programmers measured their “age” in the Unix community by the generation of John’s book which they owned. I am proud to say that I have a third generation of the photocopies.

...

> However, some of these FOSS people condone software piracy and turn a blind eye to it.

> I am not one of those people.

Mr. Hall, as a self-admitted proud pirate, what right do you have to condemn anyone else? I myself do not condone piracy either, of course. Piracy is vile and pirates should get many decades in prison. But to say that you are proud of being a pirate and a few paragraphs later condemn the practice... that is the height of hypocrisy!

A link from Slashdot, ca. 2004

https://hardware.slashdot.org/story/04/06/01/0640250/hacking...

> I remember negotiating a contract for an efficient COBOL compiler in 1975 where the license fee was 100,000 USD for one copy of the compiler*

LOL, probably five times that blinkered professor's salary.

That brings me so much joy. I thought gcc was the origin point. That the initial transmission vector of GPL software was emacs is wonderful.

https://old.reddit.com/r/programming/comments/dhrcxw/james_g...

> The first release of GNU Emacs (numbered 15.34) was in 1985, and still incorporated some of Gosling's display code. The dispute continued, with Unipress announcing that it wanted to "inform the community that portions of the GNU Emacs program are most definitely not public domain, and that use and/or distribution of the GNU Emacs program is not necessarily proper." This was countered by Fen Labalme and others who claimed that Gosling had included their code in the sale to Unipress.

> Stallman solved the problem in characteristic fashion by announcing:

> > I have decided to replace the Gosling code in GNU Emacs, even though I still believe Fen and I have permission to distribute that code

Wikipedia gives the first release of GNU Emacs was in March of 1985. In that version of the story, at least, all of Gosling's code was gone by August.

Some other discussion on HN here provides more context: https://news.ycombinator.com/item?id=21251896

--

1: http://www.h-online.com/open/features/Emacs-the-birth-of-the...

https://www.lpi.org/wp-content/uploads/2023/04/cropped-out10...

Badass.

[1] - https://knowyourmeme.com/memes/you-gotta-hit-them-with-the-s...

Glad to see it posted here, and to see his name again.

Both companies took measures to unwind a set of ideas that had crossed the line from good on paper to bad in practice.

Some people were angry but everyone moved on and business proceeded with less distraction.

It would be a supremely boring project, but if interested orgs such as suse, oracle, ibm etc suport it, it might be feasible.

It could start from a description of rhel, but ideally could contain some extension of the file system standard to allow compatibility with debian.

Then, you would have a reference platform that multiple distributions could provide and there would be competition, not just one major provider of a system `as is' and some more or less incompatible others.

If you have that documentation, it works both in space (alternative implementations) and time. In the future, you can be sure that a new implementation, perhaps of a future version of the standard, is still exactly compatible with the previous version.

This has been done for languages (C, Ada, Lisp, Fortran etc), libraries and kernels (that is POSIX), processor ISAs, but not for linux distributions AFAIK.

Then I'd consider supporting the pay-to-use Linux model. In the meantime, Debian all the way.

https://developers.redhat.com/articles/faqs-no-cost-red-hat-...

It's a very good read and does a great job of laying out "how we got here"

2. Maddog didMiss a major point (which I'm certain he is aware): THE ENTIRE COMPUTER INDUSTRY WAS PUSHED TO ADOPT UNIX/POSIX APIS BY THE FEDERAL GOVERNMENT AS PART OF ITS EFFORTS TO PROTECT ITS SOFTWARE INVESTMENTS FROM HARDWARE VENDOR LOCK-IN. Even tho POSIX could be added to any platform, it was really crummy on some highly structured systems like VMS, leading all major hardware manufacturers to begin supporting UNIX-variants. POSIX was so "successful" the industry came together (with CDE, X/Open, etc.) to attempt to then further expand the functionality of such applications to be more competitive with what WindowsNT-based apps could offer. Heck, WindowsNT, which also had to awkwardly adopt POSIX APIs (along side Microsoft's Xenix UNIX-variant), even adopted one or two of the optional X/Open APIs.

3. WHY IS IBM INVOLVED IN LINUX? IBM wasn't (really) in the dot-com boom that made Linux what it is, but IBM was deeply affected by the dot-com bust like all other tech companies. One of the first things IBM did to survive was reduce costs by firing more than one hundred thousand highly paid engineers and shipping their jobs to India, putting them to work replacing legacy mainframe systems and setting up cheap websites in LAMP. IBM poured resources into LAMP to support that staff.

4. WHY DID IBM BUY REDHAT? As enterprise systems began to rely heavily on free software, Ginny Rometty the former CEO of IBM and, unbelievably, a one time System Administrator, bought REDHAT to "corner the market" for providing services to support free software within enterprises.

5. WHY IS IBM REDHAT GOING SIDEWAYS? Because IBM isn't going to ever be able to corner the market for free software support by locking its customers into REDHAT. Those customers will continue on with their current REDHAT distributions for a while and a new generation of workers will migrate them to distro-agnostic job control systems like Kata Containers (on AWS, Azure or on-prem Debian, etc.) even as the customer application providers release updates pre-packaged as containers that specify alternate Linux distributions (not CentOS/Fedora/RHEL) in their image/pod spec files. Note that while IBM REHAT may go sideways, IBM will still be able to provide free software support for non-REDHAT initiatives and will kill (or maybe spin) off REDHAT as that becomes more apparent.

Anyone know what he does use?

Is that a typo, or an intentional play on words? I'm guessing the former, but I will have to remember this one if I ever need to use it!

Is that what the contract says? Does it say that if a customer installs CentOS, or some RedHat downstream, that they are now in breach? I thought it was about distribution of source code. What is going on?

Also is RedHat fine if the other systems run a different linux like Debian? Where's the line?

1. Some customers used to buy one RHEL license and install 1,000 copies of RHEL. That loophole was closed years ago. It doesn't prevent using CentOS.

2. Red Hat has to give you RHEL source code but if they do they'll also cancel your subscription. This makes it harder for Alma/Rocky to get RHEL source code. That's the new controversy.

It's not really closed, because you also have users buying one RHEL license and using 20,000 clone deployments, and then reporting any issues they see on clones against their one copy of RHEL, demanding customer support for dozens of issues against one RHEL license.

How is it legal? Is it just an American thing?

I can guarantee that will hurt you more than it hurts them.

You signed an agreement with Red Hat to allow them full access to all your systems to audit usage. You will be in breach of contract, and you'll get to meet Red Hat's lawyers.

uh, no.

Nobody is arguing that it's in breach, he's just explaining why a business motivation might exist to differentiate RHEL and RHEL-clones.

It's certainly in breach of the "spirit" of the agreement in a much more direct way than the arguments people are making about the GPL.

Of course not. You can read the agreement yourself. [1] Look at the sction "Unauthorized Use of Subscription Services".

[1] https://www.redhat.com/licenses/Appendix-1-Global-English-20...

I started my Linux journey with Redhat Linux 5.1 (Manhattan) I got on CD-Roms in a paper computer magazine. This was in late 90s long before anyone came up with the name "red hat enterprise Linux". Red Hat was the distribution that took Linux and packaged it and a huge library of software on cd-roms. It was free. It was popular. It brought Linux to the masses including to myself. Also it provided tremendous value to people like me(at school at the time) who couldn't even afford Internet access at home. It gave me access to a huge library of quality open source software for free which was a basis of my first tiny side IT business (small office servers and support) that meant I could now afford to buy better hardware, dial-up for as long as I wanted and eventually a 128kb DSL line to the internet. When RHEL came out with their licensing I considered it a sort of "step back" towards the "old" paid software business model. I didn't like it at all. I turned away from Redhat for many years favoring Debian.

Forward a couple of decades later, and I'm no longer doing small office servers as a side hustle, but I'm working full time consulting for fortune 500 companies. In this environment RHEL is seen as a safe choice. Whenever an important physical linux system is deployed it's running RHEL and it is fully licensed with best support. I can count on fingers of one hand the times my employers actually used RHEL enterprise support during my entire career, but they still paid for it. Why? Because it limited the risk. What about dev, and test systems? What about VMs no one really cared about? All of them run CentOS. Why? So people that run these systems that didn't have to be so highly available could use the same tools to manage them. So we would know if something worked on CentOS it would probably work on rhel due to same versions of software etc. It was neat, but I'm sure it really cut into RedHat's bottom line. Consider that Microsoft was paid for every single server, regardless if it was just a developer sandbox or a highly available email server. Also MS made you pay for support for all of them. Yes, you could have different levels of support for various servers, but beyond certain numbers of servers/users the only way to buy MS software was with very expensive support. Using Linux in general was seen as a money saving method precisely because CentOS was available for less important stuff and you could buy RHEL for production systems. In a way CentOS was a marketing vehicle for RHEL.

But about 5 years ago this has started to change. More and more big companies I worked with moved to "the cloud". Although you could use rhel there, almost no one did. AWS had their own distro of Linux(based on rhel too) now that too was seen as a safe choice. Also, containers, autoscaling, ease of provisioning and general robustness of Linux in general created an environment where the value of rhel support to businesses was much lower. Cloud technologies have seriously started eating Redhat's cake in large companies IMO.

So RedHad had to do something to stay afloat. And they did. Is it enough to save them? I don't know, but for sure they don't deserve the hate they get for it.

Would I recommend Rhel to anyone other than a huge business that can absorb the cost? Of course not.

  father/con team Larry and Doug Michel

There is this view that RedHat is somehow doing something so indispensable; but really they are curating a collection of software, written wholly and completely by other people and released under GPL2 or similar licenses.

That somehow this gives them the ability to supercede the licenses that Red Hat, themselves, agreed to when downloading, compiling and distributing the Linux kernel and related software... just seems ridiculous.

So many are commenting, but forgetting that the full measure of legality is seen in courtrooms. It's unlikely that a successful defense in court can be mounted due to IBM's deep pockets, if we are realistic about it.

My hope is that Red Hat gets the full 'Bud Light' treatment instead, and simply ceases to be much of a force in the marketplace.

EDIT to add, here is the actual text of GPL v2 license... https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html

I don't know about Perl, but there was a long stretch of time where the only full-time paid developer of the CPython core team was a Red Hat employee, with all other core team members only able to contribute a few hours a week. I don't think that's the case anymore because IIRC Microsoft is now employing a few, but as far as I know Microsoft and Red Hat are the only two companies with any employees working on Python as a full-time job.

>Any of the GNU coreutils?

Yes

>Any part of the compilers used to produce the binaries?

Red Hat is the primary corporate contributor to GCC, yes. I would guess it's probably also the largest contributor to glibc as well, but if not, it's definitely top 3.

You'll notice that for instance GCC is ahead of Clang on C++23 adoption, and that's largely because Red Hat is paying people to work on it, whereas Google who was a major sponsor of Clang/LLVM work has been decreasing their contributions there.

But Red Hat has also been increasing their contributions to LLVM, too, e.g. https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.htm...

Python: the latest commit was from a Microsoft employee. Not to mention the creator of Python works for Microsoft now.

GCC: The commit log is overwhelmingly from: RedHat, Suse, Intel, Arm, Oracle (!), IBM and a few indie developers scattered about. I saw maybe one GNU person in the logs at the most.

Sounds like Free Software has gone corporate.... RMS might want to get his suit dry cleaned.

but how does red hat structure their stuff? I know that gnu projects must surrender their copyright to gnu, in order to prevent future shenanigans. if red hat had their core infrastructure (package manager, package definitions, etc.) copyrighted to red hat, then they can change the license on future releases of red hat to make it restrictive. you're then free to release a gpl source of the packaged code and the red hat specific modifications, since they fall under gpl, but you can't release the scaffolding anymore that make up the rest of the red hat system. I'm not a lawyer, but I've seen this kind of trick pulled on gpl projects before, where version 2 is now bsd/proprietary, while gpl version 1 remains in public access.

(edit: I'm reading the rest of the thread, and it seems there's some confusion about what exactly is in the new red hat contracts.)

Maybe more significantly, Red Hat has only made limited use of CLAs in the past and hasn't used any CLAs for many years now. It's basically corporate policy.

"2 b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."

A trickier thing for Red Hat might be

> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

One may argue about how to interpret that with regard to, for example, terminating a business relationship as a result. (I could see arguments on both sides.)

Also, Red Hat's method for complying with section 3 could be a subtle issue, because one of the options for compliance requires promising to provide "any third party" with the source code upon request. I don't know whether Red Hat is using that option or a different option.

I think there's been far too little focus on this, which is the crux of it. IMO (an IANAL) it seems pretty clear that even though this is not an explicit new license condition, it de facto does prevent redistribution: i.e. "you can do business with us, but only if you do not exercise one of your rights" in de facto limiting that right

I would love to see this adjudicated. Is there a company that builds statically against RHEL and resells, or modifies RHEL as a paying customer and resells that could show material injury by this move?

>> You may not impose any further restrictions on the recipients' exercise of the rights granted herein

Is it all that obvious or clear that "if we don't like what you do with our stuff, we will not renew your contract next year or sell you anything anymore" a restriction on the software they already delivered?

The software to which that clause applies was already delivered, and redhat is not, as far as I know, applying any restrictions on that software.

As a company, they are not obliged to sell to anyone who shows up with the sticker price, so this doesn't look, to me, like a restriction on the software itself.

After all, the right to choose your customers is a very basic one that only has few exemptions related to individuals in protected classes.

Yes, it's obvious.

There are a lot of drawbacks to use of the written offer option so I'm not sure if Red Hat will continue to use it with RHEL in the future.

If you are a customer of RHEL, then you do in fact have the ability to request a copy of the source code, including on physical media, and the ability to download it yourself from the customer portal, or from the srpm repositories.

The entire change is that the source code is now only being published in 2 places (CentOS stream and the customer portal) instead of 3 (the following two plus git.centos.org). I suppose it's 3 places instead of 4 if you include the srpm repositories.

> If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

the copy and distribution clause is only part 3, where you "may" copy and distribute the program (or its derivative work, as per part 2) provided that you either "accompany it with complete … source code" or some means to get the source code from you on demand.

I can't claim this just from reading the license, because I'm not a lawyer, but in rms's reading and in Lessing's reading, the combination of part 1 and part 2 mean, paraphrasing, "if you make derivative work, compile it, and distributed it, you must also provide source code".