This is United Linux 21 years later. But this time, instead of building a distribution to compete with Red Hat, it's based on Red Hat (in practice, it is Red Hat).
> "No subscriptions. No passwords. No barriers. Freeloaders welcome."
I'm sure they're trying to be cheeky. But it also comes off as confirming Red Hat's position. OpenELA isn't about community, it's about having a base (i.e. bug-for-bug RHEL clone) upon which to sell support contracts.
If you really want to stay in the Red Hat ecosystem, I'd suggest going with AlmaLinux instead. They seem to have a more honest understanding of what "community" means.
Some people are throwing the word "freeloaders" around. It seems clear that "freeloaders" are not people running RHEL clones, but indeed there are some "freeloaders" in the community.
Most of the businesses that want to run Red hat compatible Linux probably don't care about any of that stuff. They just want to run Linux and have it be essentially as difficult to maintain as their landscaping or electricity.
If you're unsure which enterprise linux fork to go with, here is a panel discussion between AlmaLinux, RockyLinux, and Oracle - https://www.youtube.com/watch?v=PFMPjt_RgXA. They all lay out their philosophy and discuss the changes going forward. Unfortunately a SUSE representative couldn't make it, but you can fill in the gaps from their press material.
I tend to respect the AlmaLinux way of doing things, but I respect where the others are coming from.
Part of the justification at the time for getting rid of CentOS proper in favor of CentOS "Stream" was that poor Red Hat was doing all the work and spending all the cash in support of CentOS. Red Hat even went as far to say that the CentOS leadership (board?) was in full support.
Red Hat never allowed CentOS to have any kind of election. It was never a community driven project after Red Hat bought it.
So, very interesting to see these companies banding together to give us back CentOS by another name. It will be interesting to see what Rocky and Alma do.
Bryan Cantrill had an insightful talk "Corporate Open Source Anti-Patterns" surrounding events from 8-12 years ago, and all I'll say is history definitely echoes sometimes: https://m.youtube.com/watch?v=Pm8P4oCIY3g
Not true. Rocky Linux is a Rocky Enterprise Software Foundation project. And on https://www.resf.org, you can see that RESF is backed by lots more folks than just CIQ.
I knew you'd show up and say this. CIQ's CEO claims to have founded Rocky and is the current president of RESF, is Rocky's most prominent sponsor, and Rocky's recent moves have been in the same direction that CIQ requires in order to survive. Regardless of direct control or not, Rocky's financial incentives align with CIQ's.
As you so point out your bias, it would be really nice if you didn't speak on behalf of your employer and let others make their own conclusions without hearing from those biased.
It'd also be nice if employees of Red Hat wouldn't make personal attacks on folks affiliated with Rocky Linux (and to a greater extent CIQ), justified or not, but I can understand nhanlon's defensiveness, just as I understand the defensiveness from many on Red Hat's payroll surrounding everything the past month+.
I'd like to point out that SUSE has never made their source code as available as Red Hat, even after the changes that caused all the drama. The only way to get SLES source code is to sign up for a 90-day evaluation or request it by mail, whereas signing up for a free Red Hat account gives you full access indefinitely. Yet they accuse Red Hat of hurting the open source community by...operating the same way they've always done?
It's frankly embarrassing how easy the tech communities been misled with these marketing campaigns. If IBM wasn't such an easy target, people might see this for what it is- a bad faith attempt to clone an open source project and siphon the sponsors customers with their own support contracts.
Interesting, it looks like based on internet archives that was quietly published shortly after the Centos announcements in 2021. Considering this was a reactionary step it doesn’t give me much faith that they’d react any differently from Red Hat if they were losing SLES customers to another corporations fork.
Well it was SCO back in the United Linux days--albeit it wasn't the evil SCO yet at that time. (Though as others have remarked, there's a different objective at play here.)
"United Linux was an attempt by a consortium of Linux distributors to create a common base distribution for enterprise use, so as to minimize duplication of engineering effort and form an effective competitor to Red Hat. The founding members of United Linux were SUSE, Turbolinux, Conectiva (now merged with MandrakeSoft to form Mandriva) and Caldera International (later renamed to The SCO Group). The consortium was announced on May 30, 2002. The end of the project was announced on January 22, 2004."
It never really worked from a business perspective but Caldera becoming faux-SCO was pretty much the final straw.
to be actually honest and without any speck of trolling, I am at the opposite. I am actually planning to build a workstation and get a redhat enterprise workstation license. the only problem, though, they only have annual subscription. what I want is: one off license (just like windows desktop) and supporting a business entity's ongoing effort to curate and improve Linux ecosystem.
why not donating a certain amount of money to some distros instead? there's an expected level of entitlement when it money's involved.
I can tell you that even inside the company, everyone I knew who had the beginning of a clue ran Fedora. Only those with zero tech knowledge and who didn't want to learn ran RHEL... and they get it for free, obvs.
Probably some RH folk will now pop up to tell me I am totally wrong and it's all changed. That is 100% normal. You can ignore them. I do. ;-)
Many in very important subsystems. The XFS maintainer (who just recently stepped down from this role) and contributor Darrick Wong works for Oracle. Meanwhile, btrfs is the creation of Chris Mason, who worked there until 2012. Modern filesystems on linux owe a decent debt to Oracle. Good luck running an Oracle-free linux.
I often find it interesting when people imply the company is freeloading for having chosen the path of making an RHEL clone. They cloned RHEL because an unhealthy, dependent ecosystem was built around the one, singular linux distribution, not because they are unwilling to fund work.
Giving some serious competition to Red Hat can only be a good thing.
Competition is great. Xeroxing the code and undercutting them isn’t actually competing.
Oracle went after Red Hat when Red Hat bought JBoss. Larry said as much. They didn’t like Red Hat actually competing with them, so Oracle sought to undermine RHEL & have a full stack so they didn’t have to share customer spends.
> They cloned RHEL because an unhealthy, dependent ecosystem was built around the one, singular linux distribution, not because they are unwilling to fund work.
They cloned RHEL to spite Red Hat for the JBoss acquisition in the mid-2000s.
Your timeline is wrong. JBoss was acquired by Red Hat in 2006, then Oracle Linux was announced a few months later also in 2006, then Oracle bought BEA Systems in 2007.
Oracle and Red Hat both entered the bidding for JBoss and Red Hat ended up winning. Larry Ellison took this very poorly.
Oracle Linux, surprisingly, is no strings attached. The licensing is straightforward GPL, the download pages are freely accessible.
In this case, it might be Oracle's lawyers preventing them from being aggressive, because they wouldn't fare well trying to challenge Red Hat. If they screw up their treading-lightly strategy, or if they get into legal trouble, there could no longer be a suitable operating system to run Oracle Database on.
It's because they are the underdog, in no position to impose anything. They do the work because they need it for strategic reasons, so they might as well give it away for goodwill.
My guess is that Oracle Linux will use OpenELA source code repositories to create a distribution that has the usual Oracle-specific quirks, whereas RockyLinux and SUSE will use these repositories to create a distribution that has Red Hat-specific quirks. Sounds like members will have the freedom to do whatever they want with their distribution, they probably won't let any one member exclude specific packaging repositories that are desired by other members.
Based on https://openela.org/about/ this appears to be a source-only distribution. They do not speak of binary builds (just “buildable”), that's apparently up to the downstream participants.
Right now I'm thinking about it in the way that I think about Let's Encrypt.
Let's Encrypt has their own infrastructure, governance, etc., but I don't use Let's Encrypt products to interact with Let's Encrypt. Instead, I interact with Let's Encrypt via products like Certbot from the EFF.
If OpenELA's going to provide source, and I access that source through builds provided by CIQ or SUSE or someone else, then I'll be thinking of it in the same way as I think about Let's Encrypt.
Why would anyone use a server OS that's a fork of another server OS, provided by a group of 3rd-parties with their own competing enterprise distros?
I'm sure there's a reason for it with all the discussions, but if I want to use CentOS, why wouldn't I just use CentOS Stream that RH is providing? If I want RHEL, I'll go get RHEL that afaik is also free. If I want to see the future of RHEL, there's Fedora Server. And if I believed RH was being intentionally hostile, why would I support them at all and not go with a completely unrelated distro like SUSE?
Because soon that will be the fork everybody will target,and the de facto standard.
RHEL could have survived for a while in hostile mode if everybody was complacent (maybe making the entire thing profitable). But this is exactly people not being complacent.
Anyway, you can bet there will be infighting once this is established. But well, the power that free software grants for people to misbehave is very limited.
Who is everyone? I imagine any serious business is paying for RHEL instead of an unheard of fork, and in my use if I wanted to change from Fedora Server I'd go to CentOS Stream, followed by RH with a free dev license.
I'm getting the vive that some people just want free RHEL, feel entitled to have it, and don't realize that actual RHEL is free within reason (apparently up to 16 simultaneous machines). Nobody remotely concerned about security is running a non-mainstream distro and public-facing services in an age of randomware and crypto.
As I understand, the only costs with RHEL include using it across a large number of machines in enterprise, and customer support. Someone using it on a few machines in a home lab should be fine I imagine?
Now I'm even more confused as to why RHEL's changes are this controversial :p
16 machines is more devices than I have in my house, and enterprise seems like they can just pay for RHEL. I'm also betting there's not some thorough verification process that would prevent you from running RHEL free on more than 16 machines (seems almost too easy, but just make multiple free accounts per-16 machines? RH I'm sure would be happier to have people running RHEL at all than intentionally seeking out free license violators)
To be honest, if you need 20 licenses because of a home lab, I'm sure if you wrote to Red Hat, they'd probably provide some extra free (or nearly-free, like 50$ a year or something) licenses since your use case is home-related, not business-related.
That said, I can understand how one wouldn't want to do that. For a home lab, I'd say any distro is totally fine.
For personal use I use Debian almost exclusively. Laptops, desktops, servers, VMs, Raspberry Pis, all of it.
Pre-Stream CentOS was never my preference, but I did spend some time running it to learn the RHEL way. The free licenses would fill that gap.
At work we run RHEL where we needed support and Alma where we don't. It was chosen for me. I'm watching to see how this plays out, but not incredibly concerned.
"The Red Hat Developer Subscription for Individuals is a single subscription, which allows the user to install Red Hat Enterprise Linux on a maximum of 16 systems, physical or virtual, regardless of system facts and size."
This falls under the heading of "technically correct" - in the sense that the limit is high enough for people to make the argument you are, and yet too low for most enterprise use-cases. Worse, the offer could be withdrawn at any time.
If you're enterprise with more than 16 machines, you can and should probably be paying for RHEL.
What I'm not understanding is why people need to use RHEL and would resort to free random forks of it, instead of just using CentOS Stream or Fedora that are basically the same thing, actually from RH, and 100% free. RHEL is not that special.
I'm on the fence about that. I wish people were more willing to financially support open-source development, but I've worked with dozens of customers using RHEL over the last 10 years and never seen a single one of them open a support request - on that basis I can see why people feel that the price is too high. When the options are "get gouged" or "be labelled a freeloader", the outcome is pretty obvious.
> just using CentOS Stream or Fedora
I think the rise of free alternatives (Amazon Linux) and a DevOps-style mindset (no patching, just burn it down and redeploy when updates are needed) are exactly what has motivated this squeeze - RHEL is losing relevance in a lot of places, so RH/IBM are left with fewer potential customers and so just end up squeezing them harder.
You don't pay for the support requests, you pay for the work of letting you update to the next minor release at your own pace, having those updates be rock solid, and having security fixes even on older releases.
In other words you pay for not having to open support requests.
When a free alternative (CentOS, Rocky) exists, you can get those benefits without the cost. The only real differentiator RH has is support.
Being an open source company means that RH has a non-standard business model and should expect non-standard profits. Their business model is inevitably doomed, but rather than innovating they are going with the "lock-in and gouge" model, exactly like Oracle.
No, CentOS/Alma/Rocky only supports one minor release at a time (that's up to four major releases for a 10 year lifetime). You can stick to a major release but you have to update every 6 months or you'll skip the security updates too.
Red Hat supports 15-ish release streams at this time between RHEL7, RHEL8 and RHEL9. A lot of customers need that because validating a base system update takes months and they cannot afford not having security updates in the meanwhile.
The subtlety of different support levels for minor releases is something I hadn't come across before, thanks. I'm surprised RH haven't made more of that recently.
In fact the recent change basically consisted of going from 1 to 0 shipped stable branches (CentOS Stream is the mainline of RHEL). But most of those stable branches have never been public in the first place.
In my opinion 99% of end users would be served well by CentOS Stream, but the strong marketing of bug-for-bug compatible distros on part of Rocky (and to be honest it's a fig leaf to pretend CIQ is not behind that) hampered the adoption of CentOS Stream and the users' perception of its stability.
Those benefits that CentOS, Rocky offer, as you said, are without cost because the cost is shouldered by Red Hat. If you're a 1:1 rebuild, you can't introduce your own fixes, so CentOS, Rocky rely on Red Hat to write and produce a fix that will then be rebuilt "free of charge" as you mention.
I loved SUSE for a long time, but their future plans for Leap had me looking elsewhere. They want to make the next Leap microOS bases, so a transactional immutable base. No thanks I don't need that. Moreover they want to kill yast for some web based stuff with way less feature.
Funny you mention that as Oracle has also "migrated" everything to OpenSearch. They're really big proponents of (other people's) free and open-source software!
Interesting observation. I recently watched a documentary about Compaq, and this saga reminds me of a previous time when IBM tried to put the genie back in the bottle with MicroChannel architecture. Let’s see if they fare any better this time
> It will provide an open process to access source code that organizations can use to build distributions compatible with RHEL
So they're not trying to create something like RHEL but in a way that is committed to being more 'open' somehow. They're still shooting for the bug-for-bug stuff, and still an effort that's parasitic on RHEL in terms of its substantive development.
Seems like an obvious next step is to get enterprise hardware and software vendors to begin certifying on OpenELA in addition to RHEL. OpenELA10 or w/e could stand on its own as a competing enterprise linux standard that everyone is free to build from.
> OpenELA10 or w/e could stand on its own as a competing enterprise linux standard that everyone is free to build from.
Idk. How is that standing on its own? SUSE already has a perfectly good enterprise Linux distro in SLE. If the point is to have an alternative standard that anyone can build from, why not just use that as the base?
Seems to me that all the RHEL derivatives were perfectly content to let RH set the standards for enterprise linux. RH doesn't like that arrangement. SUSE probably wouldn't mind it.
All the derivatives have their EL8 and EL9 based distributions they've committed themselves to support for some time, so I'm sure they'll maintain bug for bug compatibility as best they can given the circumstances. No reason for them to keep following RH after that.
Google Chrome 112.0.5615.165 (Official Build) (64-bit)
Revision c262f36e6b1d711ee42d4fbe1343b49960593f18-refs/branch-heads/5615@{#1297}
OS Linux
JavaScript V8 11.2.214.14
User Agent Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/112.0.0.0 Safari/537.36
Command Line /usr/bin/google-chrome-stable --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=WebGPU
Executable Path /opt/google/chrome/google-chrome
I like this solution way much better. Now the only player that's missing here is Almalinux. Maybe it's not too late to make a U-turn and join this new group so that Redhat alone can be responsible for contributing to RHEL as intended.
It may not be a good thing to anyone looking at this whole mess but it's clearly what Red Hat wants. After all, their VP did lament that they were doing all this work for "free" just so that the other enterprises can rebuild their product.
I remember when Sun Microsystems and AT&T teamed up in the late 1980s and Sun announced the next version of their OS would be based on SysV UNIX instead of BSD UNIX. Since Sun was this massive force in the UNIX market back then, other UNIX vendors formed the Open Software Foundation (OSF) in protest.
In many ways, Red Hat and IBM are the modern Sun Microsystems and AT&T, so it's not surprising that their competitors are essentially doing the same thing.
> their competitors are essentially doing the same thing.
OSF was developing an operating system[1] based on Mach, a file system from IBM, and BSD's IP stack, that intentionally had very little in common with AT&T UNIX.
OpenELA is trying to create a carbon copy of their competitor's product, guided by the slogan "bug-for-bug compatible".
For me: yast (easy to use GUI/TUI for many administration tasks — useful for less experienced admins), snapper (filesystem snapshot management tool which automatically creates them before and after package management operations and allows you to boot into them or roll back if anything goes wrong. Quite similar to FreeBSD boot environments.)
zypper is probably the best 'classic' package manager there is (although dnf is great too; it's more of an argument against Debian and its derivatives).
Then there is https://build.openbuildservice.org which automatically builds packages for all supported distributions and architectures from a single RPM spec file and creates a ready to use repository for you.
OpenSUSE Leap is built from SLES sources and is thus comparable in its stability guarantees to the old CentOS (or any of the current RHEL rebuilds).
I found YaST to get in my way at times; I particularly remember YaST's Network panel hanging because I had StevenBlack's huge HOSTS file. I do like the network panel though for changing static IPs; I had to do some searching to try to figure out how to do that on Fedora, and ended up using Cockpit instead (not sure how to do it cli).
I'm confused on the differences in repo priority between zypper (oS TW) and dnf (Fedora). Apparently dnf also allows setting repo priority, but I've never had to do it, and packages seem to come from expected repos without having to specify (stuff comes from RPM Fusion if I have those repos added). On TW I had to manually specify repo priority to something other than 99 and set a flag to allow vendor changes to have similar behavior; I like that kind of control but I didn't need to do it on Fedora.
OBS is nice in-concept but I don't like the idea of using it outside of openSUSE. I think Launchpad/PPAs for Ubuntu, Copr for Fedora, and AUR for Arch. I think OBS for openSUSE and don't like the idea of using OBS for other distros, even if that's one of the big benefits and point to OBS.
Probably YAST¹ and the Open Build Service². I think the latter is especially great. There's a public instance of it hosted by openSUSE³, and you can use it to build packages for almost any distro and get a feel for it.
You seem keen to promote this, as you posted the same reply twice.
It's not the same thing at all, or even very comparable, AFAICS.
Your site produces a Fedora COPR. One of the people on the COPR team spent 10 min trying to explain to me what COPR meant at a Flock conference a few years ago. The actual answer is:
"It's a PPA but for Fedora instead of Ubuntu."
SUSE OBS does not build repos and it does not build openSUSE packages. I am running native Debian packages on Ubuntu right now built on OBS (Waterfox, notably.)
OSB builds anything for any OS. It's basically a free public CI/CD server, and it's platform-neutral.
I have not checked but I believe it can also build Windows and macOS binaries as well.
> You seem keen to promote this, as you posted the same reply twice.
The same point has been made twice, so the response is identical..?
> "It's a PPA but for Fedora instead of Ubuntu."
So I'm not sure the analogy holds 100%.
I, as a software developer, want to distribute my SW. I use COPR to build RPMs that run on any RPM-based distro, e.g. openSUSE, Fedora, RHEL, CentOS, ...
You, as the consumer, can enable the COPR repository and consume my packages (or you can manually download the RPMs if you prefer).
> OSB builds anything for any OS. It's basically a free public CI/CD server, and it's platform-neutral.
That is indeed different. Thank you, I might take a look at OSB.
I've ran Ubuntu and openSUSE servers and aside from a profile issue with PHP and openSUSE, I don't know if AppArmor is even protecting anything. Everything just works and it makes me think AppArmor is only applied to specific apps/services and not globally.
SELinux (at least on Fedora) is present, everywhere, and will gladly let you know if something is blocked because of it. I prefer this kind of protection even if it's more annoying at times :p Just a few weeks ago I learned about bin_t and that made my SELinux config for that service a lot more simple.
For example, LWN's most-recent report[0] on who contributed Linux kernel patches puts either three or four different companies above Red Hat, depending on if you're looking at changesets or lines changed.
Regardless, if leadership is theirs to lose, then they're doing a good job of it.
Kernel contributions are only one metric / piece of a distro, and these days a lot of the code churn is hardware if I’m not mistaken. It makes sense that Red Hat has slipped because the big changes are in new support for hardware.
Eh, it's good. IBM didn't want to continue supporting community things and so here we are, the RedHat business model was a bit tricky and increasingly so because of cloud computing.
The great value of RedHat was supported software. You could buy one of those $10,000 per seat software packages for some engineering discipline that was guaranteed to work by RedHat and the vendor and if it wasn't they were quite motivated and helpful in fixing your problem quickly.
RedHat also was trusted to monitor and fix security problems quickly, and was in the privileged position of getting notifications about them before they were public so they could be fixed.
The question is how do you get people to fund these two things?
There have been numerous employees, former employees, and even VP level folks who have said this direction comes from Red Hat, and not IBM.
I'm inclined to believe them, with the caveat that this reality may not have come to be had IBM never bought Red Hat. That still doesn't imply IBM forced the change.
I am curious how they feel as well. It seems like it won't impact their support contracts since things built with openela will be rhel compatible. But surely they cut people off for moat reasons.
Why do you think this is a bad change? I was thinking additional players in the space would make for a more robust ecosystem.
Probably a dumb question, as I'm not really on the enterprise side of Linux but: Isn't Canonical in the same business as Red Hat? Why doesn't Canonical seem to care about alleged "freeloaders"?
Come to think of it, why is SUSE considered as a serious replacement for RHEL and not Ubuntu?
Canonical recently introduced a “Pro” subscription - I’m not sure how sources are available from that.
There really aren’t rebuilders for Ubuntu in the same way, and Canonical has a very different place in the industry. I think there was a thing a few years ago about Canonical going after some of the distros based on Ubuntu, but I think that was over pointing directly to Canonical’s repos (rather than hosting their own binaries), which is reasonable.
If Canonical were a public company or owned by one and had a multi-billion dollar business being undermined by clones and freeloaders… I think you’d see similar actions.
I got the impression that sources are not available to the general public.
See for example this security update, the versions back to 20.04 have links to launchpad, the older versions have no link but say "Available with Ubuntu Pro".
> Come to think of it, why is SUSE considered as a serious replacement for RHEL and not Ubuntu?
SLES and RHEL are somewhat similar, in that they both use the RPM package format, and they both have a 10 year support lifecycle. They are not entirely compatible though. They also make management software that is supposed to be as interoperable as possible with competitor distributions.
Anyways, last month SUSE announced they would be making an actual RHEL fork, so that's the real reason they are joining this new partnership -- it's not related to SLES, but a new distro they are making.
As for Ubuntu -- it is often touted as an alternative to RHEL. However, people don't like the weird ways in which Ubuntu diverges from the rest of the Linux community (Snap, LXD, ufw, etc.), so some attention is diverted towards Debian and RHEL, which are more focused on packaging software that is already proven. Red Hat does their innovation in Fedora, waits a few years to see if it catches on, then implements it in RHEL. This tends to have a greater degree of success than pushing it suddenly on users like Ubuntu does.
Um. They get a lot, but packaging is not part of it.
I don't think I know a single package in Ubuntu that is a Debian package. That is what Ubuntu _does_ -- it takes Debian, repackages and tests and integrates it.
Oracle have a sales pitch - I've been on the end of Oracle's - that is "we'll sell it for less, we don't care, name a price we just want to hurt Red Hat."
Ubuntu ships the live patching that was developed by SUSE and Red Hat.
After Oracle acquired the company that developed ksplice and took the technology private, SUSE started to develop kGraft[1] and Red Hat started to develop kpatch[2], and these were eventually merged and upstreamed[3] into Linux.
Just skimming the regulations, I don't believe that it would qualify as a 501(c)3 as they don't receive "broad public support" [1] whereas the criteria for a 501(c)6 match exactly with their goals. Additionally the (c)6 allows for political activity related to the purpose of the organization, which seems like a good ability given the current intersection of politics, regulation, and tech. [2]
I'm not sure what you mean by "incentives". Perhaps you could elaborate.
I started a 501(c)(3) with some friends. It didn't require broad public support, just that we intended to grow to such a point.
(I'm not sure exactly what the current support is like; I left the board over a year ago. I think it's around 10 folks that donate somewhat regularly.)
Certainly the political activity provision of 501(c)(6)s are beneficial for this association, and I guess they'd have more scrutiny as three large companies instead of a few high schoolers.
You will find that many of the open source backing non-profits are trade organizations. Some notable examples:
- The Linux Foundation (which includes the CNCF and OpenJS Foundation)
- Rust Foundation
- Bytecode Alliance
I don't mean to provide an opinion on incentives (and they are different as the parent suggests). I just mean to share that trade organizations are already common.
Disclaimer: I work for SUSE but not on OpenELA. I am also a maintainer of CNCF projects and on the CNCF TOC.
Small nit but technically OpenJS is a separate 501c6 that is currently managed by the LF, they're not "underneath" the LF in the same way that CNCF is. Not sure why that's the case, probably just historical reasons since they were independent for a long time beforehand? Doesn't seem to change much operationally as they have the normal C6 structure with corporate members, etc.
Sure! IANAL, just a dev, but my understanding from seeing this play out over the last 20 years is the following broken down first by public vs. private benefit:
501(c)(3): Organizations under this classification must primarily serve a public interest and not a private interest. Any private benefit must be insubstantial.
501(c)(6): These organizations are designed to serve the private interests of their members, as long as those interests align with the broader industry or line of business.
Everything else follows from this distinction IMHO. You see it play out in the Linux or Rust foundation, in contrast to the Python or Zig software foundation. It's easier to get attention and members with a trade organization, but over time, over the long term, there's a stark difference that I believe is not disputed.
I'm not going to look a gift horse in the mouth. And tbh, these days, with whatever bad medicine google feels like foistering on us this week, Oracle are truly beginning to look more and more like the "good guys".
As much as any large evilcorp can be the good guys anyway.
> And now even Oracle is looking like the reasonable player?
A broken clock and so on. Oracle has absolutely no reason to misbehave here, and everything to gain by being ethical. At this point, they would only do something wrong if the compulsion was too strong.
For personal and small business needs, you can stick to whatever you'd like, even Arch Linux if that's your poison. That's not the aim of the announcement though.
It's my point though: rather than navigate between what RH is doing and what Oracle is doing, I'll just stick with a solid open source distribution. Lindy effect and all...
Except that Ubuntu isn't "solid" any more, not since they moved to those damn snaps. I'm looking at moving to openSUSE Tumbleweed now because I've had it with Ubuntu.
https://en.wikipedia.org/wiki/United_Linux
> "No subscriptions. No passwords. No barriers. Freeloaders welcome."
I'm sure they're trying to be cheeky. But it also comes off as confirming Red Hat's position. OpenELA isn't about community, it's about having a base (i.e. bug-for-bug RHEL clone) upon which to sell support contracts.
If you really want to stay in the Red Hat ecosystem, I'd suggest going with AlmaLinux instead. They seem to have a more honest understanding of what "community" means.
Some people are throwing the word "freeloaders" around. It seems clear that "freeloaders" are not people running RHEL clones, but indeed there are some "freeloaders" in the community.