Linux-Forks und Java-Preise Gräben und Verwerfungen im Open-Source-Lager

Nachdem Red Hat der Gemeinde den RHEL-Quellcode entzogen hat, hat sich Suse angeschickt, das Linux des Erzrivalen zu forken. Ein Bürgerkrieg im Open-Source-Lager? Ha! Als ob das alles wäre! Auch die übrige Open-Source-Gemeinde kann sich nicht mehr ausruhen.

Der Quellcode stabiler „RHEL“-Versionen (Red Hat Enterprise Linux) wird in den öffentlichen Repositories von Red Hat nicht mehr gepflegt. Das Unternehmen beschränkt den Zugriff darauf auf zahlende Kunden, Entwickler und sonstige Ökosystempartner unter der Bedingung, dass sie ihn für sich behalten und mit niemandem teilen.

Laut einem Blog-Beitrag von Mike McGrath, dem Vice President für Core Platforms Engineering, vom 21. Juni, gibt es von Red Hat künftig nur noch eine einzige Bezugsquelle für den öffentlichen RHEL-Quellcode: „CentOS Stream“, eine Upstream-Distribution von RHEL. Sie liegt auf der „Reifeskala“ zwischen „Fedora“ (der weitgehend experimentellen Upstream-Distribution) und RHEL (der „Downstream-“, stabilen Enterprise-Distribution).

Bildergalerie

Dieser Schritt hat den Anschein einer Maßnahme gegen das Aufkommen von „Alma Linux“ und „Rocky Linux“, zwei RHEL-kompatibler und kostenfreier Distributionen, die ihren Quellcode veröffentlichen. Rocky Linux versucht, auf Biegen und Brechen „bug-for-bug-kompatibel“ zu sein, um die Lauffähigkeit von Enterprise-Software zu gewährleisten. Alma Linux macht es anders; hier nimmt man sich die Freiheit, auftretende Probleme einfach mal zu lösen.

Bis Dezember 2020 gab es eine lizenzkostenfreie und binärkompatible Community-Distribution von Red Hat Linux namens CentOS (Community Enterprise Linux Operating System). Aufgrund ihrer Stabilität und Kompatibilität fand sie einen breiten Einsatz im Enterprise-Umfeld – zum Leidwesen von Red Hat. Im Juni 2023 kündigte Red Hat an, den Zugriff auf den Quellcode von RHEL auf zahlende Kunden und Ökosystempartner zu beschränken.

Die öffentliche Quellcode-Repository für RHEL (git.centos.org) fällt damit weg. Zahlende Kunden und Ökosystempartner können den Quellcode wie gewohnt über das Red Hat Customer Portal beziehen. Gleiche und Gleicheren?

Der Wegfall einer stabilen kostenfreien Distribution mit fortlaufender Kompatibilität zur aktuellen Produktionsversion von RHEL hat die Open-Source-Gemeinschaft in helle Panik versetzt.

Die Hütte brennt! (schon wieder)

Kritiker wie die Software Freedom Conservancy argumentieren, dass die GPL-Lizenz für Red Hat nur noch ein bedeutungsloses Lippenbekenntnis sei. Die Entscheidung, zuvor weitgehend zugänglichen Code hinter einer Bezahlmauer zu verstecken, widerspricht den Grundsätzen des Open Source.

Hinter vorgehaltener Hand ist in Linux-Kreisen sogar schon die Rede von einem Verrat des Open-Source-Gedankens. Schließlich ist das Kernprinzip von Open Source, in etwa „leben und leben lassen“.

„In einer Reaktion auf diese Ankündigung wurde ich als ein IBM-Manager bezeichnet, der eingesetzt worden sei, um Red Hat in eine geschlossene Quellcode-Umgebung zu verwandeln“, schrieb Mike McGrath, der Urheber der RHEL-Nachricht, in einer Stellungnahme zu der Ankündigung. „Und das ist nur das 'netteste Zeug'."

Stimmen

Greg Kurtzer, Gründer von Rocky Linux, dem RHEL-Fork für Cloud-native Infrastrukturen, kritisierte die „vorhersehbaren, unnötigen, vermeidbaren und kontraproduktiven Konsequenzen“ der Einschränkungen. Der Schritt würde aus seiner Sicht das Profil von Alternativen wie seiner eigenen Distribution anheben. In der Zwischenzeit habe man bei Rocky Linux einen Weg gefunden, Red Hats neueste Einschränkungen zu umgehen.

Auch Oracle Corp. schloss sich dem Chor der Empörung an und beschuldigte IBM, den Mutterkonzern von Red Hat, antikompetitiver Taktiken. „Weniger Wettbewerber bedeuten mehr Umsatzchancen für IBM“, schrieben nicht ganz uneigennützig Chief Corporate Architect Edward Screven und Head of Oracle Linux Development Wim Coekaerts. Im Lichte der dramatischen Anhebung der Lizenzgebühren für Oracles Java erscheint das Argument unglaubwürdig (siehe: weiter unten).

Corey Quinn, der Chief Cloud Economist der Duckbill Group und Branchenbeobachter, quittierte Oracles Empörung mit den Worten: „Habt ihr überhaupt eine Ahnung, wie weit man die Misshandlung von Open Source treiben muss, dass Oracle als die bessere Partei dasteht?"

Oracle hat inzwischen versprochen, den Quellcode seiner eigenen Version von Linux in alle Ewigkeit frei verfügbar zu machen. Na, das ist schon mal was.

Suse Liberty Linux

Bei Suse brachte die kontroverse Entscheidung von Red Hat gleich den Ball ins Rollen. Unter der Leitung seines neuen CEOs, des Red Hat-Veteranen Dirk-Peter van Leeuwen, will der deutsche Linux-Pionier aus Nürnberg einen eigenen Fork von RHEL veröffentlichen. Mit Blick auf lukrative Support-Verträge möchte sich Suse sein „Liberty Linux“ vorerst rund 10 Millionen Dollar kosten lassen.

Suse hatte schon an einem internen Rebuild von CentOS Linux 8 mit dem Codenamen „Liberty Linux“ im Jahre 2021 gearbeitet und den Namen daraufhin auf seine Support-Verträge übertragen. Jetzt hat sich der Anbieter mit CIQ, der treibenden Kraft hinter Rocky Linux, zusammengetan.

Das Softwareportfolio von Suse umfasst einige herausragende Produkte, darunter „Suse Linux Enterprise Server“ (SLES), „Suse Enterprise Linux for SAP“, die Edge-Distributionen „SLE Micro“ und „SLE Real Time“, den Kubernetes-Orchestrierer „Rancher“, die hyperkonvergente Infrastruktur „Harvester“, die Containersicherheitssoftware „Neuvector“ und zahlreiche andere. Suse zählt zu seinen Kunden und Partnern unter anderem Microsoft, Lenovo, Schneider Electric, das Leibnitz Supercomputing Center, Bosch und SAP. Die Erfolgsgeschichte von Suse lässt Hoffnung aufkommen.

Über Lizenzkosten orakeln

Jetzt zieht Oracle neue Saiten auf. Die Lizenzierung von „Java“ ist im Jahr 2023 spürbar teurer und komplexer geworden. Dies hängt hauptsächlich mit der Einführung einer neuen Lizenzmetrik zusammen, die die Kosten für „Java SE“ und „Java SE Desktop“ um ein Vielfaches erhöhen kann.

Diese 'Mitarbeitermetrik', auch bekannt als „Java SE Universal Subscription“, basiert auf der Anzahl der Mitarbeiter und verändert drastisch die Art und Weise, wie die Lizenzgebühren für Oracle Java zustande kommen. Die neue Metrik kann die Kosten für Java um das 4- bis 10-fache anheben. Da bleibt vielen Unternehmen nur die Flucht zu „OpenJDK“(oder zu einer Alternative wie „Azul OpenJDK“) oder IBMs „Java für Red Hat“ übrig. Im Enterprise-Umfeld ist „Kotlin“ Geschichte.

Nicht alle Installationen von Oracles Java sind lizenzpflichtig und einige von ihnen sind nur als Teil eines kommerziellen Angebots lizenzpflichtig. Java 6 und Java 7 bleiben kostenlos, erhalten jedoch keine öffentlichen Updates. Java 8 hingegen erfordert eine Lizenz, aber die Kunden wissen möglicherweise nicht, ob sie Java 8 verwenden und ob sie ausreichend lizenziert sind.

Die Kosten können für Java um das 4- bis 10-fache steigen

Um herauszufinden, ob ein Abonnement anfällt, muss die betroffene Organisation zunächst überprüfen, welcher Typ des Java-Vertrags Anwendung findet, welche Java-Versionen und -Funktionen zum Einsatz kommen und ob diese Installationen eine Lizenz erfordern. Nur mit dieser Transparenz können Unternehmen ihre Compliance-Situation bewerten, Lizenzprobleme beheben und sich auf Audits vorbereiten.

Nicht alle Java-Installationen müssen lizenziert werden. Java-Installationen unter den BCL- oder NFTC-Vereinbarungen erfordern kein kostenpflichtiges Abonnement. Java-Installationen unter der OTN-Vereinbarung gehen im Gegensatz dazu mit einem kostenpflichtigen Abonnement einher. Das verursacht typischerweise erhebliche Kosten.

Die Lizenzkosten in dem neuen Modell leiten sich von der Anzahl der Mitarbeiter in der betreffenden Organisation ab. Unter „Mitarbeiter“ versteht Oracle alle Vollzeit-, Teilzeit- und Zeitarbeitskräfte, einschließlich Agenten, Auftragnehmer, Berater & Co., die die internen Geschäftsbetriebe unterstützen. Das kann tatsächlich zu erheblichen Kosten für Unternehmen führen, selbst wenn nur eine kleine Anzahl von Arbeitsplätzen die Software nutzt.

Unternehmen sind gut beraten, ihre Java-Nutzung und Lizenzvereinbarungen sorgfältig zu überprüfen, um die Compliance sicherzustellen und Kosten effektiv zu verwalten. Auch die Erkundung alternativer Lizenzierungsoptionen und die Optimierung der Java-Nutzung können sich als sinnvoll erweisen. Im Zusammenhang mit der Einführung des neuen Lizenzmodells, „Java SE Universal Subscription“, sehen sich Unternehmen mit erheblichen Risiken konfrontiert.

Laut Oracle können Kunden mit einem aktiven Java SE-Abonnement ihre ursprünglichen Vorteile weiterhin nutzen und haben die Möglichkeit, ihren Vertrag unter den bestehenden Bedingungen und Metriken zu verlängern. Deswegen merken es die meisten erst gar nicht, dass sich die Großwetterlage geändert haben mag.

Trotz Oracles Aussagen ist die langfristige Strategie des Softwareriesen im Hinblick auf die Lizenzierung von Java unsicher. Selbst über die Preise für bestehende Abonnenten herrscht Ungewissheit, da es im Vorfeld nicht klar ist, ob das Verlängern eines bestehenden Vertrags in einem konkreten Fall unter Einbezug von zusätzlichen Lizenzen nicht doch automatisch die Umstellung auf das neue, ungünstige Lizenzmodell erzwingen mag.

Regelmäßige Bestandsaufnahmen sowie die Implementierung von Überwachungs-Tools von Drittanbietern können den Unternehmen einen Echtzeitüberblick über ihre Java-Umgebung verschaffen. Die Verwendung eines von Oracle geprüften SAM-Tools (Software Asset Management) wie „USU Oracle Optimization“ erlaubt den Verantwortlichen, einen vollständigen Überblick über die Java-Installation und die darauf installierten Geräte oder virtuelle Maschinen (kostenfrei/kommerziell/Drittanbieter) zu erhalten. Das Tool liefert Informationen über die Anzahl der erforderlichen Java-Lizenzen und die damit verbundenen Kosten.

Oracle zählt zwar zu den besonders erfolgreichen IT-Unternehmen, aber die Rechtsabteilung des texanischen Softwareriesen ist zweifelsohne an und für sich auch ein Schwergewicht. Überall dort, wo Unternehmen Oracles Preise „sauer“ aufstoßen, will die quelloffene Gemeinde mit Lösungen wie OpenJDK Abhilfe schaffen. Zum Beispiel in einer Distribution von…. Microsoft oder… Red Hat? Oder doch die SAPMachine?

Ein dé·jà vu

Open Source an sich ist so erfolgreich wie nie zuvor. Doch das aktuelle Debakel rund um Zugriffsrechte auf den RHEL-Quellcode wirft ernsthafte Fragen nach der Zukunft von Open Source im Unternehmensumfeld auf. So ruft die aktuelle Kontroverse die Open-Source-Debatte aus dem Jahre 2019 in Erinnerung, als einige Startups ihre Lizenzen modifizierten, um kommerzielle Produkte, die auf ihrem Code basierten, einzuschränken und Unternehmen wie Amazon und Tencent in ihre Schranken zu weisen.

Neue Lizenzen wie die Server Side Public License (SSPL) von „MongoDB“ sollten verhindern, dass große Unternehmen quelloffene Software als Service anbieten und damit im Cloud-Maßstab Geld verdienen, ohne eine kommerzielle Lizenz zu erwerben oder einen eigenen Beitrag zum Fortbestand der Projekte zu leisten.

(ID:49676506)