qwesx,
qwesx avatar

Red Hat's source code for RHEL (Red Hat Enterprise Linux) was previously publicly accessible, even if you were not a customer. Now only customers may get access to the source code (which is allowed by the GPL since source code only has to be delivered to those who have received binaries generated from it). But there are Linux distributions who use Red Hat's publicly available sources to create RHEL "clones" (in quotation marks because they obviously don't pretend to be RHEL), except without providing the corporate support one would receive for being a RHEL customer. They do have community forums though.

The superficial issue is that those "clone"-distros would have to either purchase a RHEL license or apply to one of Red Hat's other programs to access the sources for their own distro. The actual issue is that Red Hat's terms for being a customer are that they'll kick you out if you use that code to redistribute your own versions of it (or, god forbid, even create a full distro from it).

Since CentOS proper was killed off years ago, many people who wanted a Red Hat compatible server distro but didn't want or need commercial support shifted their systems to the aforementioned other "clone"-distros, which are now in danger of disappearing because of that change.

Is Red Hat legally able to do it? Yes. Is it a dick move? Absolutely. Will it help spread the popularity of RHEL or other Red Hat distros? Absolutely not.

bionade24, (edited )

Is it a dick move? Absolutely.

When this is such a dick move, why has no one cared about SLES not publishing the sources to a openly accessible page?

SFaulken,
SFaulken avatar

They do. It's called openSUSE Leap

cybersandwich,

In that sense, isn't Redhat pushing to CentOS Stream?

SFaulken,
SFaulken avatar

Uh. The relationship between CentOS Stream and RHEL is a bit murkier to me. I'd be lying to you if I said I fully understood how that code flow works.

For openSUSE the flow is "openSUSE Tumbleweed" -> "SUSE Linux Enterprise" -> "openSUSE Leap"

Everytime SUSE creates a new version/service pack of SLE (SLE 15 SP4, to use an example) the sources for that version are provided to openSUSE, and a new version of Leap is released (openSUSE Leap 15.4)

I don't actually work on Leap much, nor am I a SUSE Employee, so there are probably some minutae in that process that I'm missing, but that's the basic workflow.

mrbigmouth502,
mrbigmouth502 avatar

deleted_by_author

  • Loading...
  • Peruvian_Skies,
    Peruvian_Skies avatar

    It can't be retroactively amended, that's not how contract law works. The GPL isn't something you sign up for and you have to accept updates. It's a model license that people are free to use instead of writing their own. While a lot of people do license their software under "GPL version X or later", that is not mandatory and it would severely hurt GPL adoption if it were made mandatory in a future version.

    phoenixes,

    How is it that they can forbid clients from modifying+distributing this GPL code? I would have thought the GPL would always allow reuse and redistribution of GPL code.
    EDIT: Ah, someone else addresses this below at 2m17s: https://kbin.social/m/linux/t/103435/Can-someone-ELI5-the-situation-with-Red-Hat-and-CentOS#entry-comment-420884

    conciselyverbose,

    Is Red Hat legally able to do it? Yes.

    At best that's extremely debateable. The GPL explicitly precludes placing any other restrictions on receiving the code outside of the ones in the GPL. A paywall to receive code from them is allowed. Terminating access for someone exercising the rights explicitly granted to them by the GPL sure as hell sounds like an additional restriction to me. The entire contract you have to sign to receive the code the first time most definitely is.

    PabloDiscobar,
    PabloDiscobar avatar

    You did not mention the acquisition of Redhat by IBM in 2018. At the time, many observers were worried about what IBM would do with Redhat, and always wondered when IBM would go corporate crazy over a company with a model based on open source. So this decision crystalize the doubts that many people had at the time, that IBM would milk Redhat more, and this induce a kind of "Yep, of course they did go corporate crazy!" reaction.

    Many people feel burned and don't want to invest more efforts in a company with this kind of methods (they did not even allow a grace period) and want to jump ship.

    SFaulken,
    SFaulken avatar

    RedHat creates a product called RHEL (Red Hat Enterprise Linux) that is a paid support product, mostly targeted at businesses (and things like Academia/Laboratories/etc).

    At one point, there was a Wholly seperate product, created outside the RedHat umbrella, called CentOS, that quite literally took the sources of RHEL, removed the RHEL branding, and rebuilt it, allowing folks to "mostly" be able to use RHEL, without paying RedHat for a support contract.

    In 2014, the CentOS Project/Product was "purchased" by RedHat, and then in 2020, RedHat decided that CentOS would no longer just be a "rebuilt" RHEL, but instead would become the development space for RHEL, called CentOS Stream. This made many people very unhappy, and they decided to start the Rocky Linux and AlmaLinux projects to provide roughly the same product that prior versions of CentOS had provided.

    Additionally (I don't actually know exactly when), at some point, Oracle started doing basically the same thing that CentOS had been doing, and rebuilding the RHEL sources, and selling it, as "Oracle Linux"

    So net effect of what this means, is that RHEL sources will no longer be publicly available at git.centos.org, and will only be available to RedHat customers (i.e. you must have signed up for an account/license with RedHat for RHEL). This may make things more difficult for Rocky, Alma, and Oracle, to provide the same "Bug for Bug" compatible product to RHEL.

    Most of what people are upset about, is because they're willfully misreading the GPL (GNU Public License) which covers an awful lot of the RHEL sources.

    The GPL requires that if you distribute software, licensed under the GPL, that you also must provide the folks that you distribute that software to, with the sources you used. It doesn't specify how you have to provide them, you could make them available for download, you could mail folks a DVD with all the sources on it, (honestly, I think you might be able to just print them all out and send them on dead trees, and still be compliant).

    What most of the folks are upset about, is there is a clause within the GPL, that says something about providing the sources "without restriction on redistribution" or some such. And they view that RedHat can choose to terminate your license to RHEL, if you redistribute RHEL sources/software as violating the GPL. But the GPL cannot dictate business relationships. Redhat cannot stop one of their customers from distributing sources that they are licensed to have. But they are well within their legal rights to terminate that license, and provide no further access, if you distribute them. (i.e. you have an RHEL license, and version 1.0 of a library is covered under that license, you redistribute that source, and RedHat must allow that, but they're under no obligation to continue that business relationship, and provide you continuing access to version 1.1)

    That's a rough rundown on the history. What does this mean for the average linux user? Nothing, really. Unless you happen to use Rocky Linux, AlmaLinux, or Oracle Linux. It doesn't affect Debian, or Ubuntu, or openSUSE, or Arch, or anybody else. RedHat will continue to contribute back upstream to projects like the linux kernel, or GNOME, or what have you, they will continue to sponsor and hire developers, they just will no longer be providing free and open access to the RHEL Sources.

    It's not a question of legality really, but more one of an ethical nature. It sort of depends on you, as to whether or not you're bothered by RedHat doing this or not.

    Maximilious,
    Maximilious avatar

    Thanks for the thorough explanation - What does this mean for Fedora OS? Isn't that maintained by Redhat as well? I have a fairly large fedora server base in my homelab and hope I don't need to redeploy it all!

    SFaulken,
    SFaulken avatar

    Absolutely nothing. Fedora is upstream of RHEL.

    TheAgeOfSuperboredom,

    Doesn’t Red Hat own/run the Fedora Project though? Or is there some governance and/or infrastructure to prevent Red Hat from messing with it?

    SFaulken,
    SFaulken avatar

    I am only peripherally involved in Fedora as a contributor, but as I understand it, yes there is governance and infrastructure in place.

    mrbigmouth502,
    mrbigmouth502 avatar

    Unless you happen to use Rocky Linux, AlmaLinux, or Oracle Linux. It doesn't affect Debian, or Ubuntu, or openSUSE, or Arch, or anybody else.

    So, stupid question, but would Fedora be affected at all? I know that's related to Red Hat, but I'm guessing it's not affected since it's not based on RHEL.

    It's not a question of legality really, but more one of an ethical nature. It sort of depends on you, as to whether or not you're bothered by RedHat doing this or not.

    I'd say I'm bothered by it, but there's not really anything I can do about it. I'm disappointed the GPL doesn't have stricter rules regarding the distribution of source code though. I feel like it kinda defeats the purpose if sources aren't freely available to anyone who wants to use them.

    SFaulken,
    SFaulken avatar

    No, this doesn't affect Fedora in any meaningful way. Fedora is upstream of RHEL.

    mrbigmouth502,
    mrbigmouth502 avatar

    That makes sense. I thought it was upstream but I wasn't sure.

    rastilin,

    This is what I immediately wondered about as I'm on a Fedora spin.

    shatteredsteel,
    shatteredsteel avatar

    The only thing I think you may have gotten mixed up here is that CentOS or other clone distros didn't remove the branding. Red Hat did that themselves in thier repositories that were used in the clones.

    If I'm remembering correctly, in the very early days of Centos and the like, that was the deal that Red Hat had struck...you don't use our trademarks/branding and you can have access to all of our source. Most likely so that Red Hat wouldn't get endless support tickets without pay if something went wrong on a clone package.

    The rest of this seems pretty spot on.

    SFaulken,
    SFaulken avatar

    That's entirely possible. I never actually used, contributed, or developed for CentOS, so I might have some small details wrong.

    orcrist,

    There is a legal question. It would have to be litigated to be resolved, though. The argument is that when RHEL threatens to cut off future business, they are placing a restriction on redistribution. RHEL would argue that it's a restriction on future business, not on current redistribution, but who can say what a court would make of that distinction.

    It's true that RHEL does not have to continue a business relationship in general, but the point here is that they need to follow the GPL when making relevant business decisions.

    See also https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis/

    Invalid,

    Jeff Geerling has a pretty good summary: https://www.youtube.com/watch?v=kF5pyVUQBH8

    TheAgeOfSuperboredom,

    I’d also like to know what people are using server side instead. Debian?

    Thorned_Rose,
    Thorned_Rose avatar

    Arch and DietPi on the ODroid.

    rabidchaos,

    CentOS Stream. We don't need bug compatibility with RHEL, and it moves a bit slower than Fedora.

    GrumpyRobot,

    Been using Ubuntu Server

    TheAgeOfSuperboredom,

    That’s what I use, but I’ve been thinking of switching to Fedora due to Canonical’s insistance on snaps. Snaps just seem to give me trouble.

    xylan,

    Snaps are a nightmare. I've been using a VNC based remote setup for ages for our online training. In the latest ubuntu LTS there's a bug where applications installed via snaps don't trigger the appropriate cgroup permissions when running under VNC so you can't launch any of those applications. The bug is reported, verified and well described but no one from Canonical seems to be interested in applying a fix. I've ended up having to install a browser from the main Firefox site because I literally can't get the snap installed version to run any more.

    nottheengineer,

    When I typed sudo apt install firefox, pressed Y and ended up with snap firefox, I decided to stop using ubuntu and start hating canonical.

    TheAgeOfSuperboredom,

    100%! My wife kept having problems and it took us forever to figure out Ubuntu was installing snaps. She’s on Arch now BTW 😆

    Technoguyfication,
    Technoguyfication avatar

    I was a big Ubuntu Server fanboy until relatively recently. A couple years ago I shifted all my infrastructure into Docker, I don't run anything on my host machines anymore besides the Docker daemon, a few random cron jobs, and a sendmail configuration.

    Because of that, I'm switching to Alpine Linux on all my servers. I realized the only thing my machines do is operate as Docker hosts, so why should I carry around the weight of a fully fledged Ubuntu Server install? Alpine's package repo is very good and you can install all the utilities you want (ZFS, SMBD, Btop, etc.) with a single command. It's also a lot easier to maintain my host because there's a lot less to break between versions and less packages to update.

    TheAgeOfSuperboredom,

    That’s a really neat idea actually!

    rastilin,

    I've also been using Ubuntu server, but I have some regrets. I might start using Fedora on the newer machines and see how it goes, or openSUSE.

    Maximilious,
    Maximilious avatar

    I use Fedora and really like it. The only drawback for me is using podman instead of docker as some containers like mailcow don't have that 1:1 parity that podman boasts, but I do have roughly 30-40 containers running in podman without issues.

    For Mailcow and Kasm I spun up dedicated Debian or Ubuntu servers to serve them up.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • linux
  • kavyap
  • thenastyranch
  • ethstaker
  • DreamBathrooms
  • osvaldo12
  • magazineikmin
  • tacticalgear
  • Youngstown
  • everett
  • mdbf
  • slotface
  • ngwrru68w68
  • rosin
  • Durango
  • JUstTest
  • InstantRegret
  • GTA5RPClips
  • tester
  • cubers
  • cisconetworking
  • normalnudes
  • khanakhh
  • modclub
  • anitta
  • Leos
  • megavids
  • provamag3
  • lostlight
  • All magazines