Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Oracle Red Hat Software SuSE Linux

Oracle, SUSE, and CIQ Go After Red Hat With the Open Enterprise Linux Association (zdnet.com) 70

In a groundbreaking move, CIQ, Oracle, and SUSE have come together to announce the formation of the Open Enterprise Linux Association (OpenELA). From a report: The goal of this new collaborative trade association is to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code."

The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.

Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."

This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.

This discussion has been archived. No new comments can be posted.

Oracle, SUSE, and CIQ Go After Red Hat With the Open Enterprise Linux Association

Comments Filter:
  • by Anonymous Coward

    I wouldn't trust any of these corporations.

    • by jmccue ( 834797 )
      I agree, Debian is good, and I say Thank Goodness for Slackware.
      • I'm noticing a quiet move for Debian as a base OS for appliances. Be it TrueNAS SCALE, or Proxmox. Debian may not have the cool options that Ubuntu does, but it works, and has been around almost as long as Red Hat, so overall going that route isn't a bad choice.

        My only minor feature enhancement for Debian, is that Debian would have the option at install time to support TPM unlocking LUKS, with a second LUKS slot for a recovery key. That way, machines can boot automatically after updates.

        • by jmccue ( 834797 )

          My only minor feature enhancement for Debian, is that Debian would have the option at install time to support TPM unlocking LUKS, with a second LUKS slot for a recovery key. That way, machines can boot automatically after updates.

          Not sure what this means, are you saying you can load the TMP and when you power up or reboot, no need to type in the LUKS Password ? If so that seems to defeat the idea of encryption.

        • by guruevi ( 827432 )

          Debian does have a way of unlocking LUKS with TPM2. Clevis-TPM2 has been in Debian since Buster. Takes a bit of testing and setup, haven’t done it since, well, buster. clevis luks bind -d /dev/vda3 tpm2 '{"pcr_bank":"sha256","pcr_ids":"7"}'

          TPM1 (pre-Intel ~4th gen) doesn’t work well.

          Alternatively systemd-cryptenroll is now in Bookworm, this script https://github.com/wmcelderry/... [github.com] should work on most Debian, I would suggest reading the patches to understand what it does so you understand how TPM

          • I do agree that this works, but it would be nice if it were a default part of the OS install and didn't require a ton of preparation to do this. Ideally have it able to be done from a kickstart script.

            • by guruevi ( 827432 )

              The preparation is minimal, clevis does all the work, on more than a few distros it works right out of the box, just reset your TPM chip in UEFI and enable secure boot, I’ve automated the activation. I think the more supported way is not to use TPM2 auto but TPM2+PIN or use Tang.

    • by nicubunu ( 242346 ) on Friday August 11, 2023 @06:29AM (#63758456) Homepage

      What is your issue with CIQ? Did you even hear about them before?

      Note: CIQ is the company releasing Rocky Linux and is founded by the same person who founded CentOS many years ago.

  • NGMI (Score:5, Insightful)

    by bill_mcgonigle ( 4333 ) * on Thursday August 10, 2023 @06:00PM (#63757500) Homepage Journal

    They're trying to make workarounds for business-as-usual but leave IBM in charge of all the important strategic decisions.

    They don't seem to realize that IBM will be back with more ways to screw them, in all likelihood.

    The baller move would be to announce a cohesive fork of EL at the current public release and dedicate the direction of it to the nonprofit.

    Get Amazon, Oracle, SuSE, the CentOS/Scientific/descendants on board and fold in the HPC group's work.

    Let IBM keep its customers who have no choice. The other groups can afford to set the evolutionary direction going forward without IBM's judgment. Some og hatters will want to be hired by the group continuing what they used to work towards.

    Much of the work can be shared with Debian while maintaining the separate tooling that many people seem to prefer.

    Yeah, it's harder than being an IBM downstream but that business model appears to be Mostly Dead at this point.

    • Re: NGMI (Score:2, Informative)

      How many times do you and the other commenter here need to be told it has nothing to do with IBM?
      • Re: (Score:3, Informative)

        by Anonymous Coward

        I work at Red Hat, but not in the RHEL space. We are fiercely independent from IBM. This is not an IBM play in any way, shape or form.

        From what I can glean (again, I'm not close to the RHEL team), this is an attempt to shift the community upstream of RHEL. Good for the open source community, not so good for businesses that simply re-package and add little value.

        For everyone truly passionate about open source (which we are) this creates a more open community involvement.

        It saddens me that the community is

        • Re: NGMI (Score:5, Interesting)

          by RazorSharp ( 1418697 ) on Thursday August 10, 2023 @08:56PM (#63757852)

          this is an attempt to shift the community upstream of RHEL.

          We can clearly see that is what you're doing. That's exactly what we have a problem with. You want the "community" to function as free beta testers and developers for your product but at the same time lock them out from profiting from this work or their expertise. You want to divide the Linux community in two: 1) Enterprise = RHEL and only RHEL 2) "Community" = euphemism for "amateur" and your source of free labor.

          You see, before you guys decided to be a bunch of dicks, we had a symbiotic relationship. But you failed to appreciate the value of the community, instead labeling anyone else who dared profit off Linux "leaches." Well, if we're leaches then so are you.

        • by Anonymous Coward
          I also work for Red Hat, and while we all like to believe we are independent, its only because that is the lie we are constantly told. To continue to believe it just makes you naïve. All you have to do is look at what is happening in the Sales Org to see the slow IBM takeover. A literal takeover of the top accounts and putting them under IBM Sales with RH Tech folks working with them. How is that for independence?
        • Re: NGMI (Score:5, Insightful)

          by sg_oneill ( 159032 ) on Friday August 11, 2023 @01:12AM (#63758122)

          not so good for businesses that simply re-package and add little value.

          What Hubris!

          Redhats entire model is Open Source, and repackaging other peoples work and selling it.

        • Re: NGMI (Score:4, Insightful)

          by nicubunu ( 242346 ) on Friday August 11, 2023 @06:33AM (#63758460) Homepage

          If you are indeed working at RH and what you say is true about RH being independent in those decisions, the only conclusion is RH was taken over by evil

        • this is an attempt to shift the community upstream of RHEL.

          This is a huge downgrade, since the community already is both Upstream of RHEL and downstream; Cutting off the downstream source access is anti-Open source. RHEL is repackaging other peoples' work, and in the spirit of open source - RHEL's work as well should be available to repackage.

          No it's not good for open source to have a distro hiding its source code.

        • Its not good for "the community". But as a for profit business I understand why Red hat is doing it. It does a great job with RHEL and is kind of sick of the parasitical nature of companies that pay for every other service/ support but not paying for the OS that makes all of it work.

          Free ( as in beer) software is good for the community in the short term, any ways. If it kills the funding for all of the work that makes it good, then it could be really bad in the long term. This is the argument I've heard fro
        • The one thing that people of good will agree with, almost by definition, is that this is NOT a good thing for the community.

          Some believe otherwise, but it is not a good thing for IBM/Red Hat either. You have lost the support of the community whose work you redistribute in violation of its license, and the inevitable result is that some of it will be relicensed in such a way as to clarify that you can't misuse it in this fashion any longer.

          You basically screwed up, and your only play now is to reverse that

      • Re: NGMI (Score:4, Insightful)

        by thecombatwombat ( 571826 ) on Thursday August 10, 2023 @08:49PM (#63757844)

        IBM owns Red Hat. Red Hat is IBM at this point.

        This is just fact. It doesn't need defending, or explaining, but it does have to be accepted. If Red Hat does something, whether it's being led by old Red Hatters or old IBM folks, IBM is doing that thing.

    • Re:NGMI (Score:4, Interesting)

      by RazorSharp ( 1418697 ) on Thursday August 10, 2023 @08:50PM (#63757846)

      I think this is stage 1. Ensure compatibility with RHEL to make it comfortable for those making the transition. The fork you're talking about is stage 2 for once this standard takes off. Maintaining compatibility will allow all those Red Hat customers to easily transition to one of these other companies.

      Amazon, SUSE, and Oracle are going to win a bunch of government contracts over Red Hat when they can go and say, "Hey we're deploying an open standard and when your contract is up with us, we'll have to compete with all these other companies that support this same standard." RHEL, for all intents and purposes, is proprietary.

      This was a huge blunder on Red Hat's part. All the major cloud providers will push this new Enterprise Linux and Red Hat will increasingly only serve IBM customers.

      • For me (well, my clients) this would make the most sense. I recently shifted them to Rocky Linux, and could stick with that for as long as it's okay. If IBM still keep screwing people, then Rocky will suffer, whereas this collaboration might not - and would be in a better position to fork if they felt it necessary.

        In terms of my client, we'll go Rocky 8, 9, and then whatever's after that - by then, all the install and management tooling will have moved over to the new variant, so it'll be minimal hassle. E

  • The hope is then; force IBM thus RedHat deeper in to proprietary space? Or; force IBM thus RedHat to reevaluate its GPL interpretation or even the GPL environment itself thus making the industry see GPLv4 necessary?

  • by oldgraybeard ( 2939809 ) on Thursday August 10, 2023 @06:17PM (#63757544)
    How is the big switch to systemd looking to those that did it and supported it.
  • by Going_Digital ( 1485615 ) on Thursday August 10, 2023 @06:25PM (#63757568)
    Anyone that thinks the recent antics pulled by RedHat are bad, wait until you get caught out by Oracle. Don't go near this folks, go with a true community distribution like Debian.
    • What if you need support and certifications?
    • by RazorSharp ( 1418697 ) on Thursday August 10, 2023 @09:14PM (#63757874)

      Just because Oracle is a terrible company doesn't mean this news is bad. Their interests just so happen to align with the community's. It may be a first, but it's not a bad thing. Having a standard enterprise Linux is a good thing and we were fools for all just putting our faith in Red Hat and allowing them to be a de facto standard. There needs to be an industry standard Enterprise Linux supported by all the big players so that no single player can monopolize it.

      That doesn't mean I would buy ANYTHING from Oracle. Fuck those guys. But I'm not going to turn my back on something good just because Oracle's involved.

      I like that Debian is a true community project, but "Enterprise Debian" = Ubuntu and 1) I dislike Canonical for several reasons, 2) I dislike several of the technological decisions in Ubuntu.

      • by ctilsie242 ( 4841247 ) on Thursday August 10, 2023 @09:25PM (#63757892)

        Oracle could easily get a following if they GPL and mainline ZFS into the Linux kernel. There is a lot of good Oracle can do, and they can step in and get some marketshare, maybe even get a positive rep among F/OSS people.

        However, what companies buy RHEL for, is the ability to run it offline. No snaps, no flatpaks, the ability to maybe have a Satellite server handle repositories, and have the RHEL machines on an air-gapped network. This is what Oracle, SuSE, and other competitors need to understand, and consider having a patch system, as well as maybe rebrand AWX or Ansible Tower for management.

        Don't forget AAA and other things. Rebranding oVirt would give virtualization and companies will pay big money for this, just to get off of VMWare. FreeIPA/ Red Hat IdM could do a lot, especially if it is used as a directory server for IT related stuff, so when AD gets compromised, routers, appliances, consoles, and SAN web UIs are still protected. FreeIPA even allows 2FA auth on its side, so any appliance that supports LDAP is now protected by Google Authenticator style of protection without any changes on the endpoint.

    • Oracle Linux has been around since back when big iron UNIX still ruled. Part of the same initiative as Oracle RAC, to save on big money big U Unix by using cheap Intel clusters with a free "unix" OS. (All so you could spend more with Oracle of course)

      So it wasn't born yesterday, and now it's outlived CentOS. It's still a completely free vessel by which you can consume Oracle software (or not) on cheap PC clusters. With timely security updates. That hasn't changed. Now it also runs their cloud offering.

      I'm n

  • I think that Batman quote about living long enough to become the enemy applies to RedHat nowadays. Back in the 1990s they were perhaps more responsible for the spread of open source and Linux than anyone.

    (No, doesn't apply to Oracle; they were never good)

    • by Anonymous Coward

      I think that Batman quote about living long enough to become the enemy applies to RedHat nowadays. Back in the 1990s they were perhaps more responsible for the spread of open source and Linux than anyone.

      (No, doesn't apply to Oracle; they were never good)

      I would say that it also doesn't apply to IBM, they were never good either.
      So when RedHat was purchased by IBM, this is exactly what was said would happen by everyone with foresight.

    • by kriston ( 7886 )

      Oracle may have a stigma going against it, but they do build their RHEL-compatible products (Oracle database, Java) on Oracle Linux and not on RHEL.

      For a compatibility test suite for an operating system, I can't think of too many that are more comprehensive than building Oracle and Java.

    • (No, doesn't apply to Oracle; they were never good)

      I think a good analogy is that Oracle is acting like the USSR in WWII. Sure, the allies currently need their help and they're in this fight with us, so we just have to work with them while not trusting those evil fuckers one bit.

      • I like it.

      • Re: (Score:2, Interesting)

        The Soviets and their communist allies (e.g., China) ended up murdering far more people than the Nazis.

        In hindsight, perhaps we ought to have worked with the Axis to put down the Soviet threat first, and then take on Hitler once by far the more dangerous enemy had been taken care of.

    • Redhat was the vilian already back when they killed off Red hat 9 and gave us fedora core. Remember that? I do, I switched to gentoo like fool.
  • Pretty cool distro after running it for a couple of years. But I can't in good mind stay with them if they are getting in bed with Oracle in IBM's house.

    I guess it's time to see what all this Slackware noise is about.

  • by couchslug ( 175151 ) on Thursday August 10, 2023 @10:03PM (#63757938)

    Helping your corporate enemy remain popular is HIGHLY questionable.

    There is no more Red Hat, just IBM.

  • So, wait until, in response to this, they decline do distribute the source code for the BSD/MIT/apache parts of the distro. Things like NFS4, OpenSHH and OpenSSL (and many more) that are kind of important for an enterprise distro.

    Yeah, they will probably contribute upstream to those projects, and yes, they will probably provide the source code for Fedora (as fedora is the alpha and A/B testing for the next major version of RHEL), but they will less forthcoming for CentOS Stream, and will not release any cod

    • The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement. They would have to kill CentOS Stream, their free UBI offering and actively prevent Amazon employees (one of the largest third-party contributors to Fedora) from offering ABI-compatible drop-in replacements. Besides, they'd be killing their own business model, which was built upon nerds demonstrating the greater value in paying over and over again for fr
      • The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement. They would have to kill CentOS Stream, their free UBI offering and actively prevent Amazon employees (one of the largest third-party contributors to Fedora) from offering ABI-compatible drop-in replacements. Besides, they'd be killing their own business model, which was built upon nerds demonstrating the greater value in paying over and over again for free software vs. paying once for decade-supported proprietary equivalents. Take away the freedom part of the deal and there's little of value left compared to looking elsewhere.

        And guess what? The "Red Hat Universal Base Image" WILL NOT have any BSD/MIT/Apache sources (and why should it). That was the whole point of my post.

        • I think you've missed the point of my post, so allow me to make it clearer.

          The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement

          In the context of RHEL compatibility, nothing stops anyone from taking the binaries from UBI (minus artwork) and repackaging them for their distro (without source code) for packages where the source code is under a licence which doesn't require Red Hat themselves to publish it. For this reason, Red Hat withholding the source code to those packages makes no difference when it comes to clones wanting to be compatible, since as long as

          • I think you've missed the point of my post, so allow me to make it clearer.

            The binaries distributed by Red Hat for Red Hat Universal Base Image are fair game to pull from as they're not subject to the Red Hat Enterprise Agreement

            In the context of RHEL compatibility, nothing stops anyone from taking the binaries from UBI (minus artwork) and repackaging them for their distro (without source code) for packages where the source code is under a licence which doesn't require Red Hat themselves to publish it. For this reason, Red Hat withholding the source code to those packages makes no difference when it comes to clones wanting to be compatible, since as long as UBI exists, they don't need the source code to do that to begin with (just take the binaries!).

            Furthermore, CentOS Stream itself is distributed under GPLv2 (as per the EULA they include with the distro). That means all the sources must be published for all packages (even BSD/MIT/Apache licensed sources) and anything derived from that distro would be subject to the same GPLv2 terms. This would include at least all the RHEL BaseOS packages, as Red Hat refers to CentOS Stream as "a midstream between Fedora Linux and RHEL" making RHEL BaseOS a derivative of it. So Red Hat couldn't stop handing out the source code to all of the included packages (including Apache/BSD/MIT ones) without first killing CentOS Stream. Changing the terms of CentOS Stream to allow for withholding MIT/BSD/Apache sources would allow Oracle and other competitors to make their downstream distros somewhat proprietary too, creating even bigger threats. This means their only option would be to kill Stream off entirely.

            Does this all make sense to you now? Source code availability is irrelevant if UBI exists. As long as CentOS Stream exists, they must hand out sources. If they kill both those things entirely: As long as Amazon wants to save boatloads of money by exploiting Red Hat, they will pay existing (major) Fedora contributors already on their payroll a little more to also engineer RHEL-compatible drop-ins (similar to how they already pay them to work on Amazon Linux).

            How do you remove Redhat's artwork and copyright notices from the binaries without the source? Remember that OG CentOS had a big problem precisely because, in the very begining, they left all Redhat artwork and copyrights in the SW.

            CentOS stream is a property of Redhat. They can dual-license it if so they please, meaning that CentOS stream from Redhat would be distributed under a non GPLv2 License....

    • I don't like it and I also don't understand it.

      They had to know that there would be a community response, as well as a competitors' response.

      The former possibly more dangerous to them since without the community they don't have a product to sell. We come out with GPLv4, which explicitly forbids this kind of f*ckery and every other one we've discovered since GPLv3, and get key FOSS contributors to switch.

      Presto bingo. No more Red Hat, at least, not including the GPLv4 bits. Not the outcome I want (b

      • I don't like it and I also don't understand it.

        They had to know that there would be a community response, as well as a competitors' response.

        The former possibly more dangerous to them since without the community they don't have a product to sell. We come out with GPLv4, which explicitly forbids this kind of f*ckery and every other one we've discovered since GPLv3, and get key FOSS contributors to switch.

        Presto bingo. No more Red Hat, at least, not including the GPLv4 bits. Not the outcome I want (because Red Hat has been a semi-ok citizen before and I'd far prefer that we incentivize it to become a good one instead.) But it could be done.

        I don't see what they were thinking. I'm not sure I even see that they were thinking. In their shoes I would reverse this stupid decision either immediately or sooner, commit to never doing it again, and do everything in their power to demonstrate some degree of good will toward the community that makes their product possible.

        When they were a scrappy underdog, yeah, sure, doing a GPLv4 would have worked. Now that they have critical mass? No way! What's stoping them from forking the GPLv3 Version of the code, or moving to suitable alternatives licensed under BSD/MIT/Apache?

        Again, they have the critical mass in more than one way. They have a lot of developers (and money to pay them), the largest support organization for linux, lots of software vendors coding against their distro, and lots of semi-captive clients... Yes, that can c

        • >What's stoping them from forking the GPLv3 Version of the code, or moving to suitable alternatives licensed under BSD/MIT/Apache?

          Hemorrhaging money will stop them. That and the fact that alternatives for many, MANY core components that are GPL don't exactly exist.

          The cost of paying even more developers to work on code would be enormous. And hunt bug hunts. And squash the new bugs they introduce when trying to copy changes to a constantly diverging code base. All of those take a shit ton of money.

          Losing

    • If the competition advertises itself as "Redhat compatible", that establishes Redhat as the standard. And in the Enterprise market, why go for the off-shoot brand that's playing catch up rather than the real deal ?

      On top of it, "Redhat compatible" doesn't mean "take Redhat's work", it just means shipping librairies that are API compatible to Redhat, so that whatever is compiled on a Redhat system and dynamically linked still works and has all the needed symbols on your own non-Redhat system. Same for any

      • If the competition advertises itself as "Redhat compatible", that establishes Redhat as the standard. And in the Enterprise market, why go for the off-shoot brand that's playing catch up rather than the real deal ?

        On top of it, "Redhat compatible" doesn't mean "take Redhat's work", it just means shipping librairies that are API compatible to Redhat, so that whatever is compiled on a Redhat system and dynamically linked still works and has all the needed symbols on your own non-Redhat system. Same for any interpreters you ship.

        I don't get the hate for what Redhat is doing. It changes nothing to my daily life and I administer something like 1000 Redhat boxes. If it protects their business, all the better for me.

        Precisely, I agree 100% with you. But Redhat rather have you using Redhat Compatible CentOS stream* or a small company's Redhat compatible like Alma or Rocky, than you using a Redhat Compatible from Suze or Oracle and paying them instead of Redhat.

        * And therefore, beta testing the next point release of RHEL

  • Well Done, Red Hat!

Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.!

Working...