Enterprise Linux 2026: RHEL-Clones, RHEL Subscription und die neue Lizenz-Landschaft

Red Hat hat 2023 die Spielregeln geändert. Wer seitdem RHEL-kompatible Distributionen betreibt, sitzt auf einem Fundament, das sich verschoben hat – und der Markt hat reagiert. AlmaLinux, Rocky Linux, ein SUSE-Fork mit Millionenbudget und alte Bekannte wie Ubuntu Pro und SLES konkurrieren 2026 um Enterprise-Workloads, die früher selbstverständlich CentOS liefen. Was davon ist stabil genug für Produktionsumgebungen, was ist Ideologie mit LTS-Label?

Was 2023 wirklich passiert ist

CentOS war jahrelang der de-facto-Standard für Unternehmen, die RHEL-Kompatibilität ohne Subscription-Kosten wollten. Das klassische Modell: Red Hat veröffentlicht RHEL, die Quellen landen im Customer Portal, Community-Projekte bauen bitidentische Klone daraus. Funktionierte über zwei Jahrzehnte.

Dann änderte Red Hat den Zugriff auf die vollständigen RHEL-Sourcen. Wer heute die zeitnahen, vollständigen Quelltexte haben will, braucht entweder eine aktive RHEL-Subscription oder Zugang zum Red Hat Customer Portal. Die Quellen sind technisch weiterhin GPL-lizenziert – das ist kein Lizenzbetrug, sondern eine Zugangsfrage. Der Code muss auf Anfrage rausgegeben werden. Nur eben nicht mehr öffentlich und sofort.

Das hat praktische Konsequenzen. Projekte wie AlmaLinux und Rocky Linux, die vorher aus öffentlich verfügbaren RHEL-Quellen bitidentische Rebuilds erzeugten, mussten ihre Strategie anpassen. CentOS Stream, das Red Hat weiterhin öffentlich pflegt, ist kein klassischer Downstream-Klon mehr, sondern eine Rolling Preview, die dem stabilen RHEL-Release vorausläuft. Für Enterprise-Umgebungen, die auf reproduzierbare Stabilität angewiesen sind, ist das ein wesentlicher Unterschied.

RHEL 2026: Was die Subscription kostet und was sie liefert

Red Hat Enterprise Linux ist aktuell in Version 10.1, veröffentlicht am 11. November 2025. Das Subscription-Modell verspricht zehn Jahre Support pro Major-Version – aufgeteilt in Full Support und Maintenance. Das ist für Enterprise-Infrastruktur keine Kleinigkeit. Wer heute RHEL 9 einsetzt, hat damit eine definierte Plattform bis mindestens 2032.

Was die Subscription konkret enthält: Sicherheits-Backports, Zugang zu Red Hat Satellite für Patch-Management, kpatch für Kernel-Live-Patching, SELinux-Härtungsprofile, FIPS-140-zertifizierte Komponenten und ISV-Zertifizierungen für Softwareprodukte wie SAP oder Oracle Database. Letzteres ist für viele mittlere und große Unternehmen nicht verhandelbar. SAP HANA auf RHEL läuft – auf AlmaLinux offiziell nicht, weil SAP keine Kompatibilitätszertifizierung für Community-Distributionen ausstellt.

Die RHEL Subscription schützt außerdem vor dem, was der CERT-Bund regelmäßig dokumentiert: Im März 2026 listete das BSI mit WID-SEC-2026-0756 eine lokale Privilege-Escalation-Schwachstelle in RHEL. Vendor-Support bedeutet in solchen Fällen nicht nur einen Patch, sondern einen definierten Reaktionszeitraum und Backport-Garantien für ältere Minor-Releases. Community-Distributionen liefern Patches oft nach – aber „oft“ und „nach“ sind keine SLAs.

AlmaLinux und Rocky Linux: Von Klonen zu kompatiblen Plattformen

AlmaLinux beschreibt sich selbst als „Enterprise Linux, Free Forever, Community-owned und RHEL-kompatibel.“ Das ist die ehrlichste Formulierung, die das Projekt gewählt hat – und sie ist wichtig. Nicht mehr „bitidentisch“, sondern „kompatibel“. Der Unterschied klingt nach Marketing, ist aber technisch relevant.

Was „RHEL-kompatibel“ konkret bedeutet: ABI- und API-Kompatibilität, gleiche Paketversionen, gleiche Verhaltensmuster für Anwendungen. Das reicht für den Betrieb der meisten Workloads. Es reicht nicht zwingend für ISV-Zertifizierungen, die gegen das exakte RHEL-Binary geprüft wurden. AlmaLinux betreibt ein eigenes Test-Framework und hat in der Community erhebliche Glaubwürdigkeit aufgebaut. Das Projekt wurde 2021 als CentOS-Nachfolger gegründet und hat seitdem stabile Release-Zyklen geliefert.

Rocky Linux verfolgt eine ähnliche Strategie. Beide Projekte haben nach Red Hats Quellcode-Änderungen auf alternative Build-Pipelines umgestellt, die CentOS Stream und Upstream-Quellen kombinieren. Die technische Frage, die Administratoren sich stellen sollten: Reicht ABI-Kompatibilität für den konkreten Workload, oder gibt es proprietäre Kernel-Module, ISV-Anforderungen oder regulatorische Vorgaben, die RHEL-Vendor-Support erfordern?

Für die Mehrzahl der Anwendungsfälle – Webserver, Datenbanken, Container-Hosts ohne proprietäre ISV-Abhängigkeiten – ist AlmaLinux oder Rocky Linux eine sachliche, technisch solide Wahl. Ich sehe das nicht als Ideologie, sondern als Kalkulation: Subscription-Kosten einsparen, Community-Support und externe Dienstleister nutzen, Kompatibilität regelmäßig testen. Das funktioniert, wenn man es ernsthaft betreibt.

SUSEs RHEL-Fork: Mehr als eine Ankündigung

SUSE hat 2023 angekündigt, einen eigenen Fork von Red Hat Enterprise Linux zu entwickeln – eine RHEL-kompatible Distribution außerhalb von Red Hats Zugangsbeschränkungen. Das Projekt ist mit über zehn Millionen US-Dollar Investitionsbudget hinterlegt. Das ist kein Wochenendprojekt.

Das strategische Ziel von SUSE ist transparent: Den Quellcode dauerhaft frei zugänglich zu halten und das Projekt in eine unabhängige Open-Source-Foundation zu überführen. Damit adressiert SUSE direkt das Risiko, das Unternehmen beschäftigt: Was passiert, wenn Red Hat die Lizenzbedingungen erneut ändert? Eine Foundation-getragene Distribution mit eigenem Quellcode-Zugang ist strukturell widerstandsfähiger gegen einseitige Vendor-Entscheidungen.

Wichtig für die Einordnung: Zwischen Ankündigung und produktionsreifem Einsatz liegt Entwicklungszeit. Der SUSE-Fork ist kein Ersatz für SLES, sondern ein Zusatzprojekt für Unternehmen, die aus dem CentOS-Ökosystem migrieren oder RHEL-Workloads ohne Subscription betreiben wollen. Wer heute migrieren muss, kann noch nicht vollständig auf den SUSE-Fork setzen – das ehrliche Bild ist: Roadmap vorhanden, Produkt noch im Aufbau.

Dennoch verändert die Ankündigung den Markt. TuxCare ordnet in ihrer aktuellen Marktübersicht die neuen Akteure und Lizenzmodelle strukturiert ein – und der SUSE-Fork ist dort ein eigenständiger Kandidat, kein Anhang.

SLES und Ubuntu Pro: Die unterschätzten Alternativen

SUSE Linux Enterprise Server ist nicht das aufgeregte Thema gerade, aber es ist eine ausgereifte kommerzielle Enterprise-Distribution mit eigenem Long-Term-Support-Modell und Subscription-Struktur. SLES läuft in Rechenzentren, die Stabilität und Vendor-Accountability brauchen, ohne vom RHEL-Ökosystem abhängig zu sein. Für Shops, die ohnehin SUSE-Technologie einsetzen, ist SLES die logische Wahl.

Ubuntu Pro ist Canonicals Antwort auf den Enterprise-Markt. Das Modell: Ubuntu LTS als Basis, Ubuntu Pro als kostenpflichtige Erweiterung mit bis zu zehn Jahren Sicherheitssupport, FIPS-zertifizierten Paketen und Landscape für zentrales Patch-Management großer Server-Flotten. Canonical positioniert Ubuntu Pro explizit als Alternative zu RHEL – und für Python-, AI- und Cloud-Workloads ist Ubuntu im Enterprise-Umfeld tatsächlich stark verbreitet.

Was Ubuntu Pro von RHEL unterscheidet: Das ISV-Zertifizierungsökosystem ist schmaler. Viele klassische Enterprise-Softwarehersteller zertifizieren primär auf RHEL und SLES. Canonical holt auf, aber wer SAP oder bestimmte Oracle-Produkte mit Vendor-Support betreibt, hat weiterhin eine eingeschränkte Wahl. Red Hat selbst beschreibt den Auswahlprozess für Enterprise-Distributionen erwartungsgemäß aus eigener Perspektive – aber die Kriterien, die dort genannt werden (Zertifizierungen, Lifecycle, Support-SLAs), sind trotzdem die richtigen Fragen.

Das Lizenz-Modell-Raster: Was wirklich zählt

Wer heute eine Enterprise-Linux-Strategie aufstellt, muss vier Dimensionen klar trennen. Erstens den Lizenztyp: Ist die Distribution offen genug, dass keine Vendor-Lock-in-Risiken entstehen? Zweitens den Support-Typ: Wer liefert Sicherheits-Backports mit definierten SLAs? Drittens den Lifecycle: Wie lange ist die Distribution für den konkreten Workload supportet? Viertens Zertifizierungen: Welche ISV-Software läuft offiziell supportet auf dieser Plattform?

RHEL mit Subscription liefert alle vier Dimensionen aus einer Hand – zum Preis von Vendor-Abhängigkeit und Lizenzkosten. AlmaLinux und Rocky Linux liefern Dimension eins und teilweise zwei und drei, aber Dimension vier ist lückenhaft. SLES ist stark in zwei bis vier, hat aber ein kleineres Ökosystem als RHEL. Ubuntu Pro ist stark in eins und zwei, schwächer in vier für klassische Enterprise-Software.

Der SUSE-Fork zielt langfristig auf alle vier Dimensionen ohne Vendor-Lock-in – aber das ist heute noch ein Versprechen, kein ausgeliefertes Produkt. Wer langfristige Migrationspfade plant, sollte den Fork im Auge behalten, aber keine Produktionsentscheidung ausschließlich darauf aufbauen.

Interessant in diesem Kontext: In Deutschland setzen zunehmend öffentliche Institutionen auf Linux-basierte Infrastruktur. Aktuelle Berichte über Deutschlands Open-Source-Kurs in der Verwaltung zeigen, dass die Lizenzkostenoptimierung und Souveränitätsfragen real ankommen – und damit auch die Frage, ob Community-Distributionen oder kommerzielle Subscriptions besser zu behördlichen Compliance-Anforderungen passen. Community-Linux bedeutet hier nicht Ideologie, sondern konkrete Haushaltspolitik.

Migration aus CentOS: Was jetzt ansteht

Klassisches CentOS 7 und 8 sind EOL. CentOS Stream ist kein Ersatz für eine stabile Enterprise-Plattform. Wer noch auf diesen Systemen läuft, muss migrieren – und die Optionen sind klar: RHEL mit Subscription, AlmaLinux oder Rocky Linux als RHEL-kompatible Plattformen, SLES für SUSE-nahe Umgebungen, Ubuntu Pro für Cloud- und DevOps-Workloads.

Die Migration von CentOS auf AlmaLinux ist technisch erprobt und gut dokumentiert. Tooling wie almalinux-deploy nimmt einem den manuellen Aufwand ab. Rocky Linux bietet analoge Migrationsskripte. Für Umgebungen, die RHEL-Subscription einführen wollen, gibt es Migrationspfade über das Red Hat Customer Portal, inklusive Convert2RHEL-Tool.

Meine Einschätzung nach dem Stand der Dinge: Für Shops, die keine zwingenden ISV-Zertifizierungsanforderungen haben und intern die Kompetenz für Community-Support aufbauen können oder externe Dienstleister nutzen, ist AlmaLinux heute die pragmatischste Wahl. Keine Ideologie, keine Subscription-Rechnung, aber auch kein Red Hat Satellite und kein kpatch out-of-the-box. Das ist ein bewusster Trade-off, kein kostenloses Mittagessen.

RHEL 10.1 ist für Umgebungen mit ISV-Anforderungen, regulatorischen Compliance-Vorgaben oder SAP-Workloads die sachliche Wahl – auch wenn die Subscription-Kosten schmerzen. Zehn Jahre definierten Support, echte SLAs und ein vollständiges Tooling-Ökosystem haben ihren Preis.

Praxis-Szenarien: Welche Plattform für welchen Kontext

Abstrakte Entscheidungsraster helfen nur begrenzt weiter. Konkretere Szenarien machen den Unterschied deutlicher sichtbar.

Szenario 1 – Mittelständisches Produktionsunternehmen mit SAP S/4HANA: Keine Wahl außer RHEL mit Subscription oder SLES. SAP zertifiziert explizit auf beiden Plattformen und liefert Support nur, wenn das darunterliegende Betriebssystem ebenfalls im Supportstatus ist. AlmaLinux ist hier kein valider Kandidat – unabhängig davon, wie gut die ABI-Kompatibilität technisch funktioniert. Entscheidend ist die formale Zertifizierungskette, nicht die empirische Lauffähigkeit.

Szenario 2 – SaaS-Anbieter mit containerisierten Microservices: Hier ist die Wahl erheblich offener. Wenn die Anwendungsschicht in Kubernetes läuft und proprietäre Kernel-Module oder ISV-Zertifizierungen keine Rolle spielen, ist AlmaLinux oder Rocky Linux als Container-Host eine gut vertretbare Entscheidung. Die Abhängigkeit vom Betriebssystem-Vendor ist gering, der Kostenvorteil real. Voraussetzung: Ein internes oder extern beauftragtes Team, das Sicherheits-Advisories verfolgt und zeitnah patcht.

Szenario 3 – Behörde unter NIS2-Verpflichtung: NIS2 verlangt unter anderem nachweisbare Patch-Management-Prozesse und definierte Reaktionszeiten bei Sicherheitsvorfällen. Community-Distributionen schließen das nicht aus, erhöhen aber den Dokumentationsaufwand: Wer ist verantwortlich, wenn kein Vendor-SLA existiert? Interne IT-Teams müssen nachweisen, dass sie den Community-Patch-Prozess aktiv monitoren und umsetzen. Eine RHEL-Subscription vereinfacht diese Nachweiskette erheblich, ist aber nicht die einzig mögliche Antwort. Entscheidend ist die interne Prozessreife.

Szenario 4 – Startup mit gemischter Cloud-Infrastruktur: Ubuntu Pro ist hier oft die natürlichere Wahl – nicht weil RHEL schlechter wäre, sondern weil Ubuntu in Cloud-nativen Umgebungen tief verankert ist. AMIs, Container-Images, Ansible-Rollen und Terraform-Module für Ubuntu sind in der Cloud-Community breiter verfügbar. Für Workloads ohne klassische Enterprise-Software-Abhängigkeiten senkt Ubuntu Pro die Einstiegshürde, ohne auf strukturierten Sicherheitssupport zu verzichten.

Gegenargument: Warum Community-Distributionen unterschätzte Risiken tragen

Es gibt ein Argument, das in Community-orientierten Diskussionen zu selten ernst genommen wird: Organisatorische Kontinuität. AlmaLinux und Rocky Linux sind solide Projekte – aber sie sind keine Unternehmen mit Bilanzen, Gewährleistungspflichten und Haftung. Was passiert, wenn ein Kernentwicklerteam ein Projekt verlässt oder Sponsorengelder wegbrechen? Das CentOS-Ende hat gezeigt, dass selbst Red-Hat-gestützte Community-Projekte innerhalb weniger Monate strategisch umgelenkt werden können.

Das ist kein Argument gegen AlmaLinux oder Rocky Linux per se. Es ist ein Argument dafür, das Risikoprofil bewusst zu bewerten. Wer Community-Distributionen einsetzt, sollte einen Migrationsplan in der Schublade haben – nicht als Zeichen von Misstrauen, sondern als grundlegende IT-Governance-Praxis. Genau dieser Ansatz unterscheidet professionelle IT-Planung von einer reinen Kostenspar-Entscheidung.

Auf der Gegenseite ist auch Vendor-Lock-in ein reales Risiko. Red Hats Quellcode-Entscheidung 2023 war ein Erinnerungssignal: Subscription-Kunden sind nicht immun gegen einseitige Vendor-Entscheidungen. Die Kosten für einen erzwungenen Plattformwechsel können die Subscription-Einsparungen der vorangegangenen Jahre schnell übersteigen. Wer RHEL-Subscription einsetzt, sollte regelmäßig prüfen, ob die eigene Infrastruktur so aufgebaut ist, dass ein Wechsel grundsätzlich durchführbar bleibt – auch wenn er aktuell nicht geplant ist.

Was bleibt offen

Der SUSE-Fork könnte die Landschaft 2027 oder 2028 nochmals verschieben – wenn das Projekt tatsächlich produktionsreif wird und die Foundation-Governance hält, was die Ankündigung verspricht. AlmaLinux und Rocky Linux werden konsolidieren oder sich stärker differenzieren müssen, sobald ein dritter ernsthafter Community-Akteur mit institutionellem Rückhalt im Markt ist.

Die entscheidende Frage ist nicht, ob Community-Distributionen gut genug sind. Die Frage ist: Für welchen Workload, mit welchem internen Kompetenzprofil, unter welchen regulatorischen Bedingungen? Wer darauf ehrliche Antworten hat, kann die RHEL Subscription einsparen – oder erkennt, warum er sie braucht. Beides ist eine valide Antwort, nur nicht für alle gleichzeitig.

Haben Sie eine Migrationsstrategie für Ihre CentOS-Systeme – und welches Modell passt zu Ihrer konkreten Compliance-Anforderung?