SUSE announces its own RHEL-compatible distro... again

SUSE is reconsidering the change of course it made at the beginning of last year: it is launching its own RHEL-compatible distro, or as it puts it, a fork of RHEL.

The company's recently appointed CEO Dirk-Peter van Leeuwen has made his first big announcement: that the German enterprise Linux vendor will launch its own Red Hat Enterprise Linux compatible distro soon.

In the announcement, a quote from Linux pro Greg Kurtzer reveals with whom SUSE is working: Kurtzer is the founder and CEO of CIQ, the company that sponsors Rocky Linux. The announcement comes soon after the claims from the Rocky Linux project that it has found a way around the new restrictions on Red Hat sharing the RHEL source code. It also, of course, follows even more closely upon Oracle's chutzpah-laden article on this subject.

The new SUSE project doesn't have an official name yet. However, the company may be able to get it off the ground sooner than one might otherwise expect, because this is not the first time that the company has built a RHEL-compatible distro. After Red Hat terminated CentOS Linux back in 2020, SUSE was working on an internal CentOS Linux 8 rebuild, codenamed "Liberty Linux" – a name that the company subsequently recycled for an expanded support offering, as we covered at the time.

Although we revised our coverage of the announcement, there are still reports of the original project behind the code name, and for German language speakers, Heise still has the details. (Also accessible, of course, to those adept with Google Translate or comparable tools.)

Traces of the internal testing of the distro were also noticed by the administrators of Red Hat's EPEL repositories, which contain additional extras not included in the core enterprise distro.

I like looking in dnf countme data to see the various distros requesting EPEL repos. There are often many weird distro names showing up in the single digits. But this one jumped out at me with 38 hits last week: "SUSE Liberty Linux". Is @SUSE creating a RHEL compatible distro?

— Carl George (@carlwgeorge) October 7, 2021

Little more information is available at the moment, but the terminology of it being a "fork" is interesting, especially in contrast with Rocky's self-description as "designed to be 100% bug-for-bug compatible" with RHEL.

The problem faced by the RHEL downstream distros today is not as broad as simply obtaining Red Hat's source code. That's quite easy. The issue here is not that Red Hat isn't providing the source code any more. It still is. The issues are around which parts it is providing, and to whom it's providing them.

The company no longer just puts the full source code on a public Git server for everyone to download. Now, there are two different ways to get it. One is open to everyone, but only covers part of the distro; the other is complete, but is only available to customers.

Anyone can get RHEL's userland components: in other words, pretty much the whole operating system, except for the kernel and drivers. You can get this via the RHEL Universal Base Images, or UBIs, as it documents – for instance, these RHEL 9 UBIs.

The problem is that container images are not what the Software Freedom Conservancy terms the "Complete Corresponding Sources". For complete source code, you also need the source code for the kernel and any bundled drivers and kernel modules. Red Hat is still providing that, too; the difference is, now it's only providing it to customers.

It's quite easy to get it: for instance, just sign up for a free developer's account. This comes with a free RHEL licence, so you can just install the OS, then download the source RPMs. Alternatively, as the Rocky developers have worked out, you could spin up a pay-as-you-go cloud image, use it to download the source, and then close it down.

This, though, leads to a more nuanced question: by doing this, is a third-party distro-builder legitimately gaining access to the source? And even more importantly, can they retain that access on an on-going basis? Red Hat is perfectly at liberty to close down any customer accounts that do this, or request that cloud providers do the same.

This may be why SUSE is saying that it's forking the distro. Last year, its plan was to recompile Red Hat's source code using its own Open Build Service tooling. (Rocky, meanwhile, has constructed its own Peridot build service.) All of the userland of the new distro was to be built from Red Hat's official Source RPMs, with the exception of the kernel, which was to come from SUSE's own enterprise distro, SLE, compiled using a Red Hat-compatible configuration. At present, SLE 15 SP 5 and RHEL 9.2 both use kernel 5.14. However, if SUSE's distro doesn't use precisely the same build as RHEL, then SUSE can't guarantee that hardware drivers built for RHEL will also work on SUSE's equivalent distro – but of course, it can offer customers its own enterprise kernel and accompanying drivers.

Last year, we noted that Oracle Linux 9 came with an optional alternative kernel, the company's own, modified build, which it calls the Unbreakable Enterprise Kernel or UEK, for which it also has an extensive version list. Perhaps the most notable additional feature in the UEK is that it supports the Btrfs filesystem, although Red Hat dropped support for it back in 2017. Btrfs is also extensively used in SUSE products.

It is possible that SUSE is just looking to the future and playing it safe here. Its new partner CIQ has found a route to obtain RHEL kernel and driver sources, but for now, it remains an open question as to whether this will continue to be available to it indefinitely. If Red Hat finds some way to close this path off, then the RHEL downstreams may be restricted in what they can obtain from the RHEL container images. That means building their own kernels, and that might be cause for calling this new product a "fork," rather than a bug-for-bug, 1:1 binary compatible rebuild.

• Fedora Project mulls 'privacy preserving' usage telemetry
• Red Hat's open source rot took root when IBM walked in
• Rocky Linux details the loopholes that will help its RHEL rebuild live on
• Red Hat strikes a crushing blow against RHEL downstreams

We recently discussed the lengths to which Red Hat's developers go to maintain these elderly kernels for years. SUSE, which has been around for 30 years already, has abundant experience in maintaining its own enterprise kernels, which may be one of the more valuable things it brings to the new partnership.

Oracle also provides external validation here. If Oracle Linux users find that Big Red's UEK is close enough to work, then perhaps so might users of this hypothetical new SUSE kernel build. It would not be a huge reach for the company to keep its enterprise kernel pegged to the same version number as Red Hat's.

There are some salient differences between this announcement and what SUSE was working on a couple of years ago. However, the company does have more prior experience than is immediately obvious, and the move represents serious, heavyweight endorsement for CIQ and Rocky Linux. ®