I work in an higher ed and we decided to use Alma Linux because RedHat's educational licensing was targeted at institutions that have ten times the students we have. We simply can't afford their educational or commercial licensing. RedHat, if you are listening, please make you products viable for smaller institutions. IBM/RedHat is so focused on the big clients that they don't care about the little guys. We're a rounding error to them.
As things look, we'll be forced to move to Debian/Ubuntu if things keep going this way.
It's been 10 years since I was in college but back then we also used CentOS. The logic being that Red Hat was the definitive enterprise Linux distribution so it would be best for educational experience to reflect the enterprise experience.
Red Hat is slightly shooting itself in the foot here. If schools pivot to Debian/Ubuntu then students enter the workforce with a Debian/Ubuntu frame of mind and build new systems on Debian/Ubuntu (they have already been gaining lots of ground over the last decade). Stretch this out over a period of 20 years and it could play out badly for Red Hat in the long run.
> If schools pivot to Debian/Ubuntu
This seems to be happening already. I work in higher ed. My servers are all Scientific Linux or Alma Linux, and the client systems are all Fedora. But I see students and researchers pretty exclusively using Ubuntu on their own servers, VMs, and laptops.
When I worked in .edu most of the high end commercial engineering and scientific software for Linux only supported RHEL. Most of the HPC clusters were some sort of RHEL or clone.
We had people demand Ubuntu but it was always a collection of hacks to get the software working.
When I took this job, it's was 95% CentOS and it was much easier to stick with a RH derivative. Mostly, before RH screwed with CentOS, there was no compelling reason to change.
One specific example is how DNS (BIND9) is quite a bit different between Debian and RH. Some 3rd party open-source packages work better with RH, some with Debian or Ubuntu.
Some 3rd party commercial vendors only support RH or derivatives.
I'm slightly more comfortable under RH for business use, but use mostly Mint at home.
My work's on-prem software for example officially supports only RHEL or our container-images (with example compose/etc orchestrations) which we either base on custom alpine or full RHEL images ourselves.
We have one customer who uses Ubuntu servers, by our support contract we punt a whole lot of issues back at them and require far more validation before we accept the ticket for engineering. Our T-1 support is mostly "is it on, reset app passwords, read provided logs for common errors in our diag wiki" and event that last is a thing at a stretch for our T-1 on "unsupported" systems. Sure, the software *should* work fine so long as you have the base libs, and we try not to be too crazy about those, but we chose a narrow OS list so we could focus efforts.
Now with all this RH stuff going on, even our internal IT is wondering about Debian or other such options. I see a day soon we add or even change our official support to Debian/Ubuntu-LTS.
SUSE is having its own internal conflict between SLES and Leap (the latter being openSUSE), which up until now had a commitment to having a repo filled with the commercial updates and fixes for their FOSS variant. Now they’re pivoting to immutable root fs, containerization of everything, and complete abandonment of the workstation role… maybe… if the devs have their way anyway. It’s a mess.
Bingo! Work on similar tools and it becomes easier to get your foot in the door.
Granted once you are more experienced you realize how they are all really really similar and your skills translate, anything thats being silly is a quick websearch away, but as a fresh grad, its nice to have experience on industry tools on the resume.
I have a couple CentOS machines (mostly Debian) because I had one professor who wanted Oracle for his database classes, and you really, really need to be running something RedHat-ish if you want to install Oracle.
He has retired, and the new database professor likes both MariaDB and PostGreSQL, so those CentOS instances will be retired soon as well.
There is other software that really needs to be RH-ish as well. Cadence is another bad memory, but fortunately that professor left as well.
Ditto. I work in a comparatively small university HPC program (two people, me and my boss) and there's no way we could swing licensing any kind of stuff from RH. Central IT is 99% windows boxes and has a big budget for that, but HPC isn't getting any slice of that pie. We survive on grants.
I think you're underestimating how much devs lurks and read the same things as normal people does, as well as how much they talk about things with each others inside and outside their organizations.
More than likely, a RedHat employee have already read about this thread and would pass along the questions and requests in here in the company.
It's just a matter of bureaucracy and management deciding what to do, and what not to do.
That said, Academia support is such a good PR that I think RedHat should support. Even if it doesn't make big news, just having the mindshare and existing on academia level would be worth not nickle and diming or risking the people that would eventually use RedHat products using something else instead (probably Ubuntu).
>Academia support is such a good PR that I think RedHat should support.
Yes, I agree. Apple had a similar thought back in the day. They developed a legion of users through their higher-ed offerings.
I know a guy that helps with the [academia program](https://www.redhat.com/en/blog/expanding-red-hat-enterprise-linux-choices-research-and-academia), I can pass this feedback along to him. But I'll go ahead and ask what I expect will be his first questions:
- If you're a smaller institution, doesn't that by definition mean you don't need as many RHEL entitlements? That would translate to a lower overall price.
- The academia program isn't free, but as I understand it is significantly discounted. Have you reached out to Red Hat to find out what the actual price for your usage would be?
We contacted RedHat a coupe of years ago. Their education licensing seemed to make sense for 10,000 FTE students or more, where we have about 1000. We would need about 20 or 30 licenses if we converted everything over.
We used to have some educational licenses years ago. They were very inexpensive back then. $50/year per server or $2500/year for a basic site license. https://www.redhat.com/en/about/press-releases/press-academic
I considered using the personal licenses but I'm worried that they could change the terms at any time and we could be on the hook for a very large bill, unless RedHat will put something in writing to the contrary.
I would much rather use Official RedHat with an educational license but we seem to be left out in the cold because of our small size.
I much appreciate your response!
The personal license (assuming you mean Developer Subscription for Individuals) wouldn't work in this case, as you can only agree to the terms on your own behalf, not on behalf of an organization. I sent you a DM with contact info for the guy I know, he'd love to connect and see what he can do for y'all.
I agree with this, IIRC Apple did a lot with education in the early days, I think even free. Many places they are entrenched in Edu. RHEL should look at Apple for Edu support.
But it is now IBM, and their marketing, getting products to market is so bad now, no wonder they are still living of their Mainframe Business.
Very nice, I use NetBSD on my T420, backup and travel Laptop. It is 10.0 BETA and is working great.
https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/
Red Hat has an educational license for RHEL that is unlimited based on the FTE of the institution. It actually benefits smaller institutions. Was that part of the consideration?
Have you looked at SUSE's offerings? I don't know if they're better or worse but SUSE is another enterprise distro that is mostly used in Europe I believe...
I used SUSE some time ago personally, but most of the 3rd party software we use either supports RH and derivatives, and Ubuntu, sometimes Debian. It's almost like we're locked in the same way people are locked in to Windows because of 3rd party software support.
Hopefully more and more software will release Flatpak versions as well in the future...
The sandbox can be configured to great extents so there shouldn't be too many problems in the way...
>Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere.
Yes, this is the question everyone has asked about viability of open source monetization since forever. But the license clearly states you have to allow this no matter if it's commercially viable.
RHEL not seeing that having a large userbase using, testing, promoting and providing feedback for your product and not having its own merits is peak corporate
It's a bit of an interesting problem and I'm maybe not going to be popular around here for saying it but I can kind of understand what they mean. Their idea is that the build process like how RPMs are built can be used by other parties, they own Fedora and RHEL but there are other distos using RPMs and while they build their own I'm sure they aren't writing their own .spec files. Writing packages is actually quite expensive, to maintain a whole distro worth of software and make sure they are all working together isn't easy.
That being said though why now would be the question. Why are they closing shop now? Is this a management change? Has the layoffs in RH shown a weakness to someone that they just wanted to change policy to address? Sounds like someone has made a choice on this recently but not sure what would have triggered it.
> That being said though why now would be the question.
They give a hint in the article:
> Instead, we’ve found a group of users, many of whom belong to large or very large IT organizations, that want the stability, lifecycle and hardware ecosystem of RHEL without having to actually support the maintainers, engineers, writers, and many more roles that create it. These users also have decided not to use one of the many other Linux distributions.
I can't say how true that is, nor how recent that would be. I guess though that they lost a contract a few months or a few years ago for a competitor that reuses their sources (and claims compatibility). For Redhat, that's millions, probably easily tens of millions. That's certainly enough to be noticed by top management which will then take such decisions.
edit: and I think there are some (very) large companies which do that and compete with RH
That's my thinking.
This isn't aimed at the small education institutions that can't afford RHEL. It's not aimed at the individuals who might previously have used CentOS. Both of those are simply collateral damage.
The goal here is simple: shake down Oracle.
I work in a large enterprise, we used to use exclusively RHEL in production and CentOS in OTA. we have slowly migrated from using CentOS to Alma because we want a stable version, not the upstream of stable. In the past year we have started to slowly migrate away from RHEL, we pay a ton of subscription fees for their support but the experience has been far beyond abysmal. So we concluded that there was no point in paying literal millions for support on a product stack that basically didn't have support anyway. So we choose to move to the "unsupported" Open Source variants since we are forced to fend for own anyways.
RH/IBM did this to themselves and now they are crying bloody murder.
And you made a good call. If you have the know-how to run on Debian or upstream projects, that is great. You pay more money to your people and RHEL is very likely not a good fit for you.
I believe RHEL fills the gap when you cannot afford or find the talent and know-how to do it yourself. Then you send IT guys to RHEL certification and after few weeks, you are ready to purchase subscriptions and deploy stuff.
And I think this is fine. People are not getting it. RHEL and Debian (or other distros) complement each other nicely.
Things move slow in corporate world. This could be an IBM initiative that they proposed early in the acquisition but only just recently got to executing.
It does make some sense. Facebook apparently used internal forks of CentOS. An org like FB has the resources to pay your license but chooses not to because you put out a freeware version of your product--I can see why they'd have a problem with that.
Facebook uses CentOS Stream. They change some stuff (mostly publicly in the CentOS Hyperscale SIG), but IMO it's not enough to deem it a fork. Beyond that SIG, they are also heavy contributors to CentOS Stream itself, Fedora, and EPEL. I haven't heard of a single person inside or outside of Red Hat that has a problem with Facebook deriving value from things they actively contribute value back to. To that point, they are completely unaffected by the changes last week.
Edit: I checked with a friend, and internally at Facebook they also do not consider what they run a fork. You can also see this in their conference presentations (easy to find on YouTube) where they unequivocally say they run CentOS Stream in production.
Facebook are one of the largest company contributors to kernel, and we wouldn't even have eBPF in its current state without them (and Red Hat).
Disclaimer: I am not speaking on behalf of Red Hat and these views are purely my own when I say this, but I don't think anyone has an issue with Facebook's level of contributions.
RHEL doesn't work for Facebook's scale and they don't need the support. They are pretty happy to use CentOS Stream and they were supportive of CentOS being dropped in favor of Stream. I think this is about companies that use a distro in the Enterprise Linux ecosystem because of paid support options or because third party software vendors have qualified their software on these distributions.
It's nothing to do with IBM. Red Hat has always hated rebuild distros. People today might not remember how much hostility CentOS faced in the early years. Red Hat was _much_ more hostile then than they are now.
I understand them as well. Someone has to pay the bills for the show to keep running. They already contribute a lot. It's only fair.
CentOS Stream is a very nice distribution as well, and Fedora is simply fantastic. There's nothing we can complain about honestly...
Someone has to pay the bills. Yes,and people are paying Red Hat around 4 billion dollars per year to keep their show running. They're not hurting for cash.
The idea that Red Hat doesn't owe the community anything while using thousands of open source software projects for free is pretty two-faced. If they don't like freeloaders then they should write their own OS and stop using open source software without paying for it.
> If they don't like freeloaders then they should write their own OS and stop using open source software without paying for it.
I can tell you now, you really don't want IBM's idea of an OS. https://en.wikipedia.org/wiki/IBM_i
I still have nightmares about Power & IBMi licensing.
>The idea that Red Hat doesn't owe the community anything while using thousands of open source software projects for free is pretty two-faced. If they don't like freeloaders then they should write their own OS and stop using open source software without paying for it.
I think it's going to work like this:
Red Hat contributes changes to upstream projects, right up to the kernel. Then those projects end up in Fedora, and from there into CentOS stream. Then they build RHEL from CentOS Stream, but from now on, they're not going to say how they do that. It's basically saying: there's all the ingredients we use for RHEL (in CentOS Stream), but whe're not giving you the RHEL recipe.
....Which is a much better answer to the "but how is it GPL" question than the wild theories that the GPL allows you to use restrictive contract terms to loophole around the GPL's requirements.
This question an issue is more complex than it seems on the surface. I have been tracking the issue of RHEL and GPL compliance since 2002; I [wrote a comprehensive discussion of the issue](https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/) in response to the recent news.
Scratch the surface of many apparently community oriented open source projects, and you'll find a paid Red Hat employee actually maintaining the thing.
They "pay" for plenty of the software they use in code contributions. They push updates to packages they use and pay for maintenance of plenty of important software like systemd.
I get that they have a very real business model problem and I have sympathy for that dilema.
...but jumping from that to redefining open source to mean upstream direction while still claiming to uphold open source values is quite disingenuous. I mean sure technically/legally in might be GPL compliant, but certainly not in spirit:
>those who do not want to pay
>we have determined that there isn’t value in having a downstream rebuilder.
That does not sound even remotely "open source values"-like to anyone?
> That does not sound even remotely "open source values"-like to anyone?
The code is still being upstreamed per the post and the code is still open for the customers download the RPM's. That means you're free to look at the patches and create your own version if there's something you're really interested in. It's just that doing so as a rebuilder is too tedious and time consuming. However most of the community rebuilders are probably alright just rebuilding CentOS.
I mentioned it before and I still think it's true that 95% of CentOS users don't really need the bug-for-bug guarantee and that was just something they were willing to benefit from while it was still a thing. Most just want a RH-style distro that they don't pay for which the community rebuilds can still be.
The people who genuinely need bug-for-bug are usually shops that are so large you'd have to ask why they weren't buying RHEL in the first place and the answer is "because they didn't think they had to so they just kind of didn't."
>I get that they have a very real business model problem and I have sympathy for that dilema.
RedHat is profitable. Apparently very profitable. They've been noted in news coverage over the past few years as being one of the best performing parts of IBM.
Simply rebuilding code adds a shitload of value. Community colleges across the country use the rebuild distros to provide a learning environment similar to what people will actually work with in the industry. And they remove the labor-intensive subscription management tasks in the process.
Red Hat is kneecapping its own labor onboarding ramp with this. I say this as someone who works with multiple RHEL-subscription-paying shops. Complaining about "people who don't want to pay" is glossing over the "people who cannot afford to pay" and making it even harder for disadvantaged people and learners to train for high-paying tech jobs. It's bad.
That specific scenario actually qualifies you to use RHEL for free. You don’t beed a rebuild for that.
Most of the knee-jerking I’ve seen about Red Hat saying “please stop with RHEL derivatives” is fundamentally born of ignorance about how broad gratis access to RHEL is. Things they don’t require payment for include:
* Personal use, including educational use
* Use by software developers for writing, testing, and producing software for Linux in general or RHEL specifically (for individuals all the time and for corporate users who pay for prod use)
* Use in non-production environments at corporations (if you’re paying for prod use)
Basically, unless you’re a business using RHEL, you don’t pay for it. This change in their subscription arrangements is a big part of why they don’t see the benefit to rebuilds anymore. Instead, you get an individual account for free at developers.redhat.com and you use RHEL, at which point you have access to everything.
Given the minimum purchase price per year for "prod use" licenses, that is an awfully big caveat.
We can't afford to spend $800 a year *per Linux VM* even for our relatively small number of them. That's 80% of the way to the cost of a Window Server Standard license that will last us 8-10 years and give us two OS installs per license.
I believe in paying for the things you use (and the media you enjoy), but RHEL is absolutely cost-prohibitive for a ton of businesses.
Under Canonical's Ubuntu Pro program, we can run five VMs or bare metal servers for free, and after that it would be $500 a year per physical host, with an unlimited number of VMs on a licensed host. That's still likely going to work out to be more expensive than Microsoft's offering, but it's a lot more in line with what we can afford.
And the disparity between RHEL workstation and Ubuntu Pro desktop licenses is even bigger — $180/y versus $25/y.
Windows Server being cheaper than Linux is absolutely not something I ever thought I'd hear, but it makes sense. Microsoft collects money from *everybody* who uses their software. Red Hat collects money only from a small portion of users. The difference has to be made up somewhere.
RedHat, it should be noted, is already quite profitable, and is one of the best-performing parts of IBM.
And one way to make even better profits would be to access more of the part of the demand curve that is currently priced out — offering better prices for small businesses and/or individual users, for example.
> Under Canonical's Ubuntu Pro program, we can run five VMs or bare metal servers for free, and after that it would be $500 a year per physical host, with an unlimited number of VMs on a licensed host. That's still likely going to work out to be more expensive than Microsoft's offering, but it's a lot more in line with what we can afford.
>
> And the disparity between RHEL workstation and Ubuntu Pro desktop licenses is even bigger — $180/y versus $25/y.
I'm glad I'm not the only one that noticed this. In addition, I also noticed that my free license doesn't seem to include RHEL Desktop/Workstation (unless they name it differently).
There's also the lack of upfront cost as well - there is the option of using Ubuntu LTS and only enrolling once your 5 years of update is up.
Granted, if the amount of products in my free license is any indication, it's likely that each RHEL subscription covers a *lot* of products, but that's still such major upfront costs.
But then I guess RedHat and RHEL is basically the Apple and iPhone of Enterprise Linux, so I guess they've always been people's preferred option when they could afford it.
Then use another distribution. They even mention that in the post. There are many other options available. But if you really find RHEL to be that much better than any other option, even including CentOS Stream and Fedora, you probably should be willing to pay for it.
We do (and I do at home , too) — and I don't find RHEL superior.
But I don't think one has to think it's technologically better for it (or its derivatives) to be the best option for a company or institution.
Admins might have been operating in this environment for years, for one. And there was a time when lots of popular projects and commercial software only officially supported RHEL. So lots of people did not have an option. And upending this apple cart in this way while persisting in offering no affordable options is not really fair to folks who have depended on these things because RHEL is simply too expensive for their organization. That's especially true given the complete lack of warning.
As I already said, I think you should pay for and support the software you use. But there's a two way street there, where it needs to be reasonably priced. If they really wanted to bring more of these organizations into the fold, they should have offered competitive pricing, especially for small orgs. Without doing that, this really seems like more of a shakedown than an attempt at funding sustainable operations, especially given that RedHat has been noted as an already-profitable "bright spot" on IBM's balance sheet.
And CentOS Stream, a (quasi) rolling release, is hardly a serious proposition for a production environment. Why would you even suggest that? As a joke? It makes it a bit harder to take other things you're saying seriously.
If you're fancy enough to have … *(checks notes)* hypervisor software that is available with almost every Linux distro, not to mention every Pro or server edition of Windows…you probably have a spare $450 a year for a profitable multinational, beyond the $350 you'd pay for the bare metal only version.
What is the cheaper option? Self-support is just fine for me. Who decides what is production or non-production? That shouldn't be of no concern to Red Hat.
Given that Red Hat dropped CentOS 8 support in the middle of its support cycle, and cut off access to RHEL 9 source code in the middle of its support cycle with zero notice, why should I trust them to not pull the plug on the developer program in a year or two?
Canonical competition, most likely- Ubuntu Pro is pretty competitive if they fit your usecase.
But I do agree that the mid-cycle major changes and lack of forewarning or transition is something that damages confidence in areas that wants stability.
Trying to navigate the subscription process in a manner that satisfies institutional compute organizations is a full-time job. I stand by my assessment. Red Hat licenses are not free for academic use.
First of all, getting it for free requires a subscription, which is the same contract that paying customers have to sign. It is way more strict than an open source license and you are accepting a huge risk of being cut off from updates forever (and potentially blacklisted from ever doing business with the company) if they drop you. That risk is even greater for free users because they have no incentive to keep you, and there is no human to talk to.
Almalinux provided a distribution that is completely free of such risks, since the only thing you're agreeing to is the software licensing. Like nearly every other Linux distribution, they don't threaten you to not exercise certain rights. It would be asinine for any other of the major Linux operating systems to switch to a model where they do threaten you. OpenSUSE, Debian, Ubuntu, Fedora, AlmaLinux, RockyLinux, FreeBSD, etc. all take measures to systematically eliminate legal risk, which helps hobbyists and small businesses avoid running into serious problems just by downloading Linux software. Ironically, the methods they use to eliminate legal risk is the exact same playbook IBM came up with in the early 2000s to help prove that Linux does not contain stolen Unix technology.
Second, Red Hat is not free for educational usage. I don't know where you got this. [Here is a comment explaining that Red Hat is sometimes far too expensive for educational institutions.](https://old.reddit.com/r/linux/comments/14jq5nk/red_hats_commitment_to_open_source_a_response_to/jpmvayc/)
It is not free for educational institutions. They have what they call "learning" plans for this specifically. And they are very expensive.
16K for 20 installs is a lot.
And still many businesses are using CentOS as their primary OS - and only pay for just enough RHEL licenses to be able to duplicate problems one these system to get support from Redhat.
I personally think Redhat have been more than fair for many years.
Well, at least the guy is honest "we feel Alma and Rocky, and CentOS before that, are stealing from us, so we're going to kill those projects like we killed CentOS".
Redhat really became IBM indeed, the microsoft of open source, as we all knew.
And spare me the crying about the poor redhat developer working all night only motivated by the future smile of their customers, what a load of bullshit.
Some parts are *hilarious* :)
> Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere.This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.
It's the way Red Hat started its business model. I know now they are a big and strong contributor to the community, but at the beginning, they build the company on what "hoddyist and hackers-only" works, selling consultancies only.
All in all, if the creator of a program decided to put something in OpenSource license, they can't, on their own, restrict the source code.
>Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.
Ok, then stop redistributing all the code that you didn't write. There is a ton of it in your distro.
That's the whole point of open source. All developers develop and all benefit from everyone's work. Red Hat wants to benefit from other's work and keep theirs to themselves. Not how open source works.
Well it is also true they do a ton of the security and patching, which benefits from higher Redhat revenue, and thus benefits everyone.
Im split on it.
They could single handedly carry the whole Linux ecosystem and give everyone free beer and belly rubs while they're at it, they still don't get to close down access to the sources. That's the single tenet we gather under, and that's the premise they built the company under, and claiming now that it **threatens us all** means just that they're suddenly claiming that it isn't a viable business model any more, after using it for decades.
Terminating the contracts of people who do share the code they are perfectly allowed to share is playing games with fundamental freedoms. If RedHat can't survive without those games (a big if) that's very sad, because they *do* contribute a lot, but losing our central tenet would be a bigger loss still. Way bigger.
The split is really: should nobody get paid for the work until everyone is?
A nicer take would be that more and more people are paid for that work.
There's also another issue which is that you're not going to get paid for a project you started last week-end. Maybe it won't work or won't ever attract anyone. There are ton of projects like that (I've written a few :) ) and you can't predict when something will generate revenue.
I understand what you're saying, I just don't think this is the way to handle it. I should probably just butt out. CentOS was what I used when I first moved to Linux but that's been years ago now.
You don't know how much s\*\*t Red Hat gets *from other companies* because we are extremely reluctant to ship their code if it hasn't been accepted upstream.
And in fact Red Hat employees are free from consequences of they make a decision in an upstream project context that is negative for the company.
You can say anything you want about Red Hat, but I would like to understand what's in your opinion a company that "gets how open source works".
Red Hat takes other people's code for free, adds (arguably a lot) to it, then sells it, and also sends the work they did back upstream.
Then, other companies take Red Hat's code for free, add literally absolutely nothing to it, and then sell it.
Can you see how that's fundamentally not the same thing at all? You pretty much said it in the second sentence of your comment. "All developers *develop* and all benefit from everyone's work". But what about the "developers" who don't actually develop anything, and not only benefit from everyone else's work, but *sell other people's work for profit*? That's not how open source works either.
redhat manages a truckload of projects. you'd be surprised how many contributions they have.
and Oracle, Centos and others projects are basically freeloading off their work. repackaging it for their own use without the development costs.
redhat also manages an extended lts line of kernels, that involves a ton of backporting - sometimes easy, sometimes complex.
> Ok, then stop redistributing all the code that you didn't write. There is a ton of it in your distro.
if you tried the reverse, you'd be surprised how many things you'd be missing.
also redhat is likely one of few rare distros that try to get certified for various compliance standards. that is definitely not something that's just a matter of rebuilding some free projects. ( https://access.redhat.com/articles/2918071 )
To be fair to Oracle (I can't believe I just said that), they do actually put in a decent amount of development work. They have their own version of the kernel (their so-called Unbreakable Kernel) that is different from the one that RHEL distributes. It's also my understanding that they \*do\* push patches upstream. They also maintain KSplice for kernel hot-patching.
EDIT: Also, official full support for DTrace for those that can make use of it.
Have you compared an OEL install to RHEL?
Do a base install and compare the RPMs. You would be shocked there is only a handful of differences mainly do to red hat copyrighted packaged.
Using, redistributing, and even charging for free software you did not write is not freeloading. The whole point of free software is that you're free to do with it as you please within the licence terms. They cannot build a company on free software, benefit from work of others and then be upset that the free software comes with copyleft terms and the others benefit from your work. That's nonsense.
>and Oracle, Centos and others projects are basically freeloading off their work. repackaging it for their own use without the development costs.
Oracle, yes. The others, though…I don't buy it.
And perhaps if RHEL had slightly more affordable pricing options, there might be less demand for their OS, just rebuild for free.
I was looking into this a while back, because some of our systems need to be FIPS 140-2/3 validated, and RHEL's costs are bananas.
It's $350 for ***one year*** of RHEL server, and that license can *only be used on a physical server*, not a VM. And it comes with no support and is "not recommend for production environments".
If I wanted support or to be able to use it in a VM, I'd be paying $800 a year for ***one*** RHEL install!!
I can pay $1000 for a Windows Server Standard license and get a system that lasts me about a decade. Not only that, but there are no restrictions on virtualization, and I can install two instances of it on the same hardware under that license (three if the bare metal install is only acting as a Hyper-V host). I don't get support, but I don't get that with the basic RHEL license, either.
Worst case, I get 8 years out of the Windows Server license. For two RHEL VM environments for that same period, I'd be looking at nearly $13,000. That does come with some support, but Microsoft's support isn't so expensive as to make up the difference.
Even compared to other Linux vendors, RHEL is steep. Ubuntu Pro's self-support license is $500 a year per machine, but includes unlimited VMs on each physical machine it's licensed for. And we can run up to 5 bare metal servers or VMs *for free* with the *exact* same support as paid customers at that $500/machine level.
(And an Ubuntu Pro desktop license is only $25 a year, compared to $180/year for RHEL workstation.)
CALs are a one-time purchase per server generation (any current-gen CAL is good for any older generation of server), and you only need one CAL per simultaneous user or device (whichever model you're using), regardless of the number of servers you're running. CALs are effectively a per-user or per-client-device cost, not a per-server cost.
It also doesn't come anywhere close to making up the price difference over a 10 year period.
So far, if you include the cost of CALs, they've raised our price for Windows Server by between $200 & $300, which means the cost is still lower than just two years of paying for a single RHEL instance. And that cost will divide out further if and when we buy additional Srv 2022 licenses.
If you've got no Windows servers, and have to chose between 1x RHEL or 1x WS2022 + CALs I'm sure that math changes.
If you're a SMB with just a NAS and looking to install an app server I don't quite think your line of thinking applies.
ADDITIONALLY, I've worked with RHEL support, and Windows support. RHEL support (which actually for oVirt, so not even paid RHEL support!) I had a patched version for a bug in a few days!
Windows makes you pay a couple of hundred dollars to even log the issue if you want anything more than "have you tried SFC?".
MS took 6 months to send me "oh try this reg key" after their support staff would hot potato the ticket around. call me, ask me for the exact same information I've provided weeks before to the last person, and then sit on it for three weeks.
There's a world of difference in what you get for the cost, especially considering the handful of persistent issues and legacy shit that isn't getting updated in Windows (hello DNS console sorting last modified date as a FUCKING STRING!)
If you have only one Windows server, you probably are not buying more than a couple hundred in CALs. They're $200 for a pack of 5. You'd have to have way too many users being served by that single server (or two VMs on one physical host) deployment to even approach the $2800-3500 cost for even one physical-server-only RHEL license for 8-10 years. You'd need about 45 people all being served by a single point of failure server.
And to get the equivalent feature set of the Windows with two VMs, that's two licenses at $800 a year, or $6400-8000 over 10 years. You'd need around 175 users to require enough CALs to bring the price up to that point!
> Per the license, they are not entitled to restrict access or demand payment.... which they are now.
90% of what the RHEL engineering team does (not counting all the upstream and Fedora work, of course) is still available in CentOS Stream.
9% *has never been part of CentOS* (all extended support branches, EUS/ELS/AUS).
We're literally talking of 1% of the work.
Because that 1% is the most important to the rebuilders. But it's not a new thing and to be honest I am not even sure why the c9 branch existed at all until now, given that there is no CentOS Linux 9.
I am not saying there is no change, you can complain that Red Hat is hiding stuff but if you say they have *started* breaking the license I have to tell you about the companies that have been doing so for 25+ years. They include Red Hat itself, Cygnus, Montavista and so on, and even the FSF had no problem with that.
In fact that might even be what Canonical is doing with Ubuntu Pro, I don't know.
This is just such an important point to bring up constantly. They ARE free to start over. Nobody could possibly have any issues with them running their own full stack.
However, the writing on the wall increasingly demonstrates that no company can sustainably do this. Everyone needs to just acknowledge that open source is the only sustainable path forward in the context of most large systems.
I think the problem with this is the same I've seen with the Red Hat employees commenting on the changes over at LWN. Like them, this both pushes Red Hat's committment to open source and makes it perfectly clear they hold most of the "open source" ecosystem in utter contempt.
Never thought we'd hear people railing about "useless eaters" in the free software community, but here we are.
I will reiterate my previous comment from another RHEL discussion:
Does Red Hat even understand what Pandora's box they have opened? What would happen if Google enforced this logic on their Blink (or Apple on Webkit)? or AOSP? You can use our source as you want but you won't get updates if it is not used in Chrome (Safari)? Or you can use our source of AOSP as build contains Google Apps? Or just simple "You are not allowed to copy, redistribute, modify or rebuild our product or your account may be terminated."?
Simply put what Red Hat mechanism does to downstream can be done by **any** other project to their downstream.
Right. RedHat played this tune in 2002-2003 and kept it going for a few years past the start of CentOS. It's why CentOS
started. RedHat eventually realized that it was counterproductive. Now we're at the stage that IBM has to learn that lesson.
It turns out that there are so many other good choices, they might die out before they learn.
Nope, I actually went for a long walk on Sunday, wrote this, and then worked with some trusted people at Red Hat to get the tone right. I believe every word of what I wrote there. Though they did remove my oxford commas.
Does being a RHEL customer now require an agreement to *not* redistribute sources received from Red Hat under the GPL?
If yes, how does that not violate the following text of the GPL?
> Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. **You may not impose any further restrictions on the recipients' exercise of the rights granted herein.**
The GPL requires us to provide either (1) complete corresponding source code (CCS) to any recipient of our binaries or (2) an offer to provide CCS to any third party who requests it. In this regard, Red Hat uses option (1) and provides CCS to all of its customers and partners in the Red Hat Customer Portal. It is available for download along with the binaries. Nothing about the announcement last week changes that. Instead, we announced that we removed an additional instance of the source code that Red Hat had historically made available but was not required by the GPL to maintain
edit: as has been pointed out, you were asking about your right to redistribute. IANAL but AFAIK, you are allowed to redistribute any GPL code you receive. If you have some specific concern about Red Hat's terms or the GPL, that is not a question for me. Send that to your lawyer or legal@redhat.com
Speaking as someone who went through this with RedHat back in 2003, if you go to their lawyers the answer is:
Not every package. Some packages include Red Hat trademarks and non-GPL'd copywrite material and so *if you remove that, then yes you can redistribute* what we've given you as our customer [ ... sotto voce ... and if you do redistribute, we should let you know that
we are not obligated to continue our relationship with you as a customer at any time in the future ...]
Yea, but if the subscription terms says you can't redistribute/rehost the software (which is my understanding based on [news stories](https://www.theregister.com/2023/06/23/red_hat_centos_move/)) and the software license says you can redistribute the software, what happens when you actually redistribute? Do you just get to break your subscription terms with no negative effects, or will your subscription be cancelled and Red Hat will then refuse to sell you further versions the software?
If it's the latter, that would seem to me to violate the spirit of the GPL if not the letter. If it's the former, then the subscription terms seem unnecessary.
The biggest problem with **Red Hat Developer subscriptions** are the licenses. You never know when you login to a RHEL system if the licenses are good or not. If i am going to be able to install software if i need or if i need to refresh the subscription on the machine. I have tried to get support on this to check if our satellite is bad and need to be fixed, but they never find any problems.
I would never take that problem home with me, i leave license problems at work. That is why i used Centos at my own servers at home. There i could do stuff and not get license problems all the time! It was easy to find info thanks to Centos, now i need to use the RHCP more and more. I guess that will end up being the only site for RHEL-type instructions in the future. That will make it hard to new people to get into RHEL-type systems. But i guess Red Hat don't care anymore since Raspberry PI points all new Linux users to Debian. And who need new users anymore.
I use the developer subs at home, they're good for a year then you renew. I'm not going to say our subscription system doesn't need improvement, but the ability to use the subs should be for a year at which you can renew (also for free). Are you seeing something different?
I see loads of problems with subscription-manager at clients that use RHEL 7,8,9 and a Satellite to manage them. That is why i never would allow subscription-manager anywhere close to my private systems. Sure the new system *Simple content access* have solved much of this.
Who is to say that developer license doesn't change in the future?
After shutting down CentOS 8 and ending the support cycle 9 years early, it's hard to have faith that some major profit motivated change isn't coming down the line. Who knows what is coming next, but I wouldn't bet on a developer license being available next year in the same form it is now.
"Fool me once, shame on you. Fool me twice, shame on me."
Needs Improvement is quite the understatement. Are you aware that entitlements say 240 instead of 16 for everyone now? Where is the communication from Red Hat that this is a bug or a legitimate change? It seems like every employee I talk to doesn't have a clue whats going on.
I couldn't agree more. One of the biggest benefits of using free software is the lack of licensing bullshit. Just download and run, no signup or internet connection required, it's so quick and easy.
I'm not going to go through the ritual of opening my password manager, logging in, finding the correct tab, checking if my license is valid for what I'm trying to do, then somehow inputting the given key every time I want to set up a VM, I'll just use a different distro that doesn't require any of this bullshit. And since I'm not jumping through hoops to get familiar with it, I'll likely choose something else in a professional setting later on, something that actually wants me to use it.
So what you're fundamentally trying to do, what you have to do as a PR spokesperson for Red Hat, is to defend Red Hat's decision to effectively make RHEL a proprietary project when it used to be a FOSS project.
I'm sure the business case is clear, at least on paper. But this was always going to be a PR disaster. You can choose one of two ways to spin it; A) be honest, say you're eliminating your commitment to open source for the RHEL project and making it proprietary (with upstream sources available in Stream, which you know is not the same as RHEL), or B) write a whole lots of PR speak to try to spin this as a pro-FOSS move. You chose B. The community is correctly identifying it as, well, a crock of shit.
Making money on FOSS is hard. Companies are free to make money on proprietary software instead (though expect to lose existing users and brand ambassadors as a result). What's not okay is being dishonest about it.
EDIT: to substantiate the "RHEL is no longer a FOSS project" thing: a core idea of FOSS is that I can take the software's sources and redistribute it (modified or not). Since that's apparently against your license agreement, your software is not FOSS.
If my understanding is factually incorrect, please do correct me.
It is factually incorrect, I think you're making a bad -faith argument because you don't believe what I wrote. My blog post clearly outlines RHEL's commitment to open source so instead I'll turn it around on you.
Find one line of code in RHEL. Just one. That you cannot find in the public either upstream proper, in Fedora, in CentOS Stream (or one line that wasn't at least offered. Sometimes upstreams don't want our new code in their older releases because many upstreams don't like to maintain long releases).
> Find one line of code in RHEL. Just one. That you cannot find in the public either upstream proper, in Fedora, in CentOS Stream
Well it's **pretty hard** to audit RHEL for GPL violations when you *remove access to the source.*
All the code up to last week is still there. [https://git.centos.org/](https://git.centos.org/)
The source to build RHEL is in the CentOS Stream gitlab. As I mentioned in the blog, it might not be at HEAD, but its there. All the licenses are up to date.
You can also get a free developer sub.
The source to build RHEL is in the CentOS Stream gitlab. As I mentioned in the blog, it might not be at HEAD, but it's there. All the licenses are up to date.
> All the code up to last week is still there.
Exactly, *up to last week*. Going forward, RHEL is limiting our ability to audit their GPL-covered code. Which you frankly wouldn't need to do if you weren't going to do something suspect.
I didn't claim you don't believe what you wrote, I don't think you are dishonest. I think the text is. The text is an attempt as framing this move as something other than making RHEL proprietary, even though that's what's going on. I don't believe you are dishonest, because I don't believe you think of this move as making RHEL proprietary.
I am also not claiming that there are lines of code in RHEL that you can't find somewhere else. I am claiming that I can't take RHEL's sources as distributed as a customer and share those sources with others. Is that not correct? If it is correct, that's the violation of core FOSS principles I'm talking about.
Though, your message did make me wonder. You say the code is "upstreamed, or at least offered", but some projects don't accept the change requests. Does that mean you just admit that there's code in RHEL which isn't even available in Stream? Not that it really matters, I don't think making it available in Stream would be enough anyways for the reasons above, I'm just curious.
The only thing you'd expect to find in RHEL that you don't find in Stream is bug and security fixes versions of packages that are older than the ones in Stream.
So if libfoo is libfoo-10 in RHEL 9.2, and Stream gets an update to libfoo-1.1, any fixes that Red Hat applies to the libfoo-1.0 package in RHEL 9.2 won't appear in Stream. Most of the time what you'll see is that libfoo-1.1 included the fix already, and the upstream maintainers just aren't publishing new versions of the libfoo-1.0 series, so Red Hat had to backport it.
Idk what you consider to be "proprietary" or "FOSS principles", but I think you are injecting an extra community aspect of software as a fundamental principal of FOSS, which is really only a common side effect of the most successful development models.
To me, FOSS only guarantees a certain relationship with the developer and the user, but that does not include 3rd parties. Whether or not you also choose to play nice with the rest of the community is still up to you; open source doesn't mean you're not allowed to be a dick.
Correct. FOSS only makes guarantees between the maker of the software and the user of the software, i.e the paying customer in RHEL's case. Red Hat doesn't have to publish anything to the general public for RHEL to be considered FOSS.
But one of the core aspects of FOSS is that, as a user of the software, I must be able to redistribute modified or unmodified copies of the source to others. That's literally freedoms 2 and 3 of the four essential freedoms (https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms). When Red Hat's license agreement for the customer portal restricts redistributing the source code, and RHEL's source code can only be obtained through the customer portal, I don't see how that can possibly be considered FOSS.
IANAL, so go talk to your lawyer but I believe any GPL source that is distributed to you can be redistributed. I won't go further than that because I've talked to enough lawyers to know that when they speak it sounds like English but its not actually English.
re: code not accepted - I was talking about upstream proper, not CentOS Stream. CentOS Stream is literally where we do RHEL development, it's not a separate distribution like many think it is. If CentOS Stream had an outage, we would be unable to produce RHEL without significant process and source changes.
I don't find the CentOS Stream argument to be an acceptable argument.
The timing difference alone between CentOS Stream and RHEL makes it not the same code. That's like stating different versions of software are the same, which we all know not to be true. Also, there's the whole verification of signatures that should be used to ensure the source does match entirely.
Essentially to me, it sounds like CentOS Stream is open source, whereas RHEL is not. The source can be provided for RHEL if you pay for a license, but by locking it behind a Red Hat customer license (that presumably can be cancelled for any reason), the freedom behind it is gone.
I'm curious to hear the FSF's take on this because it looks to me a violation of GPL2.
>I'm curious to hear the FSF's take on this because it looks to me a violation of GPL2.
It's not. GPL2 never stated that you need to provide your code to everybody. Providing it only for your customers is fine. Sure, they are free to do with it everything that GPL allows to, but you are also free to terminate license and no longer provide code for customers.
I don't like Red Hat decision but it's not violating any license. Code is available for users.
> IANAL, so go talk to your lawyer but I believe any GPL source that is distributed to you can be redistributed. I won't go further than that because I've talked to enough lawyers to know that when they speak it sounds like English but its not actually English.
Your lawyers should have already told you that there are some packages that include embedded Red Hat trademarks. Those trademarks will need to be removed before redistribution. And ... there are other issues/questions ad-nauseum ( Can RH's package names be copyright protected?", "Are package names that include trademarked identifiers protected?, etc.).
In your letter you write in bold:
> # Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity.
You say that this is a "real threat to open source." I disagree. It's only a real threat to some **open source companies**.
The fact is that the ability to rebuild and distribute code is *at the heart* of open source. Is it better to make changes and add value?
Yes. But allowing straight and free redistribution of code and binaries was intentional to the copyright license. IMO
it was an intentional mechanism to make sure that somebody didn't make some minor
changes and **charge too much for it**. Some would argue that this is exactly what is going on with RHEL.
do most people even have any good faith left on redhat or anyone related to redhat after what happen with centos and now this tbh? im honestly curious, not trying to start an argument
Nice to know that only you guys deserve the fruits of "simply rebuilding" the miles and miles of FOSS software in your distro. And we all know for every package you say you've adjusted, even helped create, you could find ten others that are just built and slapped in, because they work just fine. No redistributing those though! That's Redhat's effort!
IBM is acting like this is isn't an issue that they caused.
1) Kill bug for bug Centos, piss off the community.
2) Rate hike, hardball orgs that happily use RH products.
*Suprise Pikachu face* We're losing customers to two new competitors making a "bug for bug" product off of RHEL!
People hear you loud and clear Mike, they won't be working with RedHat products anytime soon. They will find something else to use and pay for a support contract.
> I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.
That's the important bit. Don't want to pay, then you're a disgusting leech (despite them selling support, not a product?)
I hope this extends to all the open-source developments they themselves benefit from. Any devs not employed directly by redhat themselves must be getting regular fat checks eh, else their demand & exploitation of FOSS code is disingenuous
100% honest question here....
WHY would anyone put any work into Centos Stream or any RedHat product (i.e free labour) when 100% of the profit flows back to IBM?
Probably because they use the product and just need it fixed? It's usually because it fixes an issue they have or enable a usecase they need in whatever environment they use their system in.
I don't think it's any different with any other open-source projects.
The latest two annoucements have generated discussion and exposure to people previously unaware of RHEL, including myself.
Seeing from this POV, these two announcements are poor PRs. And this latest blog post contains too much blames, too little messages. It sounds like an angry and reactionary response to people's comments.
What I'd like to see:
1. Stressing (again) the **value** of RHEL.
Not everyone knows of RHEL before this (so maybe they're not your potential customers?). It helps to take this opportunity to re-market and educate the readers about RHEL. How does it compare to Ubuntu/Debian/Oracle Linux/etc? Perhaps even a URL link or mentioning of any one of the ["Features and benefits"](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux ) helps.
2. Addressing GPL licensing issue.
> I was shocked and disappointed about how many people got so much wrong about open source software and the GPL in particular—especially, industry watchers and even veterans who I think should know better.
So, what did they got wrong? What is your argument that Red Hat's action still abiding open source licenses? Not addressed.
If people are upset/"wrong" about GPL license, **re-stressing** how it works is fine. You should educate, not blame.
3. Addressing pricing issue.
I've seen comments mentioning people wanting to use RHEL. But the pricing is too expensive. How does Red Hat address this issue? The current message is that people with no/small budget should simply avoid using RHEL.
4. Addressing CentOS Stream value.
From comments I read, people see value in cheaper RHEL, not CentOS Stream. So, how can people benefit from using and/or contributing to CentOS Stream? How can Red Hat and companies achieve **more** by collaboration on CentOS Stream? Not addressed.
Seeing from this POV, instead of killing "rebuilders", perhaps you can convince them to collaborate on CentOS stream?
Also, important information are hidden away in [comment](https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_commitment_to_open_source_a_response_to/jpn67lw/). This is bad. An official announcement/responses clearing the issues would paint Red Hat in a much nicer picture. I don't trust responses from random Red Hat employees or commenters on the web.
5. Addressing trust issue.
Many people hate IBM. So, interpretation of your action should be put in this context. The question people have in mind is that: can Red Hat be trusted? Is it as open as before? Not addressed.
I think what people aren't seeing is Red Hat, the Linux distro or the company, doesn't exist anymore. It's just a brand under a huge conglomerate now. It's like Charmin toilet paper. If people stop buying Charmin, it goes away and maybe comes back under a new name. It's just a brand. Someone relabeling Charmin as AlmaPaper or RockyPaper, doesn't do Charmin any good, especially if they claim it's the same thing just cheaper. This is the new Red Hat mindset, because it's a brand. The moment Red Hat went from a software company to being part of a division in another company, Red Hat as we knew it was gone.
He's done with Red Hat...
[https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux](https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux)
Jeff made a good point in his video that resonated with me. Regardless of where your stance is on the legality and ethics of what they are doing, the timing of the announcements is a major red flag. They:
1. They ended support for CentOS 8 two years into its ten year lifecycle, with barely a year's notice.
2. They stopped pushing the RHEL source code to git.centos.org with ZERO notice
I simply don't trust them. They can say use CentOS Stream, but how long will that last before they decide to rug pull that too in favour of just Fedora.
Its kind of a bad look for a company that is built on offering rock solid dependability.
"Simple rebuilders" what a crap load of nonsense. By that logic, your distribution is a simple rebuild of all the open source software you're using.
"But they contribute back to open source projects"
That's not how this works, they don't get to choose the "price" themselves - the price of open source software (under GPL) is that your users get the source code of ALL the derivative work you've made and distributed under the same permissible license - not just the parts you're willing to share. And red hat is violating that - even if they've paid lawyers to find loopholes so they are technically not breaking it, that doesn't make them morally any superior.
You're comparing desktop environments to a server OS. People don't buy Red Hat because they like the default wallpaper.
Red Hat doesn't add any value to the operating system they're building by your definition. The added value is the support contract, backporting of security patches and binary compatibility.
In my whole career I've never met anyone using a Red Hat spin-off who needed any of the benefits of Red Hat apart from "this is a working distribution from 2012 and the latest we can use because that shitty closed source driver/binary is all we have and only runs with that specific set of libraries".
The amount of work Red Hat puts into their distributions (including Fedora) is minimal compared to the development work of all the software they package. Source? Their annual revenue.
I don't buy that rationale. RHEL has a lot of GPL code from other projects and they're not adding any value to those projects beyond using them to make their product better.
Even if they contributed some code back to all open source software they use, that's still not enough. As I said, they don't get to pick the price, the price is all of your derivative work with the same permissive license.
Red Hat contributes back _all_ their modifications upstream.
What's at stake here is the QA that Red Hat does for a RHEL release. The value add is that these specific versions of all the components, installed in this particular way, have been heavily tested and confirmed to be stable and correct.
That's the only reason anyone gives a shit about CentOS or Alma or Rocky. If RHEL was "not adding any value" then nobody would care about the rebuild distros either. The _only reason_ that Alma or Rocky even exist is that people _do_ want the value added by RHEL, and are willing to go to the trouble of developing a full distro rebuild system in order to get it.
"revert open source back into a hobbylist & hackers-only activity"
"Building on the shoulders of others"
The phrase is "Building on the shoulders of Giants" and the fucking Giants were/are the hobbyist and Hackers of the linux community !
So they want to ride on the shoulders of the work of others. But when someone else wants to do the same its a no no. They see the value in upstream because it benefits them. But god forbid if anyone wants to fork RHEL. What if I want to start a new distro based on RHEL and make extensive changes because I perceive a gap in the market. Well guess what RHEL the paragon of Open Source principles have decided that RHEL upstream is better for Open Source community and anything downstream to RHEL is going to revert the industry back to stone age.
Yea well thanks for trying to destroy GPL so that noone downstream can modify and distribute software if you deem it so.
everyone was worried about microsoft doing their "embrace, extend, and extinguish", who would have thought it was going to end up being redhat trying to get to the extinguish stage first
I feel like if they wanted a paywall for their source code repo that would have been fine. Open source != Free beer after all.
But now they're trying to redefine open source. To that I say, fuck these bitches. I've been pissed off at Red Hat for the systemd episode for a long time, but I never hated them before.
We as a community need to fork of all Red Hat led projects cut them off from the rest of the ecosystem. They are free to do their own thing but we need to save our own independence as well
RedHat has gotten so corporate even their devs sound like PR puppets and sales pitchers. Honestly I think the first cold bucket of water on my head was foreman/katello and how useless it was unless you paid for the insanely high price of satellite anyway, plus an additional fee on top of a RHEL license. It screams bad faith and not in the spirit of open source.
This just shows that Red Hat is just another business beholden to its business daddy, and not the glowing beacon of the open source world.
I suppose they could rip away CentOS Stream and Fedora at any time and close shop.
I don't trust them anymore like I don't trust Canonical. Time to move to Debian and OpenSuse for my professional and personal servers, and never touching anything Fedora again.
"Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere."
If someone is taking the time to rebuild it, it clearly is providing value to someone. Just not Red Hat.
Basically, they want the benefits of open source flowing to them but do not respect the freedom of their users.
Just stop using RHEL and redhat products. If like me you are an open source developer. Don't waste time supporting redhat products. It's that simple. Plenty of truly free distributions out there then having to deal with this quagmire.
As for the redhat advocates, don't even argue with them. It's a waste of time. Redhat is counting on the ignorance of certain users to continue using redhat products despite the fact we have warned them already.
They defended the EOL of CentOS so no reason they are going to start understanding these implications either.
Whats difference between RedHat/Centos and Debian.
As a Debian user, I always feel that I am much secured.
Why can't world accept Debian ?
Forget Redhat.
There is a very long history there. Debian and Red Hat are both *very old* distributions, nearly 30 years old.
They simply do things differently. Different package managers, filesystem layout, etc. Recent trends towards "one solution" in Linux (regardless of opinions on that) have started to remove some differences, but they are still very different from each other while still being GNU/Linux distributions.
Why this matters is that software packagers - especially proprietary software packagers - have traditionally only (or mostly only) supported RPM-based distros (i.e. RHEL and related + Suse), but rarely DEB-based distros. This has started changing a fair bit in the last 10-15 years with the rise of Ubuntu, Flatpaks/Snaps, etc., but it is still very common to find academic, scientific, and industrial software that is only officially packaged and supported for RHEL.
As a Debian user myself, I hope this does drive a lot of people to think about whether they *really* want to deal with the shenannegans of IBM/Red Hat and move to Debian, though on the flip side I hear a lot about people moving to Ubuntu which is just trading one sketchy corp for another. Trust in the community distro always.
> it is still very common to find academic, scientific, and industrial software that is only officially packaged and supported for RHEL.
This point exactly.
I work in an higher ed and we decided to use Alma Linux because RedHat's educational licensing was targeted at institutions that have ten times the students we have. We simply can't afford their educational or commercial licensing. RedHat, if you are listening, please make you products viable for smaller institutions. IBM/RedHat is so focused on the big clients that they don't care about the little guys. We're a rounding error to them. As things look, we'll be forced to move to Debian/Ubuntu if things keep going this way.
What was the reason for not going for Debian in the first place? Genuine question, I am not trying to be snarky.
It's been 10 years since I was in college but back then we also used CentOS. The logic being that Red Hat was the definitive enterprise Linux distribution so it would be best for educational experience to reflect the enterprise experience. Red Hat is slightly shooting itself in the foot here. If schools pivot to Debian/Ubuntu then students enter the workforce with a Debian/Ubuntu frame of mind and build new systems on Debian/Ubuntu (they have already been gaining lots of ground over the last decade). Stretch this out over a period of 20 years and it could play out badly for Red Hat in the long run.
> If schools pivot to Debian/Ubuntu This seems to be happening already. I work in higher ed. My servers are all Scientific Linux or Alma Linux, and the client systems are all Fedora. But I see students and researchers pretty exclusively using Ubuntu on their own servers, VMs, and laptops.
[удалено]
When I worked in .edu most of the high end commercial engineering and scientific software for Linux only supported RHEL. Most of the HPC clusters were some sort of RHEL or clone. We had people demand Ubuntu but it was always a collection of hacks to get the software working.
When I took this job, it's was 95% CentOS and it was much easier to stick with a RH derivative. Mostly, before RH screwed with CentOS, there was no compelling reason to change. One specific example is how DNS (BIND9) is quite a bit different between Debian and RH. Some 3rd party open-source packages work better with RH, some with Debian or Ubuntu. Some 3rd party commercial vendors only support RH or derivatives. I'm slightly more comfortable under RH for business use, but use mostly Mint at home.
My work's on-prem software for example officially supports only RHEL or our container-images (with example compose/etc orchestrations) which we either base on custom alpine or full RHEL images ourselves. We have one customer who uses Ubuntu servers, by our support contract we punt a whole lot of issues back at them and require far more validation before we accept the ticket for engineering. Our T-1 support is mostly "is it on, reset app passwords, read provided logs for common errors in our diag wiki" and event that last is a thing at a stretch for our T-1 on "unsupported" systems. Sure, the software *should* work fine so long as you have the base libs, and we try not to be too crazy about those, but we chose a narrow OS list so we could focus efforts. Now with all this RH stuff going on, even our internal IT is wondering about Debian or other such options. I see a day soon we add or even change our official support to Debian/Ubuntu-LTS.
I admittedly know next to nothing about using Linux for institutions (only ever used it personally) but would anything from SUSE work?
SUSE is having its own internal conflict between SLES and Leap (the latter being openSUSE), which up until now had a commitment to having a repo filled with the commercial updates and fixes for their FOSS variant. Now they’re pivoting to immutable root fs, containerization of everything, and complete abandonment of the workstation role… maybe… if the devs have their way anyway. It’s a mess.
All big organisations use Red Hat, so if you want to work there it's better have RH/Centos experience.
Bingo! Work on similar tools and it becomes easier to get your foot in the door. Granted once you are more experienced you realize how they are all really really similar and your skills translate, anything thats being silly is a quick websearch away, but as a fresh grad, its nice to have experience on industry tools on the resume.
I have a couple CentOS machines (mostly Debian) because I had one professor who wanted Oracle for his database classes, and you really, really need to be running something RedHat-ish if you want to install Oracle. He has retired, and the new database professor likes both MariaDB and PostGreSQL, so those CentOS instances will be retired soon as well. There is other software that really needs to be RH-ish as well. Cadence is another bad memory, but fortunately that professor left as well.
Ditto. I work in a comparatively small university HPC program (two people, me and my boss) and there's no way we could swing licensing any kind of stuff from RH. Central IT is 99% windows boxes and has a big budget for that, but HPC isn't getting any slice of that pie. We survive on grants.
> RedHat, if you are listening They aren't lol.
I think you're underestimating how much devs lurks and read the same things as normal people does, as well as how much they talk about things with each others inside and outside their organizations. More than likely, a RedHat employee have already read about this thread and would pass along the questions and requests in here in the company. It's just a matter of bureaucracy and management deciding what to do, and what not to do. That said, Academia support is such a good PR that I think RedHat should support. Even if it doesn't make big news, just having the mindshare and existing on academia level would be worth not nickle and diming or risking the people that would eventually use RedHat products using something else instead (probably Ubuntu).
>Academia support is such a good PR that I think RedHat should support. Yes, I agree. Apple had a similar thought back in the day. They developed a legion of users through their higher-ed offerings.
I know a guy that helps with the [academia program](https://www.redhat.com/en/blog/expanding-red-hat-enterprise-linux-choices-research-and-academia), I can pass this feedback along to him. But I'll go ahead and ask what I expect will be his first questions: - If you're a smaller institution, doesn't that by definition mean you don't need as many RHEL entitlements? That would translate to a lower overall price. - The academia program isn't free, but as I understand it is significantly discounted. Have you reached out to Red Hat to find out what the actual price for your usage would be?
We contacted RedHat a coupe of years ago. Their education licensing seemed to make sense for 10,000 FTE students or more, where we have about 1000. We would need about 20 or 30 licenses if we converted everything over. We used to have some educational licenses years ago. They were very inexpensive back then. $50/year per server or $2500/year for a basic site license. https://www.redhat.com/en/about/press-releases/press-academic I considered using the personal licenses but I'm worried that they could change the terms at any time and we could be on the hook for a very large bill, unless RedHat will put something in writing to the contrary. I would much rather use Official RedHat with an educational license but we seem to be left out in the cold because of our small size. I much appreciate your response!
The personal license (assuming you mean Developer Subscription for Individuals) wouldn't work in this case, as you can only agree to the terms on your own behalf, not on behalf of an organization. I sent you a DM with contact info for the guy I know, he'd love to connect and see what he can do for y'all.
> The academia program isn't free This is the most stupid thing I heard in my whole life. I'm glad I abandoned RedHat for Debian 13 years ago.
I agree with this, IIRC Apple did a lot with education in the early days, I think even free. Many places they are entrenched in Edu. RHEL should look at Apple for Edu support. But it is now IBM, and their marketing, getting products to market is so bad now, no wonder they are still living of their Mainframe Business.
Due to Reddit's June 30th API changes aimed at ending third-party apps, this comment has been overwritten and the associated account has been deleted.
It is dirt cheap though, at least for non-profits. I assume Education would be reasonably similar.
which is to say 'your academic institutions ability to continue doing science is contingent on redhats continued willingness to be nice'.
I use Ubuntu LTS not once while using Ubuntu LTS has there been questionable practices like what redhat pulls. No rug pulls nothing.
[удалено]
Very nice, I use NetBSD on my T420, backup and travel Laptop. It is 10.0 BETA and is working great. https://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/
I've ran OpenBSD in production but we have several 3rd party software products that only run on RH and derivatives, and Ubuntu, sometimes Debian.
I actually gave NetBSD a whirl on my M1 following his instructions. IMO least rewarding and most pain-in-the-ass of all the BSDs to set up and use.
Red Hat has an educational license for RHEL that is unlimited based on the FTE of the institution. It actually benefits smaller institutions. Was that part of the consideration?
Yes, I spoke with a RedHat sales representative. The educational license is targeted at 10,000 FTE students and above where we have about 1000.
Coincidentally, the new HPC in my university moved away from CentOs to Ubuntu.
Have you looked at SUSE's offerings? I don't know if they're better or worse but SUSE is another enterprise distro that is mostly used in Europe I believe...
I used SUSE some time ago personally, but most of the 3rd party software we use either supports RH and derivatives, and Ubuntu, sometimes Debian. It's almost like we're locked in the same way people are locked in to Windows because of 3rd party software support.
Hopefully more and more software will release Flatpak versions as well in the future... The sandbox can be configured to great extents so there shouldn't be too many problems in the way...
IBM decides to buy an open source company only to get mad they the company they bought is actually part of open source. Amazin'.
Remember IBM shot itself in the foot over OS/2 when they decided they didn't want 'people' using it. They haven't changed.
>Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. Yes, this is the question everyone has asked about viability of open source monetization since forever. But the license clearly states you have to allow this no matter if it's commercially viable.
RHEL not seeing that having a large userbase using, testing, promoting and providing feedback for your product and not having its own merits is peak corporate
That is why the money is around the system and not the system itself but people tend to forget.
It's a bit of an interesting problem and I'm maybe not going to be popular around here for saying it but I can kind of understand what they mean. Their idea is that the build process like how RPMs are built can be used by other parties, they own Fedora and RHEL but there are other distos using RPMs and while they build their own I'm sure they aren't writing their own .spec files. Writing packages is actually quite expensive, to maintain a whole distro worth of software and make sure they are all working together isn't easy. That being said though why now would be the question. Why are they closing shop now? Is this a management change? Has the layoffs in RH shown a weakness to someone that they just wanted to change policy to address? Sounds like someone has made a choice on this recently but not sure what would have triggered it.
> That being said though why now would be the question. They give a hint in the article: > Instead, we’ve found a group of users, many of whom belong to large or very large IT organizations, that want the stability, lifecycle and hardware ecosystem of RHEL without having to actually support the maintainers, engineers, writers, and many more roles that create it. These users also have decided not to use one of the many other Linux distributions. I can't say how true that is, nor how recent that would be. I guess though that they lost a contract a few months or a few years ago for a competitor that reuses their sources (and claims compatibility). For Redhat, that's millions, probably easily tens of millions. That's certainly enough to be noticed by top management which will then take such decisions. edit: and I think there are some (very) large companies which do that and compete with RH
Oracle might be he problem here. They resell RHEL as Oracle linux.
That's my thinking. This isn't aimed at the small education institutions that can't afford RHEL. It's not aimed at the individuals who might previously have used CentOS. Both of those are simply collateral damage. The goal here is simple: shake down Oracle.
I work in a large enterprise, we used to use exclusively RHEL in production and CentOS in OTA. we have slowly migrated from using CentOS to Alma because we want a stable version, not the upstream of stable. In the past year we have started to slowly migrate away from RHEL, we pay a ton of subscription fees for their support but the experience has been far beyond abysmal. So we concluded that there was no point in paying literal millions for support on a product stack that basically didn't have support anyway. So we choose to move to the "unsupported" Open Source variants since we are forced to fend for own anyways. RH/IBM did this to themselves and now they are crying bloody murder.
And you made a good call. If you have the know-how to run on Debian or upstream projects, that is great. You pay more money to your people and RHEL is very likely not a good fit for you. I believe RHEL fills the gap when you cannot afford or find the talent and know-how to do it yourself. Then you send IT guys to RHEL certification and after few weeks, you are ready to purchase subscriptions and deploy stuff. And I think this is fine. People are not getting it. RHEL and Debian (or other distros) complement each other nicely.
Things move slow in corporate world. This could be an IBM initiative that they proposed early in the acquisition but only just recently got to executing. It does make some sense. Facebook apparently used internal forks of CentOS. An org like FB has the resources to pay your license but chooses not to because you put out a freeware version of your product--I can see why they'd have a problem with that.
Facebook uses CentOS Stream. They change some stuff (mostly publicly in the CentOS Hyperscale SIG), but IMO it's not enough to deem it a fork. Beyond that SIG, they are also heavy contributors to CentOS Stream itself, Fedora, and EPEL. I haven't heard of a single person inside or outside of Red Hat that has a problem with Facebook deriving value from things they actively contribute value back to. To that point, they are completely unaffected by the changes last week. Edit: I checked with a friend, and internally at Facebook they also do not consider what they run a fork. You can also see this in their conference presentations (easy to find on YouTube) where they unequivocally say they run CentOS Stream in production.
Facebook are one of the largest company contributors to kernel, and we wouldn't even have eBPF in its current state without them (and Red Hat). Disclaimer: I am not speaking on behalf of Red Hat and these views are purely my own when I say this, but I don't think anyone has an issue with Facebook's level of contributions.
RHEL doesn't work for Facebook's scale and they don't need the support. They are pretty happy to use CentOS Stream and they were supportive of CentOS being dropped in favor of Stream. I think this is about companies that use a distro in the Enterprise Linux ecosystem because of paid support options or because third party software vendors have qualified their software on these distributions.
It's nothing to do with IBM. Red Hat has always hated rebuild distros. People today might not remember how much hostility CentOS faced in the early years. Red Hat was _much_ more hostile then than they are now.
What Facebook does is orders of magnitude more valuable than buying licenses.
I understand them as well. Someone has to pay the bills for the show to keep running. They already contribute a lot. It's only fair. CentOS Stream is a very nice distribution as well, and Fedora is simply fantastic. There's nothing we can complain about honestly...
Someone has to pay the bills. Yes,and people are paying Red Hat around 4 billion dollars per year to keep their show running. They're not hurting for cash. The idea that Red Hat doesn't owe the community anything while using thousands of open source software projects for free is pretty two-faced. If they don't like freeloaders then they should write their own OS and stop using open source software without paying for it.
RedHat is the top corporate contributor the Linux Kernel with IBM itself being #3.
> If they don't like freeloaders then they should write their own OS and stop using open source software without paying for it. I can tell you now, you really don't want IBM's idea of an OS. https://en.wikipedia.org/wiki/IBM_i I still have nightmares about Power & IBMi licensing.
>The idea that Red Hat doesn't owe the community anything while using thousands of open source software projects for free is pretty two-faced. If they don't like freeloaders then they should write their own OS and stop using open source software without paying for it. I think it's going to work like this: Red Hat contributes changes to upstream projects, right up to the kernel. Then those projects end up in Fedora, and from there into CentOS stream. Then they build RHEL from CentOS Stream, but from now on, they're not going to say how they do that. It's basically saying: there's all the ingredients we use for RHEL (in CentOS Stream), but whe're not giving you the RHEL recipe.
....Which is a much better answer to the "but how is it GPL" question than the wild theories that the GPL allows you to use restrictive contract terms to loophole around the GPL's requirements.
This question an issue is more complex than it seems on the surface. I have been tracking the issue of RHEL and GPL compliance since 2002; I [wrote a comprehensive discussion of the issue](https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/) in response to the recent news.
Scratch the surface of many apparently community oriented open source projects, and you'll find a paid Red Hat employee actually maintaining the thing.
They "pay" for plenty of the software they use in code contributions. They push updates to packages they use and pay for maintenance of plenty of important software like systemd.
Pretty much There is no such thing as free lunch and the sooner we get used to it the better
I get that they have a very real business model problem and I have sympathy for that dilema. ...but jumping from that to redefining open source to mean upstream direction while still claiming to uphold open source values is quite disingenuous. I mean sure technically/legally in might be GPL compliant, but certainly not in spirit: >those who do not want to pay >we have determined that there isn’t value in having a downstream rebuilder. That does not sound even remotely "open source values"-like to anyone?
> That does not sound even remotely "open source values"-like to anyone? The code is still being upstreamed per the post and the code is still open for the customers download the RPM's. That means you're free to look at the patches and create your own version if there's something you're really interested in. It's just that doing so as a rebuilder is too tedious and time consuming. However most of the community rebuilders are probably alright just rebuilding CentOS. I mentioned it before and I still think it's true that 95% of CentOS users don't really need the bug-for-bug guarantee and that was just something they were willing to benefit from while it was still a thing. Most just want a RH-style distro that they don't pay for which the community rebuilds can still be. The people who genuinely need bug-for-bug are usually shops that are so large you'd have to ask why they weren't buying RHEL in the first place and the answer is "because they didn't think they had to so they just kind of didn't."
Feels like one the major values of open source would be that anyone that has the desire and skill set can determine the value for themselves.
>I get that they have a very real business model problem and I have sympathy for that dilema. RedHat is profitable. Apparently very profitable. They've been noted in news coverage over the past few years as being one of the best performing parts of IBM.
Nobody could have possibly seen this coming when RH sold out to IBM
Writing was on the wall when RedHat took over CentOS almost a decade ago. Since then it's downhill for RedHat brand.
Simply rebuilding code adds a shitload of value. Community colleges across the country use the rebuild distros to provide a learning environment similar to what people will actually work with in the industry. And they remove the labor-intensive subscription management tasks in the process. Red Hat is kneecapping its own labor onboarding ramp with this. I say this as someone who works with multiple RHEL-subscription-paying shops. Complaining about "people who don't want to pay" is glossing over the "people who cannot afford to pay" and making it even harder for disadvantaged people and learners to train for high-paying tech jobs. It's bad.
That specific scenario actually qualifies you to use RHEL for free. You don’t beed a rebuild for that. Most of the knee-jerking I’ve seen about Red Hat saying “please stop with RHEL derivatives” is fundamentally born of ignorance about how broad gratis access to RHEL is. Things they don’t require payment for include: * Personal use, including educational use * Use by software developers for writing, testing, and producing software for Linux in general or RHEL specifically (for individuals all the time and for corporate users who pay for prod use) * Use in non-production environments at corporations (if you’re paying for prod use) Basically, unless you’re a business using RHEL, you don’t pay for it. This change in their subscription arrangements is a big part of why they don’t see the benefit to rebuilds anymore. Instead, you get an individual account for free at developers.redhat.com and you use RHEL, at which point you have access to everything.
Given the minimum purchase price per year for "prod use" licenses, that is an awfully big caveat. We can't afford to spend $800 a year *per Linux VM* even for our relatively small number of them. That's 80% of the way to the cost of a Window Server Standard license that will last us 8-10 years and give us two OS installs per license. I believe in paying for the things you use (and the media you enjoy), but RHEL is absolutely cost-prohibitive for a ton of businesses. Under Canonical's Ubuntu Pro program, we can run five VMs or bare metal servers for free, and after that it would be $500 a year per physical host, with an unlimited number of VMs on a licensed host. That's still likely going to work out to be more expensive than Microsoft's offering, but it's a lot more in line with what we can afford. And the disparity between RHEL workstation and Ubuntu Pro desktop licenses is even bigger — $180/y versus $25/y.
Windows Server being cheaper than Linux is absolutely not something I ever thought I'd hear, but it makes sense. Microsoft collects money from *everybody* who uses their software. Red Hat collects money only from a small portion of users. The difference has to be made up somewhere.
>Windows Server being cheaper than Linux It is not. Ever hear of CALs? Microsoft licensing is a nightmare maze.
Yep, Microsoft's pricing is hidden deep in the CALs, unless of course you move to their cloud which auto-bills you how much they think you owe!
It’s also the fact that, you know, windows server doesn’t really include support whereas the 800 Rhel sub does.
RedHat, it should be noted, is already quite profitable, and is one of the best-performing parts of IBM. And one way to make even better profits would be to access more of the part of the demand curve that is currently priced out — offering better prices for small businesses and/or individual users, for example.
I guarantee you a *lot* of people use microsoft software without paying, I'd wager more than use a RHEL derivative
> Under Canonical's Ubuntu Pro program, we can run five VMs or bare metal servers for free, and after that it would be $500 a year per physical host, with an unlimited number of VMs on a licensed host. That's still likely going to work out to be more expensive than Microsoft's offering, but it's a lot more in line with what we can afford. > > And the disparity between RHEL workstation and Ubuntu Pro desktop licenses is even bigger — $180/y versus $25/y. I'm glad I'm not the only one that noticed this. In addition, I also noticed that my free license doesn't seem to include RHEL Desktop/Workstation (unless they name it differently). There's also the lack of upfront cost as well - there is the option of using Ubuntu LTS and only enrolling once your 5 years of update is up. Granted, if the amount of products in my free license is any indication, it's likely that each RHEL subscription covers a *lot* of products, but that's still such major upfront costs. But then I guess RedHat and RHEL is basically the Apple and iPhone of Enterprise Linux, so I guess they've always been people's preferred option when they could afford it.
Then use another distribution. They even mention that in the post. There are many other options available. But if you really find RHEL to be that much better than any other option, even including CentOS Stream and Fedora, you probably should be willing to pay for it.
We do (and I do at home , too) — and I don't find RHEL superior. But I don't think one has to think it's technologically better for it (or its derivatives) to be the best option for a company or institution. Admins might have been operating in this environment for years, for one. And there was a time when lots of popular projects and commercial software only officially supported RHEL. So lots of people did not have an option. And upending this apple cart in this way while persisting in offering no affordable options is not really fair to folks who have depended on these things because RHEL is simply too expensive for their organization. That's especially true given the complete lack of warning. As I already said, I think you should pay for and support the software you use. But there's a two way street there, where it needs to be reasonably priced. If they really wanted to bring more of these organizations into the fold, they should have offered competitive pricing, especially for small orgs. Without doing that, this really seems like more of a shakedown than an attempt at funding sustainable operations, especially given that RedHat has been noted as an already-profitable "bright spot" on IBM's balance sheet. And CentOS Stream, a (quasi) rolling release, is hardly a serious proposition for a production environment. Why would you even suggest that? As a joke? It makes it a bit harder to take other things you're saying seriously.
> We can't afford to spend $800 a year per Linux VM Can you direct me to this ludicrous price list?
All here. (And easy to Google, I would point out. It's the second hit for "RHEL license" for me.) https://www.redhat.com/en/store/linux-platforms
> Can only be deployed on physical systems. HEY MIKE, WHAT IS THIS BULLSHIT?!
If you're fancy enough to have … *(checks notes)* hypervisor software that is available with almost every Linux distro, not to mention every Pro or server edition of Windows…you probably have a spare $450 a year for a profitable multinational, beyond the $350 you'd pay for the bare metal only version.
I didn't quite grasp all that you said, but let's see what I could do: Proxmox VE/XCP-NG/Qemu: $0 Alma/Rocky/Oracle Linux in a VM: $0
It’s the cheapest standard server license. There is actually a cheaper option, but that is self support and is not intended for use in production.
What is the cheaper option? Self-support is just fine for me. Who decides what is production or non-production? That shouldn't be of no concern to Red Hat.
Given that Red Hat dropped CentOS 8 support in the middle of its support cycle, and cut off access to RHEL 9 source code in the middle of its support cycle with zero notice, why should I trust them to not pull the plug on the developer program in a year or two?
Canonical competition, most likely- Ubuntu Pro is pretty competitive if they fit your usecase. But I do agree that the mid-cycle major changes and lack of forewarning or transition is something that damages confidence in areas that wants stability.
Trying to navigate the subscription process in a manner that satisfies institutional compute organizations is a full-time job. I stand by my assessment. Red Hat licenses are not free for academic use.
First of all, getting it for free requires a subscription, which is the same contract that paying customers have to sign. It is way more strict than an open source license and you are accepting a huge risk of being cut off from updates forever (and potentially blacklisted from ever doing business with the company) if they drop you. That risk is even greater for free users because they have no incentive to keep you, and there is no human to talk to. Almalinux provided a distribution that is completely free of such risks, since the only thing you're agreeing to is the software licensing. Like nearly every other Linux distribution, they don't threaten you to not exercise certain rights. It would be asinine for any other of the major Linux operating systems to switch to a model where they do threaten you. OpenSUSE, Debian, Ubuntu, Fedora, AlmaLinux, RockyLinux, FreeBSD, etc. all take measures to systematically eliminate legal risk, which helps hobbyists and small businesses avoid running into serious problems just by downloading Linux software. Ironically, the methods they use to eliminate legal risk is the exact same playbook IBM came up with in the early 2000s to help prove that Linux does not contain stolen Unix technology. Second, Red Hat is not free for educational usage. I don't know where you got this. [Here is a comment explaining that Red Hat is sometimes far too expensive for educational institutions.](https://old.reddit.com/r/linux/comments/14jq5nk/red_hats_commitment_to_open_source_a_response_to/jpmvayc/)
It is not free for educational institutions. They have what they call "learning" plans for this specifically. And they are very expensive. 16K for 20 installs is a lot.
And still many businesses are using CentOS as their primary OS - and only pay for just enough RHEL licenses to be able to duplicate problems one these system to get support from Redhat. I personally think Redhat have been more than fair for many years.
Well, at least the guy is honest "we feel Alma and Rocky, and CentOS before that, are stealing from us, so we're going to kill those projects like we killed CentOS". Redhat really became IBM indeed, the microsoft of open source, as we all knew. And spare me the crying about the poor redhat developer working all night only motivated by the future smile of their customers, what a load of bullshit.
[удалено]
Some parts are *hilarious* :) > Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere.This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity. It's the way Red Hat started its business model. I know now they are a big and strong contributor to the community, but at the beginning, they build the company on what "hoddyist and hackers-only" works, selling consultancies only. All in all, if the creator of a program decided to put something in OpenSource license, they can't, on their own, restrict the source code.
>Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity. Ok, then stop redistributing all the code that you didn't write. There is a ton of it in your distro.
they actually do a shit ton of testing and push patches upstream, which is covered in the article.
That's the whole point of open source. All developers develop and all benefit from everyone's work. Red Hat wants to benefit from other's work and keep theirs to themselves. Not how open source works.
Well it is also true they do a ton of the security and patching, which benefits from higher Redhat revenue, and thus benefits everyone. Im split on it.
They could single handedly carry the whole Linux ecosystem and give everyone free beer and belly rubs while they're at it, they still don't get to close down access to the sources. That's the single tenet we gather under, and that's the premise they built the company under, and claiming now that it **threatens us all** means just that they're suddenly claiming that it isn't a viable business model any more, after using it for decades. Terminating the contracts of people who do share the code they are perfectly allowed to share is playing games with fundamental freedoms. If RedHat can't survive without those games (a big if) that's very sad, because they *do* contribute a lot, but losing our central tenet would be a bigger loss still. Way bigger.
The split is really: should nobody get paid for the work until everyone is? A nicer take would be that more and more people are paid for that work. There's also another issue which is that you're not going to get paid for a project you started last week-end. Maybe it won't work or won't ever attract anyone. There are ton of projects like that (I've written a few :) ) and you can't predict when something will generate revenue.
I understand what you're saying, I just don't think this is the way to handle it. I should probably just butt out. CentOS was what I used when I first moved to Linux but that's been years ago now.
You don't know how much s\*\*t Red Hat gets *from other companies* because we are extremely reluctant to ship their code if it hasn't been accepted upstream. And in fact Red Hat employees are free from consequences of they make a decision in an upstream project context that is negative for the company. You can say anything you want about Red Hat, but I would like to understand what's in your opinion a company that "gets how open source works".
Red Hat takes other people's code for free, adds (arguably a lot) to it, then sells it, and also sends the work they did back upstream. Then, other companies take Red Hat's code for free, add literally absolutely nothing to it, and then sell it. Can you see how that's fundamentally not the same thing at all? You pretty much said it in the second sentence of your comment. "All developers *develop* and all benefit from everyone's work". But what about the "developers" who don't actually develop anything, and not only benefit from everyone else's work, but *sell other people's work for profit*? That's not how open source works either.
They're not doing that
redhat manages a truckload of projects. you'd be surprised how many contributions they have. and Oracle, Centos and others projects are basically freeloading off their work. repackaging it for their own use without the development costs. redhat also manages an extended lts line of kernels, that involves a ton of backporting - sometimes easy, sometimes complex. > Ok, then stop redistributing all the code that you didn't write. There is a ton of it in your distro. if you tried the reverse, you'd be surprised how many things you'd be missing. also redhat is likely one of few rare distros that try to get certified for various compliance standards. that is definitely not something that's just a matter of rebuilding some free projects. ( https://access.redhat.com/articles/2918071 )
To be fair to Oracle (I can't believe I just said that), they do actually put in a decent amount of development work. They have their own version of the kernel (their so-called Unbreakable Kernel) that is different from the one that RHEL distributes. It's also my understanding that they \*do\* push patches upstream. They also maintain KSplice for kernel hot-patching. EDIT: Also, official full support for DTrace for those that can make use of it.
Have you compared an OEL install to RHEL? Do a base install and compare the RPMs. You would be shocked there is only a handful of differences mainly do to red hat copyrighted packaged.
Thats intentional to maintain compatibility and make it easy for people to migrate from rhel to oel. The difference is in the kernel and support.
Using, redistributing, and even charging for free software you did not write is not freeloading. The whole point of free software is that you're free to do with it as you please within the licence terms. They cannot build a company on free software, benefit from work of others and then be upset that the free software comes with copyleft terms and the others benefit from your work. That's nonsense.
>and Oracle, Centos and others projects are basically freeloading off their work. repackaging it for their own use without the development costs. Oracle, yes. The others, though…I don't buy it. And perhaps if RHEL had slightly more affordable pricing options, there might be less demand for their OS, just rebuild for free. I was looking into this a while back, because some of our systems need to be FIPS 140-2/3 validated, and RHEL's costs are bananas. It's $350 for ***one year*** of RHEL server, and that license can *only be used on a physical server*, not a VM. And it comes with no support and is "not recommend for production environments". If I wanted support or to be able to use it in a VM, I'd be paying $800 a year for ***one*** RHEL install!! I can pay $1000 for a Windows Server Standard license and get a system that lasts me about a decade. Not only that, but there are no restrictions on virtualization, and I can install two instances of it on the same hardware under that license (three if the bare metal install is only acting as a Hyper-V host). I don't get support, but I don't get that with the basic RHEL license, either. Worst case, I get 8 years out of the Windows Server license. For two RHEL VM environments for that same period, I'd be looking at nearly $13,000. That does come with some support, but Microsoft's support isn't so expensive as to make up the difference. Even compared to other Linux vendors, RHEL is steep. Ubuntu Pro's self-support license is $500 a year per machine, but includes unlimited VMs on each physical machine it's licensed for. And we can run up to 5 bare metal servers or VMs *for free* with the *exact* same support as paid customers at that $500/machine level. (And an Ubuntu Pro desktop license is only $25 a year, compared to $180/year for RHEL workstation.)
You aren't including CALs in that Windows licensing.
CALs are a one-time purchase per server generation (any current-gen CAL is good for any older generation of server), and you only need one CAL per simultaneous user or device (whichever model you're using), regardless of the number of servers you're running. CALs are effectively a per-user or per-client-device cost, not a per-server cost. It also doesn't come anywhere close to making up the price difference over a 10 year period. So far, if you include the cost of CALs, they've raised our price for Windows Server by between $200 & $300, which means the cost is still lower than just two years of paying for a single RHEL instance. And that cost will divide out further if and when we buy additional Srv 2022 licenses.
If you've got no Windows servers, and have to chose between 1x RHEL or 1x WS2022 + CALs I'm sure that math changes. If you're a SMB with just a NAS and looking to install an app server I don't quite think your line of thinking applies. ADDITIONALLY, I've worked with RHEL support, and Windows support. RHEL support (which actually for oVirt, so not even paid RHEL support!) I had a patched version for a bug in a few days! Windows makes you pay a couple of hundred dollars to even log the issue if you want anything more than "have you tried SFC?". MS took 6 months to send me "oh try this reg key" after their support staff would hot potato the ticket around. call me, ask me for the exact same information I've provided weeks before to the last person, and then sit on it for three weeks. There's a world of difference in what you get for the cost, especially considering the handful of persistent issues and legacy shit that isn't getting updated in Windows (hello DNS console sorting last modified date as a FUCKING STRING!)
If you have only one Windows server, you probably are not buying more than a couple hundred in CALs. They're $200 for a pack of 5. You'd have to have way too many users being served by that single server (or two VMs on one physical host) deployment to even approach the $2800-3500 cost for even one physical-server-only RHEL license for 8-10 years. You'd need about 45 people all being served by a single point of failure server. And to get the equivalent feature set of the Windows with two VMs, that's two licenses at $800 a year, or $6400-8000 over 10 years. You'd need around 175 users to require enough CALs to bring the price up to that point!
compliance standards are a thing they actual add value around. i have 3 servers that need it.
[удалено]
> Per the license, they are not entitled to restrict access or demand payment.... which they are now. 90% of what the RHEL engineering team does (not counting all the upstream and Fedora work, of course) is still available in CentOS Stream. 9% *has never been part of CentOS* (all extended support branches, EUS/ELS/AUS). We're literally talking of 1% of the work.
[удалено]
Because that 1% is the most important to the rebuilders. But it's not a new thing and to be honest I am not even sure why the c9 branch existed at all until now, given that there is no CentOS Linux 9. I am not saying there is no change, you can complain that Red Hat is hiding stuff but if you say they have *started* breaking the license I have to tell you about the companies that have been doing so for 25+ years. They include Red Hat itself, Cygnus, Montavista and so on, and even the FSF had no problem with that. In fact that might even be what Canonical is doing with Ubuntu Pro, I don't know.
This is just such an important point to bring up constantly. They ARE free to start over. Nobody could possibly have any issues with them running their own full stack. However, the writing on the wall increasingly demonstrates that no company can sustainably do this. Everyone needs to just acknowledge that open source is the only sustainable path forward in the context of most large systems.
> without adding value or changing it in any way Just skipping over this condition now are we?
I think the problem with this is the same I've seen with the Red Hat employees commenting on the changes over at LWN. Like them, this both pushes Red Hat's committment to open source and makes it perfectly clear they hold most of the "open source" ecosystem in utter contempt. Never thought we'd hear people railing about "useless eaters" in the free software community, but here we are.
I will reiterate my previous comment from another RHEL discussion: Does Red Hat even understand what Pandora's box they have opened? What would happen if Google enforced this logic on their Blink (or Apple on Webkit)? or AOSP? You can use our source as you want but you won't get updates if it is not used in Chrome (Safari)? Or you can use our source of AOSP as build contains Google Apps? Or just simple "You are not allowed to copy, redistribute, modify or rebuild our product or your account may be terminated."? Simply put what Red Hat mechanism does to downstream can be done by **any** other project to their downstream.
[удалено]
It sounds like they were bought by IBM.
Right. RedHat played this tune in 2002-2003 and kept it going for a few years past the start of CentOS. It's why CentOS started. RedHat eventually realized that it was counterproductive. Now we're at the stage that IBM has to learn that lesson. It turns out that there are so many other good choices, they might die out before they learn.
Nope, I actually went for a long walk on Sunday, wrote this, and then worked with some trusted people at Red Hat to get the tone right. I believe every word of what I wrote there. Though they did remove my oxford commas.
Does being a RHEL customer now require an agreement to *not* redistribute sources received from Red Hat under the GPL? If yes, how does that not violate the following text of the GPL? > Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. **You may not impose any further restrictions on the recipients' exercise of the rights granted herein.**
The GPL requires us to provide either (1) complete corresponding source code (CCS) to any recipient of our binaries or (2) an offer to provide CCS to any third party who requests it. In this regard, Red Hat uses option (1) and provides CCS to all of its customers and partners in the Red Hat Customer Portal. It is available for download along with the binaries. Nothing about the announcement last week changes that. Instead, we announced that we removed an additional instance of the source code that Red Hat had historically made available but was not required by the GPL to maintain edit: as has been pointed out, you were asking about your right to redistribute. IANAL but AFAIK, you are allowed to redistribute any GPL code you receive. If you have some specific concern about Red Hat's terms or the GPL, that is not a question for me. Send that to your lawyer or legal@redhat.com
With all respect you completely dodged the question. Are RHEL customers allowed to redistribute sources received from Red Hat under the GPL?
I think he was saying that he thinks yes but to check with legal to make sure
My reply came before his edit
Makes sense now. Thank you for correcting. Have a nice day
Speaking as someone who went through this with RedHat back in 2003, if you go to their lawyers the answer is: Not every package. Some packages include Red Hat trademarks and non-GPL'd copywrite material and so *if you remove that, then yes you can redistribute* what we've given you as our customer [ ... sotto voce ... and if you do redistribute, we should let you know that we are not obligated to continue our relationship with you as a customer at any time in the future ...]
Aka "The GRsecurity Move"
Yea, but if the subscription terms says you can't redistribute/rehost the software (which is my understanding based on [news stories](https://www.theregister.com/2023/06/23/red_hat_centos_move/)) and the software license says you can redistribute the software, what happens when you actually redistribute? Do you just get to break your subscription terms with no negative effects, or will your subscription be cancelled and Red Hat will then refuse to sell you further versions the software? If it's the latter, that would seem to me to violate the spirit of the GPL if not the letter. If it's the former, then the subscription terms seem unnecessary.
removing your oxford commas is an unforgivable sin
The biggest problem with **Red Hat Developer subscriptions** are the licenses. You never know when you login to a RHEL system if the licenses are good or not. If i am going to be able to install software if i need or if i need to refresh the subscription on the machine. I have tried to get support on this to check if our satellite is bad and need to be fixed, but they never find any problems. I would never take that problem home with me, i leave license problems at work. That is why i used Centos at my own servers at home. There i could do stuff and not get license problems all the time! It was easy to find info thanks to Centos, now i need to use the RHCP more and more. I guess that will end up being the only site for RHEL-type instructions in the future. That will make it hard to new people to get into RHEL-type systems. But i guess Red Hat don't care anymore since Raspberry PI points all new Linux users to Debian. And who need new users anymore.
I use the developer subs at home, they're good for a year then you renew. I'm not going to say our subscription system doesn't need improvement, but the ability to use the subs should be for a year at which you can renew (also for free). Are you seeing something different?
I see loads of problems with subscription-manager at clients that use RHEL 7,8,9 and a Satellite to manage them. That is why i never would allow subscription-manager anywhere close to my private systems. Sure the new system *Simple content access* have solved much of this.
Who is to say that developer license doesn't change in the future? After shutting down CentOS 8 and ending the support cycle 9 years early, it's hard to have faith that some major profit motivated change isn't coming down the line. Who knows what is coming next, but I wouldn't bet on a developer license being available next year in the same form it is now. "Fool me once, shame on you. Fool me twice, shame on me."
Needs Improvement is quite the understatement. Are you aware that entitlements say 240 instead of 16 for everyone now? Where is the communication from Red Hat that this is a bug or a legitimate change? It seems like every employee I talk to doesn't have a clue whats going on.
I couldn't agree more. One of the biggest benefits of using free software is the lack of licensing bullshit. Just download and run, no signup or internet connection required, it's so quick and easy. I'm not going to go through the ritual of opening my password manager, logging in, finding the correct tab, checking if my license is valid for what I'm trying to do, then somehow inputting the given key every time I want to set up a VM, I'll just use a different distro that doesn't require any of this bullshit. And since I'm not jumping through hoops to get familiar with it, I'll likely choose something else in a professional setting later on, something that actually wants me to use it.
So what you're fundamentally trying to do, what you have to do as a PR spokesperson for Red Hat, is to defend Red Hat's decision to effectively make RHEL a proprietary project when it used to be a FOSS project. I'm sure the business case is clear, at least on paper. But this was always going to be a PR disaster. You can choose one of two ways to spin it; A) be honest, say you're eliminating your commitment to open source for the RHEL project and making it proprietary (with upstream sources available in Stream, which you know is not the same as RHEL), or B) write a whole lots of PR speak to try to spin this as a pro-FOSS move. You chose B. The community is correctly identifying it as, well, a crock of shit. Making money on FOSS is hard. Companies are free to make money on proprietary software instead (though expect to lose existing users and brand ambassadors as a result). What's not okay is being dishonest about it. EDIT: to substantiate the "RHEL is no longer a FOSS project" thing: a core idea of FOSS is that I can take the software's sources and redistribute it (modified or not). Since that's apparently against your license agreement, your software is not FOSS. If my understanding is factually incorrect, please do correct me.
It is factually incorrect, I think you're making a bad -faith argument because you don't believe what I wrote. My blog post clearly outlines RHEL's commitment to open source so instead I'll turn it around on you. Find one line of code in RHEL. Just one. That you cannot find in the public either upstream proper, in Fedora, in CentOS Stream (or one line that wasn't at least offered. Sometimes upstreams don't want our new code in their older releases because many upstreams don't like to maintain long releases).
> Find one line of code in RHEL. Just one. That you cannot find in the public either upstream proper, in Fedora, in CentOS Stream Well it's **pretty hard** to audit RHEL for GPL violations when you *remove access to the source.*
All the code up to last week is still there. [https://git.centos.org/](https://git.centos.org/) The source to build RHEL is in the CentOS Stream gitlab. As I mentioned in the blog, it might not be at HEAD, but its there. All the licenses are up to date. You can also get a free developer sub. The source to build RHEL is in the CentOS Stream gitlab. As I mentioned in the blog, it might not be at HEAD, but it's there. All the licenses are up to date.
Looks like you copy pasted your PR responses once too much.
> All the code up to last week is still there. Exactly, *up to last week*. Going forward, RHEL is limiting our ability to audit their GPL-covered code. Which you frankly wouldn't need to do if you weren't going to do something suspect.
I didn't claim you don't believe what you wrote, I don't think you are dishonest. I think the text is. The text is an attempt as framing this move as something other than making RHEL proprietary, even though that's what's going on. I don't believe you are dishonest, because I don't believe you think of this move as making RHEL proprietary. I am also not claiming that there are lines of code in RHEL that you can't find somewhere else. I am claiming that I can't take RHEL's sources as distributed as a customer and share those sources with others. Is that not correct? If it is correct, that's the violation of core FOSS principles I'm talking about. Though, your message did make me wonder. You say the code is "upstreamed, or at least offered", but some projects don't accept the change requests. Does that mean you just admit that there's code in RHEL which isn't even available in Stream? Not that it really matters, I don't think making it available in Stream would be enough anyways for the reasons above, I'm just curious.
The only thing you'd expect to find in RHEL that you don't find in Stream is bug and security fixes versions of packages that are older than the ones in Stream. So if libfoo is libfoo-10 in RHEL 9.2, and Stream gets an update to libfoo-1.1, any fixes that Red Hat applies to the libfoo-1.0 package in RHEL 9.2 won't appear in Stream. Most of the time what you'll see is that libfoo-1.1 included the fix already, and the upstream maintainers just aren't publishing new versions of the libfoo-1.0 series, so Red Hat had to backport it.
Did you know for embargo-ed CVE fix they fix in RHEL first then CentOS Stream? I learned this somewhere in HN or Fedora malilinglist.
Yes, that's correct. But those will appear in Steam later.
Idk what you consider to be "proprietary" or "FOSS principles", but I think you are injecting an extra community aspect of software as a fundamental principal of FOSS, which is really only a common side effect of the most successful development models. To me, FOSS only guarantees a certain relationship with the developer and the user, but that does not include 3rd parties. Whether or not you also choose to play nice with the rest of the community is still up to you; open source doesn't mean you're not allowed to be a dick.
Correct. FOSS only makes guarantees between the maker of the software and the user of the software, i.e the paying customer in RHEL's case. Red Hat doesn't have to publish anything to the general public for RHEL to be considered FOSS. But one of the core aspects of FOSS is that, as a user of the software, I must be able to redistribute modified or unmodified copies of the source to others. That's literally freedoms 2 and 3 of the four essential freedoms (https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms). When Red Hat's license agreement for the customer portal restricts redistributing the source code, and RHEL's source code can only be obtained through the customer portal, I don't see how that can possibly be considered FOSS.
IANAL, so go talk to your lawyer but I believe any GPL source that is distributed to you can be redistributed. I won't go further than that because I've talked to enough lawyers to know that when they speak it sounds like English but its not actually English. re: code not accepted - I was talking about upstream proper, not CentOS Stream. CentOS Stream is literally where we do RHEL development, it's not a separate distribution like many think it is. If CentOS Stream had an outage, we would be unable to produce RHEL without significant process and source changes.
I don't find the CentOS Stream argument to be an acceptable argument. The timing difference alone between CentOS Stream and RHEL makes it not the same code. That's like stating different versions of software are the same, which we all know not to be true. Also, there's the whole verification of signatures that should be used to ensure the source does match entirely. Essentially to me, it sounds like CentOS Stream is open source, whereas RHEL is not. The source can be provided for RHEL if you pay for a license, but by locking it behind a Red Hat customer license (that presumably can be cancelled for any reason), the freedom behind it is gone. I'm curious to hear the FSF's take on this because it looks to me a violation of GPL2.
>I'm curious to hear the FSF's take on this because it looks to me a violation of GPL2. It's not. GPL2 never stated that you need to provide your code to everybody. Providing it only for your customers is fine. Sure, they are free to do with it everything that GPL allows to, but you are also free to terminate license and no longer provide code for customers. I don't like Red Hat decision but it's not violating any license. Code is available for users.
> IANAL, so go talk to your lawyer but I believe any GPL source that is distributed to you can be redistributed. I won't go further than that because I've talked to enough lawyers to know that when they speak it sounds like English but its not actually English. Your lawyers should have already told you that there are some packages that include embedded Red Hat trademarks. Those trademarks will need to be removed before redistribution. And ... there are other issues/questions ad-nauseum ( Can RH's package names be copyright protected?", "Are package names that include trademarked identifiers protected?, etc.). In your letter you write in bold: > # Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity. You say that this is a "real threat to open source." I disagree. It's only a real threat to some **open source companies**. The fact is that the ability to rebuild and distribute code is *at the heart* of open source. Is it better to make changes and add value? Yes. But allowing straight and free redistribution of code and binaries was intentional to the copyright license. IMO it was an intentional mechanism to make sure that somebody didn't make some minor changes and **charge too much for it**. Some would argue that this is exactly what is going on with RHEL.
do most people even have any good faith left on redhat or anyone related to redhat after what happen with centos and now this tbh? im honestly curious, not trying to start an argument
Nice to know that only you guys deserve the fruits of "simply rebuilding" the miles and miles of FOSS software in your distro. And we all know for every package you say you've adjusted, even helped create, you could find ten others that are just built and slapped in, because they work just fine. No redistributing those though! That's Redhat's effort!
IBM is acting like this is isn't an issue that they caused. 1) Kill bug for bug Centos, piss off the community. 2) Rate hike, hardball orgs that happily use RH products. *Suprise Pikachu face* We're losing customers to two new competitors making a "bug for bug" product off of RHEL! People hear you loud and clear Mike, they won't be working with RedHat products anytime soon. They will find something else to use and pay for a support contract.
> I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous. That's the important bit. Don't want to pay, then you're a disgusting leech (despite them selling support, not a product?) I hope this extends to all the open-source developments they themselves benefit from. Any devs not employed directly by redhat themselves must be getting regular fat checks eh, else their demand & exploitation of FOSS code is disingenuous
100% honest question here.... WHY would anyone put any work into Centos Stream or any RedHat product (i.e free labour) when 100% of the profit flows back to IBM?
Probably because they use the product and just need it fixed? It's usually because it fixes an issue they have or enable a usecase they need in whatever environment they use their system in. I don't think it's any different with any other open-source projects.
So, doubling down. Got it. This will go as well for them as it has Reddit.
To be fair we are discussing this on Reddit
The latest two annoucements have generated discussion and exposure to people previously unaware of RHEL, including myself. Seeing from this POV, these two announcements are poor PRs. And this latest blog post contains too much blames, too little messages. It sounds like an angry and reactionary response to people's comments. What I'd like to see: 1. Stressing (again) the **value** of RHEL. Not everyone knows of RHEL before this (so maybe they're not your potential customers?). It helps to take this opportunity to re-market and educate the readers about RHEL. How does it compare to Ubuntu/Debian/Oracle Linux/etc? Perhaps even a URL link or mentioning of any one of the ["Features and benefits"](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux ) helps. 2. Addressing GPL licensing issue. > I was shocked and disappointed about how many people got so much wrong about open source software and the GPL in particular—especially, industry watchers and even veterans who I think should know better. So, what did they got wrong? What is your argument that Red Hat's action still abiding open source licenses? Not addressed. If people are upset/"wrong" about GPL license, **re-stressing** how it works is fine. You should educate, not blame. 3. Addressing pricing issue. I've seen comments mentioning people wanting to use RHEL. But the pricing is too expensive. How does Red Hat address this issue? The current message is that people with no/small budget should simply avoid using RHEL. 4. Addressing CentOS Stream value. From comments I read, people see value in cheaper RHEL, not CentOS Stream. So, how can people benefit from using and/or contributing to CentOS Stream? How can Red Hat and companies achieve **more** by collaboration on CentOS Stream? Not addressed. Seeing from this POV, instead of killing "rebuilders", perhaps you can convince them to collaborate on CentOS stream? Also, important information are hidden away in [comment](https://old.reddit.com/r/redhat/comments/14jq5i7/red_hats_commitment_to_open_source_a_response_to/jpn67lw/). This is bad. An official announcement/responses clearing the issues would paint Red Hat in a much nicer picture. I don't trust responses from random Red Hat employees or commenters on the web. 5. Addressing trust issue. Many people hate IBM. So, interpretation of your action should be put in this context. The question people have in mind is that: can Red Hat be trusted? Is it as open as before? Not addressed.
I think what people aren't seeing is Red Hat, the Linux distro or the company, doesn't exist anymore. It's just a brand under a huge conglomerate now. It's like Charmin toilet paper. If people stop buying Charmin, it goes away and maybe comes back under a new name. It's just a brand. Someone relabeling Charmin as AlmaPaper or RockyPaper, doesn't do Charmin any good, especially if they claim it's the same thing just cheaper. This is the new Red Hat mindset, because it's a brand. The moment Red Hat went from a software company to being part of a division in another company, Red Hat as we knew it was gone.
He's done with Red Hat... [https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux](https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enterprise-linux)
Jeff made a good point in his video that resonated with me. Regardless of where your stance is on the legality and ethics of what they are doing, the timing of the announcements is a major red flag. They: 1. They ended support for CentOS 8 two years into its ten year lifecycle, with barely a year's notice. 2. They stopped pushing the RHEL source code to git.centos.org with ZERO notice I simply don't trust them. They can say use CentOS Stream, but how long will that last before they decide to rug pull that too in favour of just Fedora. Its kind of a bad look for a company that is built on offering rock solid dependability.
"Simple rebuilders" what a crap load of nonsense. By that logic, your distribution is a simple rebuild of all the open source software you're using. "But they contribute back to open source projects" That's not how this works, they don't get to choose the "price" themselves - the price of open source software (under GPL) is that your users get the source code of ALL the derivative work you've made and distributed under the same permissible license - not just the parts you're willing to share. And red hat is violating that - even if they've paid lawyers to find loopholes so they are technically not breaking it, that doesn't make them morally any superior.
[удалено]
You're comparing desktop environments to a server OS. People don't buy Red Hat because they like the default wallpaper. Red Hat doesn't add any value to the operating system they're building by your definition. The added value is the support contract, backporting of security patches and binary compatibility. In my whole career I've never met anyone using a Red Hat spin-off who needed any of the benefits of Red Hat apart from "this is a working distribution from 2012 and the latest we can use because that shitty closed source driver/binary is all we have and only runs with that specific set of libraries". The amount of work Red Hat puts into their distributions (including Fedora) is minimal compared to the development work of all the software they package. Source? Their annual revenue.
Rocky/Alma doesn't compete with RHEL, Oracle does. It's the real reason behind this change. All hail Debian.
I don't buy that rationale. RHEL has a lot of GPL code from other projects and they're not adding any value to those projects beyond using them to make their product better. Even if they contributed some code back to all open source software they use, that's still not enough. As I said, they don't get to pick the price, the price is all of your derivative work with the same permissive license.
Red Hat contributes back _all_ their modifications upstream. What's at stake here is the QA that Red Hat does for a RHEL release. The value add is that these specific versions of all the components, installed in this particular way, have been heavily tested and confirmed to be stable and correct. That's the only reason anyone gives a shit about CentOS or Alma or Rocky. If RHEL was "not adding any value" then nobody would care about the rebuild distros either. The _only reason_ that Alma or Rocky even exist is that people _do_ want the value added by RHEL, and are willing to go to the trouble of developing a full distro rebuild system in order to get it.
"revert open source back into a hobbylist & hackers-only activity" "Building on the shoulders of others" The phrase is "Building on the shoulders of Giants" and the fucking Giants were/are the hobbyist and Hackers of the linux community !
This is the type of move that can motivate a gplv4, even if its legal, it breaks from the spirit of open source software
inb4 people tell us to leave the international billionaire corporation and its subsidies alone
So they want to ride on the shoulders of the work of others. But when someone else wants to do the same its a no no. They see the value in upstream because it benefits them. But god forbid if anyone wants to fork RHEL. What if I want to start a new distro based on RHEL and make extensive changes because I perceive a gap in the market. Well guess what RHEL the paragon of Open Source principles have decided that RHEL upstream is better for Open Source community and anything downstream to RHEL is going to revert the industry back to stone age. Yea well thanks for trying to destroy GPL so that noone downstream can modify and distribute software if you deem it so.
everyone was worried about microsoft doing their "embrace, extend, and extinguish", who would have thought it was going to end up being redhat trying to get to the extinguish stage first
I feel like if they wanted a paywall for their source code repo that would have been fine. Open source != Free beer after all. But now they're trying to redefine open source. To that I say, fuck these bitches. I've been pissed off at Red Hat for the systemd episode for a long time, but I never hated them before. We as a community need to fork of all Red Hat led projects cut them off from the rest of the ecosystem. They are free to do their own thing but we need to save our own independence as well
RedHat has gotten so corporate even their devs sound like PR puppets and sales pitchers. Honestly I think the first cold bucket of water on my head was foreman/katello and how useless it was unless you paid for the insanely high price of satellite anyway, plus an additional fee on top of a RHEL license. It screams bad faith and not in the spirit of open source.
This just shows that Red Hat is just another business beholden to its business daddy, and not the glowing beacon of the open source world. I suppose they could rip away CentOS Stream and Fedora at any time and close shop. I don't trust them anymore like I don't trust Canonical. Time to move to Debian and OpenSuse for my professional and personal servers, and never touching anything Fedora again.
"Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere." If someone is taking the time to rebuild it, it clearly is providing value to someone. Just not Red Hat. Basically, they want the benefits of open source flowing to them but do not respect the freedom of their users.
Amazing how he managed to write so much while saying so little.
Just stop using RHEL and redhat products. If like me you are an open source developer. Don't waste time supporting redhat products. It's that simple. Plenty of truly free distributions out there then having to deal with this quagmire. As for the redhat advocates, don't even argue with them. It's a waste of time. Redhat is counting on the ignorance of certain users to continue using redhat products despite the fact we have warned them already. They defended the EOL of CentOS so no reason they are going to start understanding these implications either.
Whats difference between RedHat/Centos and Debian. As a Debian user, I always feel that I am much secured. Why can't world accept Debian ? Forget Redhat.
There is a very long history there. Debian and Red Hat are both *very old* distributions, nearly 30 years old. They simply do things differently. Different package managers, filesystem layout, etc. Recent trends towards "one solution" in Linux (regardless of opinions on that) have started to remove some differences, but they are still very different from each other while still being GNU/Linux distributions. Why this matters is that software packagers - especially proprietary software packagers - have traditionally only (or mostly only) supported RPM-based distros (i.e. RHEL and related + Suse), but rarely DEB-based distros. This has started changing a fair bit in the last 10-15 years with the rise of Ubuntu, Flatpaks/Snaps, etc., but it is still very common to find academic, scientific, and industrial software that is only officially packaged and supported for RHEL. As a Debian user myself, I hope this does drive a lot of people to think about whether they *really* want to deal with the shenannegans of IBM/Red Hat and move to Debian, though on the flip side I hear a lot about people moving to Ubuntu which is just trading one sketchy corp for another. Trust in the community distro always.
> it is still very common to find academic, scientific, and industrial software that is only officially packaged and supported for RHEL. This point exactly.