back to article Rocky Linux details the loopholes that will help its RHEL rebuild live on

Last week, the Rocky Linux project said it had found a way to continue delivering its RHEL-based distribution. Now we have some information on how it's doing it. The decades-long battle between Red Hat and the various organizations cloning its enterprise Linux distro has taken a new turn. If you've been following the news …

  1. Down not across

    Reseller

    Intriguing. I kind of thought the cloud provider would be the customer and Rocky would not be RH customer, but customer of the reseller. I suppose lot comes down to what the reseller agreement and cloud providers agreement with its customers say. Plenty for legal people to think about.

    1. Anonymous Coward
      Anonymous Coward

      Re: Reseller

      The cloud provider is the redhat customer, which redhat have to provide access to the source. Rocky are the cloud providers customer that provides access to the redhat distribution which are also required to provide the source.

      Which kind of breaks the redhat customer agreement but may not break the service provider agreement, if it does, then redhat can't be resold and no cloud provider can provide redhat as the would be breaking the gpl.

  2. Rich 2 Silver badge

    To free or not to free

    I doubt RH will find it too difficult to close off these work-arounds. They’re not stupid

    I understand why some people are annoyed with RH. But I’m also not that sympathetic either. I see the argument that RH are making use of free code that’s out there and so they should, in turn,share their “added value” (ignoring the whole GPL technicalities for a moment). But (and I think this is significant) the free code that RH use is also free to you or me. So they are not stealing anything. To those sulking in a corner because their free tap of hard work is running dry, I would say “well do the work yourself then”.

    It’s been said a zillion times before but if you release your code for free (and are happy to do so) then you have to accept that it will likely get used in applications you don’t approve of, by people you don’t like, and in ways you don’t like. If you don’t like that then don’t release your code for free. Or at all.

    And if it wasn’t your code on the first place then you have absolutely no right to complain at all

    1. abend0c4 Silver badge

      Re: To free or not to free

      I think the problem here is that if you're a customer, you have an absolute right to the source code, even Red Hat isn't disputing that. What they appear to be saying, though, is if you exercise that right you may find you're no longer a customer.

      I'm not sure I'd be happy about long-term support being essentially dependent on an extra-contractual whim.

      1. Mark 65

        Re: To free or not to free

        I think this could start to sound the death knell for Red Hat. Its previous selling point was support and stability allowing software vendors the ability to have a one-stop "works on (Red Hat) Linux" option.

        Debian has stability and both support and stability are offered by Suse, Ubuntu, and potentially Oracle to varying extents. Containerisation, SAAS etc means that Red Hat's opportunity space is shrinking (likely prompting this nonsense) and if one of those other distros can seize the day it will thus have fully enshittified itself with this move and provided a case study for future reference.

    2. Anonymous Coward
      Boffin

      Re: To free or not to free

      @Rich 2: ‘I see the argument that RH are making use of free code that’s out there and so they should, in turn,share their “added value”’

      Why not take Oracle Linux and re-package that and request the full source code to the Oracle Database?

      1. alain williams Silver badge

        Re: To free or not to free

        Why not take Oracle Linux and re-package that and request the full source code to the Oracle Database?

        Because the Oracle Database is not under a free license. It is linked to free components (libraries) but these are under the LGPL which allows their use in non free software.

        The use of proprietary licensed programs under Linux has been allowed since forever without making those programs free.

      2. katrinab Silver badge
        Boffin

        Re: To free or not to free

        You are entitled to the source code for Oracle Linux, and link to download that is right next to the link to download the binaries. It doesn't ask you to agree to anything to download that.

        Oracle Database isn't part of the GNU/Linux operating system, it is a separate application that runs on it, and isn't GPL licenced.

        1. Anonymous Coward
          Anonymous Coward

          Re: To free or not to free

          It's a strange world when Oracle is less of a dick.

          1. mtategcps

            Re: To free or not to free

            IMAO, Oracle is the target here. Rocky and Alma just got caught in the blast radius.

    3. Anonymous Coward
      Anonymous Coward

      Re: To free or not to free

      > I doubt RH will find it too difficult to close off these work-arounds. They’re not stupid

      IBM/RH know they are on debatable legal ground but they are betting on the "We're IBM we have more lawyers than you" ground. They are betting that no one will seriously want to risk the cost of fighting them in court.

      But where people are using obtaining the source by being customers of a IBM/RH customer it won't be IBM's lawyers it will be the cloud providers lawyers you'd be fighting and the cloud provider would likely feel they had nothing to gain by fighting a court battle.

      As a direct customer of IBM/RH the situation is you enter into a contract, you then download the source and distribute it and IBM/RH terminate your contract. You then choose to fight this on the basis that the are effectively impose an extra restriction which is against the GPL. So you have to fight IBM's lawyers.

      As an indirect customer you have a contract with A.N.OTHER cloud provider, you download the code and distribute it and they terminate your contract so you sue the cloud company. What's in it for the cloud company to want to run up huge legal costs fighting it in court? Even IBM/RH won't want to terminate a cloud vendors contract because they lost a court case, I can't see any court accepting that one no matter how many expensive lawyers you can afford to field.

      1. Doctor Syntax Silver badge

        Re: To free or not to free

        The copyright owners have rights here. If they think RH are breaking copyright terms then they can take RH to court. Now here's a thing to ponder. There are an awful lot of them. There may even be more of them than RH/IBM have lawyers. What happens if they individually challenge RH? How many fronts can RH fight on?

        1. Anonymous Coward
          Anonymous Coward

          Re: To free or not to free

          The other key thing with this is that the copyright owners are spread all over the world and it would only take the courts in one country to force IBM/RH to stop people downloading the code to allow it to be freely accessible again.

        2. Malcolm Weir

          Re: To free or not to free

          What happens is that RH/IBM petition the court(s) to consolidate the cases, which the court(s) grant because they don't want to be litigating the same stuff repeatedly.

          1. stiine Silver badge

            Re: To free or not to free

            Only within countries.

            1. Malcolm Weir

              Re: To free or not to free

              True, albeit with a caveat that its probably a little more nuanced because "countries" and "copyright regulatory regimes" are not precisely the same (usually because of odd definitions of "country" -- looking at you, UK!)

      2. Anonymous Coward
        Anonymous Coward

        Re: To free or not to free

        Plus the biggest cloud vendors are AWS, Azure, and Google - who's got the most lawyers?

    4. TheWeetabix Bronze badge

      Re: To free or not to free

      “… But (and I think this is significant) the free code that RH use is also free to you or me. So they are not stealing anything. To those sulking in a corner because their free tap of hard work is running dry, I would say “well do the work yourself then”...

      You are completely ignoring the fact that this Libre and Gratis free code is someone else’s tap of hard work. By your own statements Red Hat should be willing to share its added value built on someone else’s Libre hard work, regardless of if it is Gratis or not. You can still steal something that’s Gratis free, not least by using it in ways that are against how it is licensed. If I steal a sweater someone else knitted for themselves, is it not stealing if it doesn’t have a price? Of course it’s stealing, I am stealing their labor, and using their possessions in an unlicensed way.

      1. DuncanLarge

        Re: To free or not to free

        > By your own statements Red Hat should be willing to share its added value built on someone else’s Libre hard work, regardless of if it is Gratis or not

        If their "added value" is under the GPL, the MUST share it when requested by those who have binaries distributed by RH or by anyone further down.

        That is the whole point of the GPL. The end user is king, you cant stop them being free.

    5. AdamWill

      Re: To free or not to free

      Here's the thing: we (I work for RH) *do* "share our added value".

      The thing we keep trying to communicate about this change is: if you're actually interested in doing Normal Open Source Stuff with Red Hat, "downstream of RHEL" is the *worst* place to be.

      We do not do any significant engineering work in RHEL. One of the internal buzzwords at RH is "upstream first". This means: you do your significant work upstream. All the interesting engineering work we do happens in upstream projects first, then in Fedora, then in Fedora ELN, then in CentOS Stream, then it *finally* trickles down to RHEL.

      If you actually want to do normal F/OSS collaboration with RH, you almost certainly don't want or need to be downstream of RHEL. The idea that cutting off the RHEL source means we're not "sharing our work" relies on a misunderstanding of how RH actually *does* work. There is no RH work that would be interesting to most F/OSS developers that's in RHEL and not in anything else. The 'value' of RHEL is not 'it has all this novel stuff in it that you can't find anywhere else'.

      The only significant reason that I can think of to be downstream of RHEL is to build a RHEL clone, and the only reason to build a RHEL clone is to not have to pay for RHEL or not have to deal with the subscription stuff. Which, I get it, people like and want! And you *can* argue that it's good for RH to provide/enable free RHEL clones, or that we "ought to" do it because "spirit of GPL" or "we bought CentOS" or whatever. That's up for debate. But I would argue that it's really a *separate* debate. If you want to see and participate in and contribute to and reuse the substantial engineering work RH does, *you already can*, because it all happens upstream of RHEL.

      The only stuff that happens in RHEL and nowhere else is *extremely* long-term backports - like, keeping 5+-year-old environments working and patched. Which is hard work, but it's probably not something many people are actually interesting in seeing and collaborating on. Aside from that, embargoed CVE fixes happen first in RHEL, but then land in CentOS Stream (and of course Fedora).

      If you take a wider view, I would argue we are significantly *improving* our F/OSS 'accessibility' in recent years. CentOS Stream is not what CentOS used to be, and if you want a RHEL clone it is not the thing you want, but it's much *better* for the 'spirit of open source'. Before CentOS Stream, this is how RHEL was developed:

      1. We forked it off Fedora (more or less)

      2. Stuff happened in private, behind the Red Hat firewall, where you couldn't see it, for months or years, then a RHEL .0 release appeared, with .src.rpms

      Now, this is how RHEL is developed:

      1. A new CentOS Stream release forks off Fedora ELN, which is a kind of variant of Fedora with RHEL-like customizations applied, and is entirely open - https://docs.fedoraproject.org/en-US/eln/

      2. The new CentOS Stream release itself is fully open, with git repos and everything. All the stuff that used to happen behind the RHEL firewall now happens in public. You can watch the process of the RHEL pre-release and .0 release coming together as it happens. You can submit pull requests, if you like.

      Between them, Fedora ELN and CentOS Stream move a *huge* chunk of the RHEL development process from happening in private behind the RH firewall where nobody could see it, to happening in public where everyone can see it and even contribute to it. This, to me, seems like a massive improvement in openness, and it's all happened in the last few years (under the Evil IBM Empire, no less).

      1. flayman

        Re: To free or not to free

        I don't buy it, Adam. Red Hat are upset because Oracle are selling subscriptions for support on its own rebuild that are cheaper than yours. Plenty of other companies have found ways to make money while benefitting from and, here's the kicker, giving back to open source projects. Red Hat was the first billion dollar open source company.

        This is a questionable and highly flawed move. At best it's a huge PR failure, given that the community are so upset. Of course there is value in the rebuilds. Having the rebuilds out there means that there are more bods running it and more eyes on the code. Other people besides Red Hat can work on improving long term stability, which benefits Red Hat and everyone.

        How is this supposed to work? Since anyone who receives the binaries of GPL software is entitled to the source, if the sources find their way back into one of the rebuilds, how are Red Hat going to know who provided it?

        1. chasil

          Oracle/RedHat pricing

          Oracle Linux support is not cheaper than Red Hat.

          Oracle Linux Basic: $499/year Premier: $1,399/year

          https://www.oracle.com/linux/support/

          Red Hat Workstation: $179 Server $349

          https://www.redhat.com/en/store/linux-platforms

          1. Shrek

            Re: Oracle/RedHat pricing

            With regards to pricing I would point out that you're not, at least in my opinion, doing a direct comparison there. I think RHEL Premium is the most direct comparison (24x7 support, production suitable etc) and costs $1,299 - so still cheaper but it's not as far apart as you make it seem. The $349 option for RHEL server is "Self Support" and "not intended for production environments."

            Of course, with both of those you are looking at options (e.g. CPU pair pricing of Oracle's offering and High Availability and other bundles for RHEL) which you may or may not need so I would assume that the final cost could vary quite widely from the headline figures depending on each specific use case.

            1. chasil

              Re: Oracle/RedHat pricing

              I see that RHEL pricing is also tiered, on 8x5 and 24x7. I guess this is a more complete list:

              Oracle Linux Basic: $499/year; Premier: $1,399/year

              https://www.oracle.com/linux/support/

              Workstation self-support: $179; 8x5 support: $299

              Server self support: $349; 8x5 support: $799; 24x7 support: $1,299

              https://www.redhat.com/en/store/linux-platforms

              1. Anonymous Coward
                Anonymous Coward

                Re: Oracle/RedHat pricing

                Big customers with hundreds of licenses don't pay list price anyway. They get a quote with a random discount from the sales reps.

        2. AdamWill

          Re: To free or not to free

          I'm not sure your reply has anything to do with my post? I'm not, really, interesting in getting involved deeply in the arguments about whether the RHEL source availability change is good or evil or in the spirit of this or that or the other or the whole red herring about whether rebuilds "have value" (which of course they do, in some sense, Mike kinda misspoke while trying to make a wider point there). What I do want to debate is the idea that not making the RHEL sources publicly available means we've "abandoned open source" (that's one take I've seen quite a lot) or that we're not "sharing our work" as was posited here.

          Whatever you think of the merits of the change (I don't really want to argue about it) or the legality of it (I'm not a lawyer, but I trust Richard Fontana when he says he reckons we're golden), I do want to argue that RH is still extremely committed to F/OSS when looked at on a broad scale and not just focusing on the availability of .src.rpms for RHEL. I want to argue that the question of being a good F/OSS citizen has to be a lot broader than RHEL .src.rpm availability.

          I think you've gotta keep in mind that we could achieve our goals here in a way that avoids any controversy over the "spirit of the GPL", but probably not a way people would like: we could just go open core. We could find some key but legally-severable-from-the-GPL bit of RHEL and just make it closed source. There, problem solved! Nobody can clone RHEL now, and the GPL has nothing to do with it, since we'd just be...not using the GPL for a bit of software. Just like Gitlab, or Docker, or Apple, or a zillion other software companies that use a lot of F/OSS. We don't do that *because* we actually do want to be as F/OSS-y as we can reasonably be while keeping our business going. We really do want that, believe it or not.

          Would that be better for everyone, overall, than our current attempt to keep our business running on a pure F/OSS model?

          1. flayman

            Re: To free or not to free

            Would it be better? I don't know, but it would make more sense. It would feel more honest, and I'm not wishing to imply dishonesty. It's just that I think a big part of the problem is that it's hard to understand what it is you are trying to achieve because it hasn't been explained well. The sources are going to find their way into the rebuilds sooner or later. You can't stop that. You can only slow it down. So as a couple of us have said on a different thread, a better approach would be to delay the publication of the sources. That would be acceptable and understandable. If I take you at face value, you have indicated that you might agree with this. I'm not really sure because my sarcasm detector is in the shop.

            The way this has been communicated is a disaster. I don't think that's even up for debate.

            1. AdamWill

              Re: To free or not to free

              As I said, I am not really in a position to argue about that part, and I don't really *want* to. It's going to happen and I guess we'll see how it all shakes out as we go along. I'm not involved in making or implementing any of those decisions (thankfully, because I'd be awful at it). All I know about what it's intended to achieve is, yes, it's intended to make life harder for the clones. How much harder do we want to make it? I don't know. How much harder will it actually make it? I don't know that either.

              I really am just interested in talking about RH's F/OSS commitments and contributions overall. I understand that this isn't a win in that column. I just want folks to take a broader view.

              My answer to my own question is that I don't think it would be better. I think it's better overall that we do all of our significant development in the open and release it for free, even if we have to do stuff like this to keep the money working out. I'd rather have this than just have us make stuff closed source. In an ideal world we wouldn't have to do this either, but I can't really argue with the folks who actually have to go out and sell this stuff so my salary gets paid. I've heard the stories they have to tell about just how hard the clones make it to do that, and I don't have a *better* idea for solving that. (I'm asking about whether the time delay approach was considered, though).

          2. abend0c4 Silver badge

            Re: To free or not to free

            >we're golden

            I'm not sure that "we have clever lawyers who can tie our customers in knots" is quite the commercial win for an open source company as you seem to believe.

            1. AdamWill

              Re: To free or not to free

              I didn't intend to present it as positive or negative, just as a statement. The law tends to work that way. either it's legal or it isn't. If our extremely experienced and high-powered F/OSS expert lawyers say it's legal, I'm gonna go with that. Whether you think it's good or bad or something more complicated is a different question and seems to depend a lot on where you're standing and what your values are.

              Personally, I wish we didn't feel like we had to do it. It doesn't feel great. But then, I also think it's pretty uncool to rebuild someone else's product and try to make money off it, if they don't want you to do that. As I posted on Mastodon, imagine the same situation with a small project, like davx (a dav sync client I use on Android). It's GPLv3. It's built on top of other F/OSS projects (so I guess the author is 'repackaging other people's work'). The author sells it for $7.50 in the Play Store to try and fund development. It's entirely within the letter and spirit of the GPL for me to take the source, rebrand and rebuild it (maybe as unbreakabledav?), and stick it up in the Play Store for free. Or for $2.50. Would it be cool to do that? I wouldn't feel that great doing it. I dunno. It's complicated.

              1. sten2012

                Re: To free or not to free

                > But then, I also think it's pretty uncool to rebuild someone else's product and try to make money off it

                Exactly what Red Hat currently do. Which up until the centos debacle I never heard anyone complain about.

                > if they don't want you to do that.

                Therein lies the rub. Are Red Hat checking every upstream are happy to be milked by this new business model? I'm not a major contributor to open source but may have some commits that have found their way into red hat, not sure. But here I am telling you "I DONT WANT YOU TO DO THIS" (or wouldn't, if nothing I've touched is in RHEL). And the community at large are saying the same. So have all packages you rebuild and sell given their blessings?

              2. flayman

                Re: To free or not to free

                Lawyers, especially high powered ones, are paid to come up with legal arguments that are arguable towards achieving some end. They will make that argument if they feel they can. Arguable does not mean it's guaranteed winnable. And honestly, if this is the situation we find ourselves in, it's already lost in one sense.

                "But then, I also think it's pretty uncool to rebuild someone else's product and try to make money off it, if they don't want you to do that."

                I'm sorry, but that's the GPL. The more I think of it, you'd be better off closing parts of REHL. Trouble is then you'd lose the contributions. RHEL is using a lot of open source code that the authors were happy to share. Some of those authors are now not so happy sharing it with RedHat. Open source depends on good will. It's actually not that complicated. What I think is going to happen now, and brace for it, is that RHEL will fork off and be maintained by a consortium of commercial and non-commercial entities who are prepared to nurture and appreciate the ecosystem that supports it. RedHat will lose control and the brand will die off. I hope it's not too late because that would be sad.

                EDIT: Maybe think about improving the bottom line by ditching the high powered lawyers.

          3. Anonymous Coward
            Anonymous Coward

            Re: To free or not to free

            You need to call accounting and ask they why a billion dollar company, that was bought by IBM, is hurting for money.

            If Redhat can't keep running with that much money coming in, not even IBM is going to be able to save them.

            1. flayman

              Re: To free or not to free

              "If Redhat can't keep running with that much money coming in, not even IBM is going to be able to save them."

              IBM's history over the last 3 decades is a case study in failure to adapt to changing markets. They shrugged off the world wide web until the paradigm shift became apparent, and then they were forced to become an industry follower. The 1990 book Barbarians to Bureaucrats by Lawrence M. Miller features this now ironic quote from IBM founder Thomas Watson, Sr: “Whenever an individual or a business decides that success has been attained, progress stops.”

              This 1996 article pretty much sums it up, and things have barely improved: https://sloanreview.mit.edu/article/the-decline-and-rise-of-ibm/

              “We are completely transforming the business to address the market for networked computer systems.” Lou Gerstner, then IBM CEO. 1996!

          4. Anonymous Coward
            Anonymous Coward

            Re: To free or not to free

            @AdamWill: Committed to open source, just not the license terms

      2. DuncanLarge

        Re: To free or not to free

        > ignoring the whole GPL technicalities for a moment

        Technicalities? Dont you mean the legally binding text of the license. Do you think I can ignore the "technicalities" of copyright and try and justify why I'm able to copy and sell the latest blockbuster?

        Thing is if I do that it is merely a thought experiment. It all comes crashing down when the "technicalities" are re-established when you re-enter real life.

      3. Jaybus

        Re: To free or not to free

        I don't think this is about Red Hat's contributions to FOSS, which everyone agrees is huge. I do NOT believe Centos Stream was about opening up Red Hat's internal development program. That was also said about Fedora when RHEL binaries were no longer available without subscription. Centos came into being because the life cycle of Fedora was way too short for most business use scenarios. Then along came AWS and other cloud providers and businesses using dozens of instances. Many were/are perhaps buying some RHEL 7 subscriptions to get the support they needed and then running Centos 7 on a bunch more cloud instances. Centos Stream, like Fedora before it, is about a short life cycle, making additional RHEL subscriptions more attractive to businesses than fooling with Centos Stream. Then along came Rocky from the ashes of Centos, prompting this current round of increasing the difficulty of building the distro from source.

      4. Anonymous Coward
        Anonymous Coward

        Re: To free or not to free

        That's a bit disingenuous. Being upstream is like tapping into <master>, being downstream would be like tapping into <release 7.0.12>. Although everything in that release is technically available in <master> it's not really there in any usable form, thus your strawman burneth.

    6. DuncanLarge

      Re: To free or not to free

      > I doubt RH will find it too difficult to close off these work-arounds. They’re not stupid

      All they can do is make it difficult, they cant close anything off.

      They could for example charge a distribution fee for the source code and post it to the requester on cd-r. More difficult yes, but to be legal they would need to do that minimum. The GPL states the source must be distributed in machine readable form, with everything needed to compile a working binary, and on a medium typically used for software interchange.

      Oh and before anyone says "but computers dont have optical drives", there is thing called USB and cheap USB drives everywhere. Also my new GPU arrived with a dvd-rom containing their NVIDIA drivers and manuals. Not the most common media today but not uncommon either so RH could simply make the source distribution slow and annoying, but the cant avoid it.

    7. ryokeken

      (ignoring the whole GPL technicalities for a moment)

      (ignoring the whole GPL technicalities for a moment)

      everything you said kind of a moot point if you casually ignore the license.

      would you say "if we ignore copyright law for a moment yadda yadda yadda "? nope

      That's the whole point of the GPL, to protect everyone's hard work from the real poachers and those who make excuses for them

  3. Howard Sway Silver badge

    making them Red Hat customers, at least briefly

    I suspected something like this would start happening.

    Red Hat are trying to restrict access, whilst the rest of the world only needs one person to get the source code once, then redistribute it. Banning customers one by one who do this seems like a crude method to attempt to stop it on RH's part. After all, even if they stop this loophole, I'm sure that other companies could find a large list of people who would be willing to accept a donation to purchase a full enterprise license and then make the source available, and take the hit of being "banned".

    1. Crypto Monad Silver badge

      Re: making them Red Hat customers, at least briefly

      I expect the next step will be that the SRPMS will become extremely hard to get hold of: not included in the cloud base images, not available to 'developer' accounts, and only available to "Super Platinum Plus" customers on $10K+ subscriptions. (Essentially, under the same sort of terms that you can get Windows source code).

      As for clouds, they don't even need to make the kernel binaries visible within the root filesystem. Hypervisors can boot from an external kernel image and initrd.

      1. alain williams Silver badge

        Re: making them Red Hat customers, at least briefly

        I expect the next step will be that the SRPMS will become extremely hard to get hold of: not included in the cloud base images, not available to 'developer' accounts, and only available to "Super Platinum Plus" customers on $10K+ subscriptions. (Essentially, under the same sort of terms that you can get Windows source code).

        The only way that RH/IBM could do that and remain GPL compliant would be to make the cheapest RH license cost $10k. Since we know that RH is not interested in small customers that is indeed a possibility -- the downside to them is that small software developers/vendors would be less inclined to support their stuff on the RH platform.

      2. containerizer

        Re: making them Red Hat customers, at least briefly

        That's unambiguously illegal under the GPL. Anyone who gets the binary must be allowed to get the source.

    2. Doctor Syntax Silver badge

      Re: making them Red Hat customers, at least briefly

      "Red Hat are trying to restrict access, whilst the rest of the world only needs one person to get the source code once, then redistribute it."

      The ROTW needs to access it every time a change is released.

    3. sbegrupt

      Re: making them Red Hat customers, at least briefly

      The only message RH is trying to send here is that RH clones do not get RELIABLE and TIMELY support, including for security fixes (which I can see embargoing from their own customers for a few days/weeks). This is enough for any serious company to buy from RH instead of using a clone if they operate a mission-critical system on RHEL. All the code in question is released by RH under GPL, often before it makes it to RHEL, sometimes after (eg security fixes). RH needs to just delay when the code is made available under GPL, not to actually prevent it from being shared.

      1. flayman

        Re: making them Red Hat customers, at least briefly

        Then all they had to do was say we are withholding the source code from public availability until a few weeks after it goes out to customers. It would be hard to argue against that, and it would have avoided this whole PR mess. That's not what they've said at all though.

        1. AdamWill

          Re: making them Red Hat customers, at least briefly

          y'know, I've somehow not thought to ask why we *didn't* do that. I will now, though...

  4. Conyn Curmudgeon

    Don't think I would like to use anything that is disputed and could break at any minute or rug pulled. That would be like using Apple in an enterprise environment. Stick with Debian and adapt.

    1. John Robson Silver badge

      "That would be like using Apple in an enterprise environment."

      Plenty of Apple devices in enterprise environments, they have a strong tendency not to break.

      Of course no Windows machine has ever broken in an enterprise environment...

      1. DuncanLarge

        > Plenty of Apple devices in enterprise environments

        In what universe would that be?

        1. Anonymous Coward
          Anonymous Coward

          > > Plenty of Apple devices in enterprise environments

          > In what universe would that be?

          In ours for example, as Macs are the standard for desktops and laptops in my workplace, with the exception from certain user groups which have Linux desktops or laptops (usually workstations), plus a smaller number of users who just need an (enterprise) Chromebook (although some of these users also have a desktop Mac or a Linux desktop workstation).

          Right now there are only a small number of Windows systems left and their number is shrinking literally by the day, and with Windows disappearing from our environments the support costs have gone down as well.

          We also see an increasing number of Macs with our clients.

  5. Alistair
    Windows

    Not to be the cynic in the room, but

    Lets be blunt. Redhat has no animosity to the downstream freebie distro's that publish its work. Sure the commentary said "they bring us no value". Everyone in the room knows darned well that that line is from the pile out back of the barn. Redhat has one, and only one, target with this move.

    Oracle has OEL, directly from the fat purple hats work, and Oracle has spent *years* and *millions* of dollars doing its damnedest to get everyone on the planet to pay them for .......... no, not the DB, JAVA. Because java is everywhere. Redhat simply wants to force Oracle into a long term, multi-million dollar agreement to pay for the RHEL sources. Much like Oracle would do with java if there weren't so many forks available. Either that or make Oracle do the work themselves, meaning investment in bodies and infrastructure to do the work.

    There are a couple of other far lesser known distros that have indeed used the RHEL sources and charged downstream for support, but those are highly specialized and will quickly make an appropriate agreement with RH. They aren't billion dollar companies, but specific to certain fields, and again, they do add work, specialized to those fields.

  6. Doctor Syntax Silver badge

    " If you are using hardware whose vendor only offers drivers for RHEL, or the applications that you need are only supported on RHEL – " then you might be having a bit of a discussion with that vendor right now.

    For H/W manufacturers drivers are a necessary means to sell their product, they aren't a product in themselves. If the availability of a say, Debian, driver becomes essential for selling product then a Debian driver will be along in due course. After all, they're both Linux drivers; it's not like they'd be starting from scratch. The reason why there's only RH at the moment is going to be because marketing tell them that's all they needed. Markets can, and do, shift.

    1. Anonymous Coward
      Anonymous Coward

      Q. How distro-dependent are drivers these days? I'd have thought that drivers are related to the kernel being used rather than the cruft put around it, or are there variations in that distro related cruft that affects HW drivers?

      1. JulieM Silver badge

        How distro-dependent are drivers these days?

        Not at all, and they never have been! There is nothing magical about drivers. You should be able to build and install them on anything.

  7. luis river

    initiative CPU RISC V equal LINUX unbranded ?

    RedHat LINUX fully private, there are similar point of view to CPU ARM full property of SoftBank. World time ago search new CPU, and born RISC V. Me opinion: please LINUX need same nice work, by contributions effort all industry community.

  8. chuckufarley Silver badge

    Colour me blind, but...

    ...I don't think Rocky will be able to continue. The corporate world has too many "Nuclear Options" to eliminate those seen as freeloaders in the market spaces. As far as Enterprise customers really, seriously using a Debian LTS? That is so odd that I can't even laugh at the thought. Debian is a distro still exists because of and for it's developers and those developers do not give a rat's ass about enterprise computing needs. By the time they realize that they should care the moment will have passed, the Enterprises will have had second and third thoughts, and a more suitable match will have been found.

    I bet the install numbers of opensuse are going through the roof this quarter.

    1. ChoHag Silver badge

      Re: Colour me blind, but...

      The thing the corporate world doesn't understand in turn is that the "freeloader market" has its own nuclear option in response to being shoved out, and that's to stop participating. The effects are subtle, long term and permanent.

      Funny that in a world build on advertising, the advertisers can't see the free adverts.

      1. chuckufarley Silver badge

        Re: Colour me blind, but...

        Well, yes and no. When it comes to "not participating" it's like reading a pubic forum and never, ever responding in any way, shape or form. No human can resist it over a long enough time scale. The practice of shunning is powerful and cuts both ways. More often than not the powers than be shun first to silence any potential response from the upstarts. While I am not lawyer I do believe that the global legal systems have entrenched this practice to protect themselves from the 'terrorists' that would be so bold as to define words with meaning instead of money.

        1. DuncanLarge

          Re: Colour me blind, but...

          Yep, like I said. You have no clue what world you inhabit.

          Perhaps you are a corporate bigwig who has barely a clue what this Linux thing is? I thought those types might still be about after 20 years.

    2. flayman

      Re: Colour me blind, but...

      Okay, I'll colour you. I don't think you know what you're talking about, especially when it comes to Debian. If you have a look at the most popular docker images on Docker Hub you'll see that they are mostly built on Debian Buster or Bullseye. That's because Debian is the most stable and reliable Linux distro there is. There's also Alpine for the ultra lightweight builds. It almost doesn't even matter what you're running for your Linux host. As we move more and more towards cloud native workloads as the standard practice, RHEL is not going to be seen as such a crucial piece.

    3. DuncanLarge

      Re: Colour me blind, but...

      > The corporate world has too many "Nuclear Options" to eliminate those seen as freeloaders in the market spaces

      Seems you have no idea what the GPL is for then...

    4. Anonymous Coward
      Anonymous Coward

      Re: Colour me blind, but...

      How about this then - at the major financial player I used to work at, they had a single RH instance in production and everything else was CentOS (prod, staging, dev). The RH instance was only there for if a problem arose so that they could call on the expensive SLA and get them to "fix their shit". Why pay for licenses you simply don't need?

      1. disk iops

        Re: Colour me blind, but...

        You can say it. Bloomberg. and so did Nielsen Media, you know, the ratings company.

  9. sammystag

    Licence

    Perhaps a silly question but if the Linux community is so outraged by Red Hat's actions, can we expect a license change to the Linux kernel along with the multitude of other upstream components Red Hat uses forcing them to make their source code freely available if they want to make use of any future release? The options for Red Hat would then be release their source code or maintain their own fork of today's latest version of whatever they use.

    1. Max Pyat

      Re: Licence

      This was my first thought

      Although I'm still unconvinced that Red Hat's actions don't violate the GPL.

      1. alain williams Silver badge

        Re: Licence

        Although I'm still unconvinced that Red Hat's actions don't violate the GPL.

        That is not what @sammystag is saying. s/he is suggesting that licenses evolve to a new set that forbid what RH has done. If these licenses are then adopted by enough core components then RH will have to back down.

        If only a few adopt the new licenses then RH can simply rewrite them, or maintain a fork from before the component's license was changed.

        1. sten2012

          Re: Licence

          Think you may have missed what Max was saying too, the double negative perhaps?

          They are saying you might not need to change anything to forbid it if the GPL already has.

    2. Doctor Syntax Silver badge

      Re: Licence

      "can we expect a license change to the Linux kernel along with the multitude of other upstream components Red Hat uses forcing them to make their source code freely available if they want to make use of any future release?"

      The Linux kernel has, over the years, had a large number of contributors. All have contributed under GPL2. In order to change it all those contributors would have to be contacted and their consent obtained. Some will not have been on contact with the kernel devs for some time, maybe years, and would have to be traced before they could be contacted. Some will have died and the tracing extended to find their heirs. And some will work for Red Hat. Failing such consent the non-consenting and untraced contributors contributions would have to be replaced. This has been pointed out in every thread relating to this.

      Taking all that into account, you tell me - can we expect a licence change?

      1. sammystag

        Re: Licence

        I'm not sure that's right. It might be, I'm not a lawyer. My understanding is that I could fork the Linux kernel and distribute my fork under a licence with additional terms as long as it complies with all the requirements of GPL2 . If that's true, wouldn't if follow that the main project could change licence for future releases requiring source of any derivative works to be published openly to everyone?

        1. heyrick Silver badge

          Re: Licence

          Unfortunately GPLv2 isn't compatible with GPLv3, and if a GPLv4 turns up that fixes this shitshow, it won't be compatible with GPLv2 either. So, no, it's not as simple as simply switching the licence in future versions as people have their work according to the current licence and the current licence clearly states no additional restrictions (which is why it can't be GPLv3ed).

          1. sammystag

            Re: Licence

            Thanks, makes sense. That's unfortunate

    3. DuncanLarge

      Re: Licence

      > can we expect a license change to the Linux kernel along with the multitude of other upstream components Red Hat uses forcing them to make their source code freely available if they want to make use of any future release

      RH source code is already forced to be avaliable to anyone with the binary (although not for free, a distribution cost can be charged) so I dont see what your point is.

      1. sten2012

        Re: Licence

        One such change could be that source code must made available to your supplier too, for example, to allow for enforcing pulling source code changes upstream on request too.

        Then if Red Hat chooses to terminate that contract because someone invokes their right.. well.. at least it's mostly just screwing themselves.

  10. bazza Silver badge

    Quick Sanity Check

    If one gets login access to a cloud instance of a vm running rhel, then has one really received the binary?

    Certainly Gpl2 is based on receiving a copy of the program. Being able to see the program run isn't the same as having it.

    1. talk_is_cheap

      Re: Quick Sanity Check

      You have received a copy of the program - it can be found under / of the file system. The fact that it does not come on 1000's of floppies or 10's of CDs does not change the fact that you have access to a copy - otherwise, you would not be able to run the Linux kernel.

      1. bazza Silver badge

        Re: Quick Sanity Check

        But it's the host that is running the kernel, not one's own hardware... If one copied the VM content over, then one definitely has received the program.

        Perhaps the inevitable thing is that, if one is granted access to the VM, one then has permission to copy the VM content. So they have implicitly given you the right to receive the program, so that also confers rights to the source.

        1. thondwe

          Re: Quick Sanity Check

          And how many hardware device drivers in the kernel running on a VM Host - I won't expect to see any really, just the Hypervisor specific drivers - so Rocky et al would only be able to run on the same Hypervisors - which may in themselves be custom variants of the standard ones e.g. Azure not quite HyperV, AWS not quite QEMU/Xen?? Only really VMware would be safe?

          Anyway, won't then run on physical tin??

          Rocky Ground (Sorry probably been done!)

          1. Red~1

            Re: Quick Sanity Check

            Certainly looks like there'll be a rocky road ahead! (sorry, I couldn't help myself)

          2. bazza Silver badge

            Re: Quick Sanity Check

            Another possibility is that VM images start not including the kernel image. It's never really read post-boot, the VM would run along just fine without it, and a hypervisor could be created to launch the the VM with the kernel already "loaded" from outside of the disk image and therefore not included in the disk image.

            However, can one create a kernel image from a kernal already loaded into memory? That might not even matter. Just having a copy of the RAM for where the kernel resides means "you have the program" and nothing in GPL2 says that it has to be runnable. If a root process can access any RAM (maybe you'd have to load a specially devised kernel module to help), then you could get an image of the kernel

            Early and Extensive Thought Experiement -> RedHat Reversal?

            None of this is good news BTW, but if there is going to be a game of cat/mouse it's good to think about to where that game could reach. If it can be shown early on that there is no way that commercial providers of RHEL instances can do so without the customer getting a copy of "the program" (even if that is in a RAM-copied form, instead of a bootable form (if there's any difference)), and therefore being entitled to the source, then that may be useful for forcing an early reversal of Big Purple's position.

            1. bazza Silver badge

              Re: Quick Sanity Check

              What I've outlined above could the fatal weakness in RedHat's position. For an RHEL instance to be useful to a customer, the kernel and their applications must be allowed to sit in the same memory space.

              They might try some T&C's that say "don't do this", but that'd then be like them saying "we admin your VM, you cannot", and that's not a tenable marketing proposition.

              They might try witholding lumps of the source folder tree for drivers they've not included in the kernel image for the VM, but that could be a bit tricky; the source for the kernel also includes all the drivers, and a partial copy of it might not count as "the whole source", even if chunks of it were not built into the program the customer has received.

              1. the spectacularly refined chap Silver badge

                Re: Quick Sanity Check

                They might try witholding lumps of the source folder tree for drivers they've not included in the kernel image for the VM, but that could be a bit tricky; the source for the kernel also includes all the drivers, and a partial copy of it might not count as "the whole source", even if chunks of it were not built into the program the customer has received.

                Not an issue, the GPL was always drafted with the intent you can cut bits out and slot them in elsewhere... "That's a useful data structure, I'll have that" or "I'll rip out that function for this" is the original intent of the licence. You've never had to supply the source in full by design, only the portions you use.

    2. Teal Bee
      Holmes

      Re: Quick Sanity Check

      One of the few comments worth reading.

      Indeed, getting access to a program does not automatically make somebody a recipient of the program. If an employer installs Linux on servers, then employees logging into those servers do not get any rights to programs found there, irrespective of licence.

      The fact that so many software vendors make source code freely available to the public has blurred the distinction between recipient and user in people's minds.

      1. Anonymous Coward
        Anonymous Coward

        Re: Quick Sanity Check

        Indeed, getting access to a program does not automatically make somebody a recipient of the program

        You may see it that way, but it's how a judge sees it that will matter.

        1. bazza Silver badge

          Re: Quick Sanity Check

          Could get really, really tricky if it reaches court.

          As I've outlined above, there's probably no way that RedHat can stop RHEL instance users copying the kernel from the VM they're renting. Arguably, that'd be a bit like leaving an apple pie to cool in the window, and someone making off with it. The text of the GPL2 uses the phrase, "that you distribute or publish". In some senses, allowing someone to get next to the kernel doesn't mean you've handed it over to them; you've not distributed or published it. However, by allowing a customer on to the VM with root access, you're permitting them to take a copy of the kernel, at least from RAM or from the VM disk image (if it's there). But, they're doing the taking, you're not posting, sending, transferring the kernel to the user. It's a bit like putting a sign by the apple pie saying, "help yourself", but you've not engaged in the act of cutting slices and handing them out.

          The mechanism of accessing a rhel VM instance clearly isn't dealt with explicitly in the GPL2 text. The interpretation of the GPL2 in the context of a rented VM could keep lawyers and judges for a very long time...

          1. Anonymous Coward
            Anonymous Coward

            Re: Quick Sanity Check

            The very fact that the FSF made the Affero GPL (AGPL) to target SaaS could be taken as a hint that the FSF believes that the normal GPL covers the cloud rental model sufficiently.

  11. Doctor Syntax Silver badge

    "As we recently described, Red Hat goes to extreme lengths to keep old kernels supported and secure."

    My takeaway from that talk was that it was about the hoops external contributors had to go through and the testing RH would perform to get external submissions into the long-term supported kernels. The contributors may have been upstream recent kernel contributions to be back-ported or third parties (?H/W vendors) wanting to get things in. Unless I missed something - possible as I found the delivery extremely soporific - there was nothing there about RH providing their own additions.

  12. K.S. Bhaskar

    RH is probably more interested in blocking Oracle Linux than Rocky, Alma and friends. My guess is that they will close the loophooles that Rocky Linux uses, but leave others open. We will know in the weeks ahead who they really want to block.

    1. Anonymous Coward
      Anonymous Coward

      We will know in the weeks ahead who they really want to block.

      Will we? After all you cannot really block one without blocking the other.

      Chances are this is all about Oracle stiffing IBM on something way back in the day.

  13. Anonymous Coward
    Anonymous Coward

    I wonder how long before Red Hat stops distributing non-GPL source code, either specifically for the UBI / cloud case, or even for all customers, so as to make it impossible to have a 'full clone' of RHEL (as there's quite a few packages on a typical system that are e.g. BSD or MIT licensed which unlike GPL licensed packages have no requirement to provide source along with a binary)...

  14. IGnatius T Foobar !

    Sounds less than feasible

    This sounds less than feasible to me. It's clear that IBM does not want Blue Hat Linux clones to exist, and when IBM decides they're going to screw something up, they put the full force of their bureaucracy behind screwing it up.

    I for one am ready for the world to retire the RPM ecosystem.

  15. Anonymous Coward
    Anonymous Coward

    Collateral damage

    These loopholes could be the catalyst for folks demanding source files from rivals in the exact same way. Nothing could stop folks also demanding source code for Canonical’s Ubuntu Pro updates, while using reproducible builds to recreate their expensive paid extras (like their FIPS-certified binaries) for people to use at no cost. With reproducible build projects getting closer and closer to producing identical binaries for whole distros, it won’t be long until selling updates to GPL-licenced projects becomes a non-starter (for those who don’t have full copyright allowing for closed-source variants to be released at least).

    What would stop say Microsoft from doing what Oracle Unbreakable Linux does, except for Ubuntu Pro and their extended maintenance?

    Red Hat has royally screwed all the vendors, not just themselves.

  16. Sanguma

    Cory Doctorow seems applicable here

    I just found a term which seems to fit the current Red Hat trajectory - Cory Doctorow's enshittification, to wit:

    "Here is how platforms die: first, they are good to their users; then they abuse their users to make things better for their business customers; finally, they abuse those business customers to claw back all the value for themselves. Then, they die."

    It would apply to companies as well as platforms. MS Windows began to run into this during the 2000s; Linux's hedge against enshittification would be that it is free and open source; however, Red Hat as a company, doesn't have that hedge.

  17. The Velveteen Hangnail

    RHEL remains an important product to a lot of big businesses,

    > RHEL remains an important product to a lot of big businesses,

    Not for much longer it won't. Or at least, it's going to obliterate it's mindshare and become the Oracle of the Linux world. They screwed the pooch with their handling of v8, and this is another very large nail added to the coffin.

    Unless you have a very good reason, and deep pockets, to use RHEL, you won't touch it with a 10ft pole. I also expect Fedora will also start taking a nose-dive too (assuming it hasn't already). I know I won't be touching anything Redhat anymore without a very good reason.

    It also raises concerns about everything _else_ Redhat makes, like Ansible and IPA. Are they going to go proprietary too?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like