Wenn Schockwellen die Freie Software Community erschüttern, lohnt es sich oft, eine kühle Mate aus dem Kühlschrank, und das Popcorn aus dem Schrank zu holen. Damit setzt man sich in eine gemütliche Ecke, um sich das Schauspiel anzusehen. Ihr ahnt, worum es geht? Beginnen wir von Anfang an:
Das Unheil nahm seinen Anfang, als die Firma Red Hat im Juli 2019 für 34 Milliarden Dollar von IBM aufgekauft wurde.
CentOS (Community Enterprise Operating System) war eine Linux-Distribution, die auf Red Hat Enterprise Linux (RHEL) des Unternehmens Red Hat aufbaute. Die Distribution wurde von einer offenen Gruppe von freiwilligen Entwicklern betreut, gepflegt und weiterentwickelt. Bis 2021 war CentOS hinter Ubuntu und Debian die am dritthäufigsten verwendete Linux-Distribution für Web-Server.
Die kommerzielle Linux-Distribution RHEL kann nur im Zusammenhang mit Supportverträgen erworben werden. Die Firma Red Hat stellt aber alle Quellpakete von RHEL im Internet bereit, um die Anforderungen unterschiedlicher Lizenzen von in RHEL enthaltener freier Software zu erfüllen. Das ermöglicht es, eine zu RHEL binärkompatible Linux-Distribution zu entwickeln. Durch die Binärkompatibilität ermöglichte CentOS, Computer mit einer RHEL-kompatiblen Linux-Distribution zu nutzen, ohne einen Supportvertrag mit Red Hat abschliessen zu müssen. Auch ergab sich, neben finanziellen Ersparnissen, der Vorteil, dass alle Software, die für RHEL angeboten wird, auch direkt und ohne Einschränkungen unter CentOS genutzt werden konnte.
Im Jahr 2021 wurde die Kompatibiltät zwischen RHEL und CentOS aufgehoben. An dessen Stelle trat CentOS Stream, mit dem die Weiterentwicklung von RHEL getestet und stabilisiert werden sollte. Dadurch kam CentOS Stream für die meisten Server-Betreiber nicht mehr infrage. Wer ein stabiles RHEL möchte, setzt nicht die Beta-Version als Rolling Release ein (CentOS).
Es dauerte nicht lange, bis die Projekte RockyLinux und AlmaLinux darauf reagierten und auf der Basis der öffentlichen RHEL-Quellen ihre Clone erstellten. ScientificLinux hatte bereits 2019, also vor diesem Ereignis, aufgegeben und auf CentOS verwiesen. Damit kehrte unter den Server-Betreibern wieder Ruhe ein, hatte man doch mit Rocky und Alma zwei Alternativen, die die Binärkompatibilität mit RHEL sicherstellten.
Diese Ruhe endete am 21. Juni 2023 abrupt, als Red Hat (IBM) mitteilte, dass man den RHEL Quellcode nicht mehr öffentlich zur Verfügung stellen werde. Damit wurde die Lebensader für Rocky und Alma abgeschnitten. Rechtlich gesehen, ist diese Entscheidung völlig in Ordnung, da die GPL nicht grundsätzlich zur Veröffentlichung des Quellcodes verpflichtet.
Die GPL schreibt vor, dass es den Lizenznehmern möglich sein muss, den Code zu analysieren. Die Konsequenz dieser Vorschrift ist, dass der Programmcode einsehbar ist. Die Pflicht der Offenlegung innerhalb der GPL bezieht sich jedoch nicht auf die allgemeine Öffentlichkeit. Laut GPL-Lizenz müssen lediglich Lizenznehmer den Code einsehen können. Es ist dementsprechend vom Lizenzgeber festzulegen, wer Lizenznehmer ist. Der Lizenzgeber kann die Software zusammen mit dem Quelltext an eine ausgewählte Gruppe von Lizenznehmern übergeben. Er kann sich jedoch auch dafür entscheiden, dass dies auf einem öffentlich zugänglichen Webserver geschehen soll. Letzteres ist bei Open-Source-Software häufig der Fall.
Im Sinne des Lizenzgebers (IBM) sind die Projekte RockyLinux und AlmaLinux keine Lizenznehmer, womit sie keinen Anspruch auf Einsicht der RHEL Quellcodes haben.
Am 29. Juni hat das Rocky-Projekt mit zwei Vorschlägen reagiert, wie man das Problem umgehen könnte:
Eine Möglichkeit besteht in der Verwendung von UBI-Container-Images, die auf RHEL basieren und über verschiedene Online-Quellen (einschließlich Docker Hub) erhältlich sind. Mit dem UBI-Image ist es leicht möglich, Red Hat-Quellen zuverlässig und unbelastet zu beziehen. Wir haben dies mit OCI-Containern (Open Container Initiative) getestet, und es funktioniert genau wie erwartet.
Eine weitere Methode, die wir nutzen werden, sind Pay-per-Use-Instanzen in der öffentlichen Cloud. Damit kann jeder RHEL-Images in der Cloud aufsetzen und so den Quellcode für alle Pakete und Errata erhalten. Dies ist für uns am einfachsten zu skalieren, da wir all dies über CI-Pipelines erledigen können, indem wir Cloud-Images aufsetzen, um die Quellen über DNF zu erhalten, und diese automatisch in unsere Git-Repositories stellen.sdf
Auch das Alma-Projekt hat bereits am 22. Juni auf die Veränderungen in einem Blog-Post reagiert, jedoch noch keine Mitigationsvorschläge benannt. Damit möchte man sich ein paar Wochen Zeit nehmen.
Aber was macht man, wenn nicht alternative Clone, sondern alternative Lösungen gefragt sind? Die Antwort darauf ist einfach und liess auch nicht lange auf sich warten. Wer auf Support und Service Level Agreements angewiesen wird, was sehr wahrscheinlich im Unternehmensumfeld ist, kann auf die Linux-Server-Distros von Canonical und SUSE ausweichen. SUSE bietet mit SUSE Linux Enterprise Server (SLES) eine Alternative an, ebenso wie Canonical mit ihren Enterprise Angeboten.
Am vergangenen Donnerstag äusserte sich Dr. Thomas Di Giacomo (Chief Technology & Product Officer bei SUSE) zur Situation und wirft IBM indirekt ein falsches Verständnis der Open Source-Landschaft vor:
Bei SUSE liegen uns die Prinzipien von Open Source und die Kraft der Zusammenarbeit am Herzen. Auch wenn Veränderungen in der Open Source-Landschaft die Dynamik verändern können, sind wir der festen Überzeugung, dass die Freiheit, auf Software zuzugreifen, sie zu verändern und zu verbreiten, für alle offen bleiben sollte.
Und dann positioniert er das SUSE-Angebot direkt gegen IBM:
SUSE unterstützt viele Unternehmenskunden bei der Ausführung und Verwaltung heterogener Umgebungen, einschließlich CentOS und RHEL. Unsere Lösung für diese Kunden ist SUSE Liberty Linux. Wir möchten unseren Kunden versichern, dass wir uns weiterhin voll und ganz dafür einsetzen, ein nahtloses Erlebnis für SUSE Liberty Linux zu schaffen. Daran ändert auch die Entscheidung von Red Hat nichts.
Von Canonical habe ich bis jetzt noch keine Stellungnahme zur Causa RHEL gelesen. Selbstverständlich hat sich das Debian Projekt auch nicht dazu geäussert; das wäre unter ihrer Würde. Dabei könnte Debian als grosse Gewinnerin aus diesem Debakel hervorgehen. Debian ist die Mutter aller GNU/Linux-Serverbetriebssysteme; Debian ist nicht kommerziell und Debian hat erst vor drei Wochen die brandneue Version 12 (Bookworm) herausgebracht. Zwar kann man von diesem Community-Projekt keinen Unternehmens-Support beziehen, aber dafür gibt es bestimmt Lösungen von Drittanbietern.
Als Desktop-Anwender:innen müsst ihr euch keine Sorgen machen; Fedora ist von dieser Angelegenheit nicht betroffen. Aber räumt das Popcorn noch nicht weg, das Schauspiel geht bestimmt noch weiter.
Quellen:
https://www.redhat.com/en/blog/furthering-evolution-centos-stream
https://de.wikipedia.org/wiki/CentOS
https://www.suse.com/c/navigating-changes-in-the-open-source-landscape/
https://iits-consulting.de/blog/general-public-license/
Nein, sehe ich überhaupt nicht so. Debian als nicht-kommerzielles Projekt sowieso nicht - schreibt ihr ja auch selber. Externe Dienstleister zu Debian - vielleicht für sich als Dienstleister. Aber: Dienstleister haben ja bestenfalls mittelbaren Einfluss auf die Entwicklung von Debian und ext. Dienstleister werden sich IMHO schwer tun, den langen Supportzeitraum von RedHat ebenfalls abzubilden. Canonical und Suse können das. Vielleicht geht aber auch RedHat als (kommerzieller) Gewinner hervor, weil die die Kunden von Oracle Linux abgreifen - Oracle hat ja auch keine Paketquellen mehr, die sie kommerziell verwerten können.
Open Source ist dann doch nicht immer Open Source. Open Source für Lizenznehmer, doch sicherlich mit einer Art Geheimhaltungsvereinbarung, ist keine Open Source sondern Closed Source.
Es gibt kein "Open Source für Lizenznehmer". Open Source ist Opensource. Es sei denn, die Software ist dual lizenziert (wie z.B. Qt). Wenn jemand eine Service Lizenz abschließt umfasst die Lizenz den Service und ggf. zusätzlich Software zusätzlich zur Open Source Software. Aber die bleibt frei. Einfaches Beispiel: wenn du eine Webagentur damit beauftragt, dir eine Webpräsenz auf Basis von Typo3 zu bauen, dann zahlst du der Agentur dafür. Typo3 bleibt trotzdem Open Source.
ich habe zu dem Thema einen recht guten Beitrag gelesen der inkl. der Kommentare recht aufschlussreich das Thema aufbereitet.
https://news.itsfoss.com/red-hat-fiasco/
ich kann RH schon verstehen und dennoch stösst es die Gemeinschaft vor den Kopf was in der Natur der Sache liegt.
Es wird sich auch zeigen ob Suse durch seine Turbulenzen in relative Schieflage gekommen, seine Garantien aufrechterhalten wird können. https://www.wallstreet-online.de/nachricht/16983176-presse-softwareanbieter-suse-uebernahme Man wird sehen wie es ausgeht. In jedem Fall steht die Linuxwelt vor gravierenden Umbrüchen
Seit Längerem tut sich etwas bei den kommerziellen Linuxdistributionen. Weg von Paketen die über 10-12 Jahre gepatcht werden um sie für den Serverbetrieb stabil zu halten und hin zu einer immutablen Installation die dann mit Containern und flatpaks versorgt werden und durch ein einfaches rollback unvorhergesehene Funktionsverluße ausgleichen können. Ich denke, dass wenn das alles mal Spruchreif ist, wir dann eventuell auch gerne freiwillig auf ein CentOS oder Alma und Rocky verzichten.
Mies war von Red Hat ausschließlich die Kommunikationsform – mit entsprechendem Vorlauf der An-/Abkündigung wäre das doch OK gewesen. Sie geben doch (meines Wissens) sogar noch immer alle Quellen für alle frei (was sie nicht müssten), nur eben nicht so schön als SRPMs verpackt. Mir gefällt es auch nicht, aber RH hier in der Sache einen Vorwurf zu machen, finde ich schon sehr gewagt (und das, obwohl ich viele von RH maßgeblich vorangetriebene Entwicklungen nicht sehr schätze).